RE: [PATCH v4 3/4] iio: adc: ad4691: add triggered buffer support

[Sabau, Radu bogdan]

> -----Original Message-----
> From: Jonathan Cameron <jic23@xxxxxxxxxx>
> Sent: Saturday, March 21, 2026 5:17 PM
> To: Radu Sabau via B4 Relay <devnull+radu.sabau.analog.com@xxxxxxxxxx>
> 
> [External]
> 
> On Fri, 20 Mar 2026 13:03:57 +0200
> Radu Sabau via B4 Relay <devnull+radu.sabau.analog.com@xxxxxxxxxx>
> wrote:
> 
> > From: Radu Sabau <radu.sabau@xxxxxxxxxx>
> >

...

> > tree is configured as DATA_READY output. The IRQ handler stops
> > conversions and fires the IIO trigger; the trigger handler executes a
> > pre-built SPI message that reads all active channels from the AVG_IN
> > accumulator registers and then resets accumulator state and restarts
> > conversions for the next cycle.
> 
> No oversampling configuration?  If it's a fixed length burst I'd still
> expect to see an indication of what it is and if we can flip back to
> no oversampling by changing mode, that should be oversampling == 1.
> Seems there is a depth setting for the averaging filters, that superficially
> at least appears to be the right control for this.
> 
> Seems like there is an SPI burst mode as well?  That feels like very
> standard oversampling.
> 

Hi Jonathan,

You are right! Those depth registers which I wrongly name ACC_COUNT_LIMIT
still (name changed upon chip's release,  I will fix in the next version of the driver)
indeed work as expected.

I verified this using a Logic Analyzer on the SPI signals and GP interrupt to verify
the timing -> GP falls after a longer time if depth is increased -> oversampling is used.

Since this would be a nice addition, I will implement this then in the
next version.

Thank you for this!
Radu

> >
> > Manual Mode: CNV is tied to SPI CS so each transfer simultaneously
> > reads the previous result and starts the next conversion (pipelined
> > N+1 scheme). At preenable time a pre-built, optimised SPI message of
> > N+1 transfers is constructed (N channel reads plus one NOOP to drain
> > the pipeline). The trigger handler executes the message in a single
> > spi_sync() call and collects the results. An external trigger (e.g.
> > iio-trig-hrtimer) is required to drive the trigger at the desired
> > sample rate.
> >