RE: [PATCH v6 4/4] iio: adc: ad4691: add SPI offload support

[Sabau, Radu bogdan]

> -----Original Message-----
> From: David Lechner <dlechner@xxxxxxxxxxxx>
> Sent: Saturday, April 4, 2026 6:34 PM

...

> >
> > Add driver documentation under Documentation/iio/ad4691.rst covering
> > operating modes, oversampling, reference voltage, SPI offload paths,
> > and buffer data layout; register in MAINTAINERS and index.rst
> 
> Documentation should be separate patch. It covers more than just SPI
> offload.
> 

Noted. Thanks for this.

> >
> > Kconfig gains a dependency on IIO_BUFFER_DMAENGINE.
> >
> > Signed-off-by: Radu Sabau <radu.sabau@xxxxxxxxxx>
> > ---

...

> > +Selected when a ``pwms`` property is present in the device tree. The PWM
> drives
> > +the CNV pin independently of SPI at the configured conversion rate, and a
> GP
> > +pin (identified by ``interrupt-names``) asserts DATA_READY at end-of-burst
> to
> > +signal that the AVG_IN result registers are ready to be read.
> > +
> > +The IRQ handler stops the PWM, fires the IIO trigger, and the trigger
> handler
> 
> If we stop the PWM after an IRQ, then we don't get a consistent sample rate.
> Ideally, we would leave the PWM running and just pick a rate slow enough
> that
> there is plenty of time to read the data. Otherwise, this mode doesn't seem
> particularly useful.

Should there also be a condition when setting the sampling frequency, that will
protect from setting too fast sample rates?

> 
> > +reads all active ``AVG_IN(n)`` registers in a single optimised SPI message and
> > +pushes the scan to the buffer.
> > +
> > +The buffer sampling frequency (i.e. the PWM rate) is controlled by the
> > +``sampling_frequency`` attribute on the IIO buffer. Valid values span from
> the
> > +chip's minimum oscillator rate up to its maximum conversion rate
> > +(500 kSPS for AD4691/AD4693, 1 MSPS for AD4692/AD4694).
> 
> Valid, but not usable without SPI offload.

The PWM is also be used with triggered-buffer in CNV Burst Mode.

> 
> > +
> > +Autonomous Mode (idle / single-shot)
> > +-------------------------------------
> > +

...

> > +
> > +Manual offload
> > +--------------
> > +
> > +Used when no ``pwms`` property is present and SPI offload is available.
> > +
> > +A periodic SPI offload trigger controls the conversion rate. On each trigger
> > +period, the SPI engine executes an N+1 transfer message (same pipelined
> scheme
> 
> How does this work with oversampling?

As per previous versions discussions, Manual Mode doesn't support oversampling,
since the chip only transfers the raw unfiltered 16-bit data without register interaction
in this mode.

> 
> > +as software Manual Mode) and streams the data directly to the IIO DMA
> buffer.

...

> > +IIO DMA buffer:
> > +
> > +* **CNV Burst offload**: the SPI engine reads AVG_IN registers with a 2-
> byte
> > +  address phase followed by a 2-byte data phase; the 16-bit result lands in
> > +  the lower half of the 32-bit word (``shift=0``).
> > +* **Manual offload**: each 32-bit SPI word carries the channel byte in the
> > +  first byte; the 16-bit result is returned in the upper half of the 32-bit
> 
> I would expect the "first" byte to be in the "upper half" of the 32-bits as
> well. This layout could be explained better.
> 
> Also, since extra data has to be read in this mode, does this affect the max
> conversion rate?

This is bad documentation on my part. "channel byte" isn't used anymore,
this is previous version behaviour. Right now, only 16-bits worth of actual
channel data are used.

> 
> > +  word (``shift=16``).
> > +
> > +The ``in_voltageN_type`` sysfs attribute reflects the active scan type.
> > +
> > +
> > +Unimplemented features
> > +======================
> > +
> > +* GPIO controller functionality of the GP pins
> > +* Clamp status and overrange events
> > +* Raw accumulator (ACC_IN) and accumulator status registers
> > +* ADC_BUSY and overrun status interrupts