Re: [PATCH v10 4/6] iio: adc: ad4691: add SPI offload support

[Jonathan Cameron <jic23@kernel.org>]

On Mon, 11 May 2026 14:54:16 +0300
Radu Sabau via B4 Relay <devnull+radu.sabau.analog.com@kernel.org> wrote:

> From: Radu Sabau <radu.sabau@analog.com>
> 
> Add SPI offload support to enable DMA-based, CPU-independent data
> acquisition using the SPI Engine offload framework.
> 
> When an SPI offload is available (devm_spi_offload_get() succeeds),
> the driver registers a DMA engine IIO buffer and uses dedicated buffer
> setup operations. If no offload is available the existing software
> triggered buffer path is used unchanged.
> 
> Both CNV Burst Mode and Manual Mode support offload, but use different
> trigger mechanisms:
> 
> CNV Burst Mode: the SPI Engine is triggered by the ADC's DATA_READY
> signal on the GP pin specified by the trigger-source consumer reference
> in the device tree (one cell = GP pin number 0-3). For this mode the
> driver acts as both an SPI offload consumer (DMA RX stream, message
> optimization) and a trigger source provider: it registers the
> GP/DATA_READY output via devm_spi_offload_trigger_register() so the
> offload framework can match the '#trigger-source-cells' phandle and
> automatically fire the SPI Engine DMA transfer at end-of-conversion.
> 
> Manual Mode: the SPI Engine is triggered by a periodic trigger at
> the configured sampling frequency. The pre-built SPI message uses
> the pipelined CNV-on-CS protocol: N+1 16-bit transfers are issued
> for N active channels (the first result is discarded as garbage from
> the pipeline flush) and the remaining N results are captured by DMA.
> 
> All offload transfers use 16-bit frames (bits_per_word=16, len=2).
> The channel scan_type (storagebits=16, shift=0) is shared between the
> software triggered-buffer and offload paths; no separate scan_type or
> channel array is needed for the offload case at this stage. Oversampling
> support and mode-specific channel array distinctions are introduced in
> the following commit.
> 
> IIO_BUFFER_DMAENGINE is selected because the offload path uses
> devm_iio_dmaengine_buffer_setup_with_handle() to allocate and
> attach the DMA RX buffer to the IIO device.

More stuff from sashiko - it also not noticed the BE marking is
in a later patch - but given you are doing 16bit words here likely
the chan spec needs to be different.

Hohum. It then seems to have timed out.  Maybe that should be a new
rule - if your patch set is too big for sashiko it's too big and
complex for reviewers too ;)

> 
> Signed-off-by: Radu Sabau <radu.sabau@analog.com>

I didn't really spot anything myself on this pass so just a question
of analysing the bot output and groaning at what I missed :(

Jonathan