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

[Kurt Borja]

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.

>
> (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?

> 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.

-- 
Thanks,
 ~ Kurt