Re: [RFC PATCH v3 3/5] iio: buffer: Extend DMAengine buffer interfaces to take extra sysfs attributes

[Marcelo Schmitt]

On 06/18, Nuno Sá wrote:
> On Wed, Jun 17, 2026 at 04:43:18PM -0500, David Lechner wrote:
> > On 6/16/26 9:03 PM, Marcelo Schmitt wrote:
> > > Some devices using DMAengine buffers are connected to extra hardware that
> > > allows setting how fast data is transferred to/from the buffer. However,
> > > those extra pieces of harwdware are external to the sensor chip such that
> > > supporting the transfer speed as a sensor property is a bit of an
> > > inaccuracy. Expand IIO DMAengine buffer interfaces to take arguments for
> > > extra sysfs attributes, enabling the transfer speed to be configured
> > > through the buffer interface.
> > 
> > This message is a bit confusing. It sounds like it is attempting to
> > control something about the DMA controller itself. But based on the
> > later patches, it looks like this is just so we can add arbitrary
> > sysfs attributes to the bufferX directory. And in this specific case,
> > a sampling_frequency attribute.
> 
> Agreed. Seems like rate control comes from the buffer.

For this series, that was the actual result. Since we already have extra
sysfs attributes for kfifo and for triggered buffers, I thought of trying it
wish DMAengine buffers as well. The intent is to decouple the sampling frequency
sysfs attributes (which depend on SPI offload and PWM availability) from the ADC
IIO device. And the reason for that is to avoid making the device driver
directly select SPI_OFFLOAD and/or depend on PWM because these devices can be
used without offloading.

> 
> > 
> > > 
> > > Signed-off-by: Marcelo Schmitt <marcelo.schmitt@xxxxxxxxxx>
> > > ---
> > > New patch.
> > > 
> > > Now that I've come to this buffer "solution", I have pretty much convinced
> > > myself it would be better to instead have some sort of IIO trigger to control
> > > the signal source connected to SPI offloading trigger module.
> > > 
> > In the other chips with SPI offload we've done already, we just used
> > IIO_CHAN_INFO_SAMP_FREQ to control the SPI offload trigger rate.
> > Any reason why we can't do that here? In the original SPI offload
> > discussions, IIRC the general consensus was that adding a trigger
> > just to control that was overkill when I suggested the same.
> > 
> 
> I tend to agree with David. Even if we come to a conclusion that we
> can't use IIO_CHAN_INFO_SAMP_FREQ to control the trigger rate, I'm not
> really convinced sysfs interfaces on the buffer itself are the place for
> this.

I understand it might be odd and confusing to have the sampling freq attributes
in the buffer. Using IIO_CHAN_INFO_SAMP_FREQ shall also work for this device
so I'll probably switch to that. Though, an interesting point Jonathan made on
v2 was that some devices have sampling frequency controls natively (e.g. ad7173).
I wonder if having a trigger device would help with the SPI offload dependency
separation. We might avoid attribute name clashing for some devices as bonus.

Thanks,
Marcelo