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

["Nuno Sá" <noname.nuno@gmail.com>]

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.

> 
> > 
> > Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
> > ---
> > 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.

- Nuno Sá