Re: [PATCH 5/9] iio: adc: rzt2h: implement DMA buffer support

[Jonathan Cameron]

On Thu, 3 Sep 2026 07:49:29 +0000
Cosmin-Gabriel Tanislav <cosmin-gabriel.tanislav.xa@xxxxxxxxxxx> wrote:

> > From: Jonathan Cameron <jic23@xxxxxxxxxx>
> > Sent: Saturday, August 29, 2026 4:21 AM
> >   
> > > Implement buffered capture using a cyclic DMA transfer into a kfifo
> > > buffer to support continuous high-rate sampling.
> > >
> > > On buffer enable, switch the ADC to continuous conversion mode and start
> > > a cyclic DMA transfer over the active channels.
> > >
> > > Because the DMA controller does not support native scatter-gather, and
> > > because of the cyclic DMA setup, transfers must be done in widths
> > > covering all the enabled channels.
> > >
> > > Since DMA transfer width must be a power of two and aligned to its size,
> > > cover the smallest power-of-two-aligned group of channel registers
> > > spanning the enabled channels.
> > >
> > > Split the cyclic buffer into fixed-size periods. On each period
> > > completion, bump a pending counter and wake a consumer kthread from the
> > > DMA callback.
> > >
> > > For every completed period, gather the enabled channels out of the DMA
> > > layout into the scan layout the IIO core expects and push each scan
> > > with iio_push_to_buffers().  
> > 
> > Could you instead use the available_scan_masks infrastructure.  bit annoying
> > to specify the full list but isn't that long I think with 16 channels
> > 
> > 16 x single
> > 8 x double,
> > 4 x quads
> > 2 x octect
> > 1 x all of them.
> > 
> > The the IIO demux in (sits behind the push_to_buffers path if
> > we have available_scan_masks set) will then deal with repacking
> > the data if necessary.
> >   
> 
> Hi Jonathan.
> 
> There are a couple reasons why I haven't used available_scan_masks.
> 
> Our limitation is on the DMA side. It cannot do scatter-gather in a
> single descriptor, and we need to copy all the channels for each
> completion IRQ. This is why we have to copy all the enabled channels
> in a single block, and the base address needs to have the same
> alignment as the block size.
> 
> My initial naive implementation copied all 16 channels (32 bytes) all
> the time, but at that size the DMAC quickly hits a wall where it doesn't
> service the ADC's completion signals anymore, at ~220k requests per
> second.
> 
> Optimizing the DMA window allows us to avoid losing samples when the
> enabled channels are densely packed. Enabling only channel 0 and 15
> still hits the DMAC performance wall though, for example.
> 
> If we were to use available_scan_masks, the ADC would have to enable the
> extra channels too, since it would have no knowledge of whether a
> channel is enabled legitimately or for alignment purposes. The ADC scans
> each channel iteratively, not in parallel, so sampling rate would be
> affected because of the extra enabled channels. Besides that, this would
> be transparent to the user, but it would reuse the last set sampling
> frequency values, which affect the sampling rate without the user even
> knowing.

Ok.  So if this was a common thing I'd suggest we might expose an extra
mask that presents what the various consumers have requested, but I'd
not go to that effort for the first driver that could use it.

> 
> If there are any extra enabled channels, iio_demux() would have to copy
> all the data again. We need to keep our own copy inside the driver to
> unswap the ADC's 16-bit data registers out of each 32-bit word.

Ah. Yes, with a copy already happening might as well make it just one.

> 
> The available_scan_masks table would have to be computed at runtime
> since not all instances of the ADC have 16 channels.

Given these are fairly small, that might just be selection from a set
of options.

> Also the use of
> devm_iio_adc_device_alloc_chaninfo_se() means that we allow gaps in the
> channels themselves. scan_index is set incrementally anyway, so it can
> get out of sync with the channel index, and that would need extra
> handling when building the table.

Ah. That would make life trickier.

> 
> Let me know what you think and what the direction should be.

This info is more than enough to convince me that it isn't worth
using the core demux stuff. Thanks for all the details!

Jonathan