Re: [PATCH v3 7/9] iio: adc: ti-ads1262: support triggered buffer sampling

[Jonathan Cameron]

On Thu, 27 Aug 2026 13:45:17 -0500
"Kurt Borja" <kuurtb@xxxxxxxxx> wrote:

> On Sun Aug 16, 2026 at 4:54 PM -05, Jonathan Cameron wrote:
> > On Tue, 11 Aug 2026 15:24:46 -0500
> > "Kurt Borja" <kuurtb@xxxxxxxxx> wrote:
> >  
> >> On Mon Aug 10, 2026 at 11:31 AM -05, David Lechner wrote:  
> >> > On 8/9/26 3:28 AM, Kurt Borja wrote:    
> >> >> On Sat Aug 8, 2026 at 1:39 PM -05, David Lechner wrote:    
> >> >>> On 8/7/26 10:58 PM, Kurt Borja wrote:    
> >> >>>> Add triggered buffer support and a data-ready (DRDY) hardware trigger.
> >> >>>>    
> >> >
> >> > ...
> >> >    
> >> >>>    
> >> >>>> +	u8 tx[11] __aligned(IIO_DMA_MINALIGN);
> >> >>>> +	u8 rx[11] __aligned(IIO_DMA_MINALIGN);    
> >> >>>
> >> >>> don't need second one to be aligned, they aren't independent.    
> >> >> 
> >> >> Ah, I forgot this observation in the last version. These are used in a
> >> >> full-duplex transfer, wouldn't that require for both to be on its own
> >> >> cache line? I just started learning about DMA.    
> >> >
> >> > No. In this case, it works roughly like this...
> >> >
> >> > - We fill the TX buffer before the transfer. (CPU access to memory may
> >> >   just live in the cache at this point and not actually be sent to RAM)
> >> > - We request to start the SPI transfer.
> >> > - The core SPI code flushes (or maybe I should say invalidates) the cache
> >> >   on the TX buffer. This ensures that what we wrote with the CPU available
> >> >   to DMA.  
> >
> > Extra fun - it has to flush the rx buffer too.  Because...  
> >> > - The actual SPI transfer happens that uses DMA to access both TX and
> >> >   RX buffers. (Again, could just live in a cache and not be sent to RAM)
> >> > - The SPI core code flushes the cache on the RX buffer. This ensures
> >> >   that when the CPU reads the memory, it will see what the DMA just
> >> >   wrote.    
> > If the RX buffer had old dirty lines (could have been used for something
> > completely different) in it, that is modified data that hadn't
> > been written back to RAM, then this flush would wipe out the hardwork of
> > the DMA by writing those CPU cache held rx bytes over the top.  
> 
> Makes sense too. In this case, if both buffers share the same cache
> line, I *guess* that would just be a redundant flush.

In some paths maybe. I'd need to draw it out and it's Sunday evening
so not today! :)

> 
> >
> > (Next bit is just to scare anyone who thinks they know how this all works -
> > completely irrelevant here :)
> > Don't get me started on architectures that do clean write back (occasionally).
> > Thankfully I don't believe any of them also have non coherent DMA as to
> > be able to do that nasty hack you have to know no one can see it.  
> 
> With "clean write back" are you referring to a write back without
> invalidating the line?

No.  Writing back a line that was known to be be clean - neither CPU
nor devices ever wrote it.  The problem lies that it could have been
fetched in by a prefetcher at any random time. Then written back at
another random time - potentially on top of what ever DMA occurred
in the meantime.  It's completely broken but only if there is a way
to see it.  On that platform one was introduced much later than the
original design on basis everyone pretty much assumes cache coherency
protocols never do clean write backs.

Anyhow, tales that should be accompanied by strong spirits.  Not even
beer is enough for this one (and I was only on the side lines!)

> 
> > For more fun, one large CPU vendor thought that was the case and there is
> > a spec out there that has a magic flag to let the OS know it does this
> > because there are cases where you care.
> > </rant>
> >  
> >> 
> >> Oh, this makes a lot of sense.
> >>   
> >> >
> >> > Since there isn't a time when CPU and DMA both write to the cache line
> >> > at the same time before a flush, there is never a time we could have
> >> > an issue with stale data replacing data that had not been flushed.
> >> >
> >> > It does mean that we can't update the tx buffer for the next message
> >> > until after this message is done, but we have to do that anyway.
> >> >
> >> > What does cause problems is if we just had a regular unrelated variable
> >> > after this in the cache line and the driver updated it during a SPI
> >> > transfer. If this new value was just living in the CPU cache, then
> >> > when the RX flush happened, it would write over that new value with
> >> > stale data from the DMA's version of the cache.    
> >> 
> >> Thanks! I'll look deeper into DMA, it's very interesting.
> >>   
> > Wolfram Sang did a nice ELCE talk on the more normal flows for this a
> > few years back when he was working on reducing copies in the i2c subsystem.
> > https://www.youtube.com/watch?v=JDwaMClvV-s&pp=ygUQd29sZnJhbSBzYW5nIGRtYQ%3D%3D
> > Is the one I think.  
> 
> Very interesting talk, DMA is way messier than I thought. I guess it's
> the price of supporting so many different architectures.
> 
> I recently got my hands on an FPGA board so I'm gonna be playing with
> it, although it seems DMA is still way out of my reach :p.
> 
> ...
> 
> Thanks for your review! I already finished v4 and I should be able to
> submit it tonight.
>