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

[Sabau, Radu bogdan]

> -----Original Message-----
> From: Jonathan Cameron <jic23@xxxxxxxxxx>
> Sent: Tuesday, May 5, 2026 5:28 PM
> To: Radu Sabau via B4 Relay <devnull+radu.sabau.analog.com@xxxxxxxxxx>
> Cc: Sabau, Radu bogdan <Radu.Sabau@xxxxxxxxxx>; Lars-Peter Clausen
> <lars@xxxxxxxxxx>; Hennerich, Michael <Michael.Hennerich@xxxxxxxxxx>;
> David Lechner <dlechner@xxxxxxxxxxxx>; Sa, Nuno <Nuno.Sa@xxxxxxxxxx>;
> Andy Shevchenko <andy@xxxxxxxxxx>; Rob Herring <robh@xxxxxxxxxx>;
> Krzysztof Kozlowski <krzk+dt@xxxxxxxxxx>; Conor Dooley
> <conor+dt@xxxxxxxxxx>; Uwe Kleine-König <ukleinek@xxxxxxxxxx>; Liam
> Girdwood <lgirdwood@xxxxxxxxx>; Mark Brown <broonie@xxxxxxxxxx>; Linus
> Walleij <linusw@xxxxxxxxxx>; Bartosz Golaszewski <brgl@xxxxxxxxxx>; Philipp
> Zabel <p.zabel@xxxxxxxxxxxxxx>; Jonathan Corbet <corbet@xxxxxxx>; Shuah
> Khan <skhan@xxxxxxxxxxxxxxxxxxx>; linux-iio@xxxxxxxxxxxxxxx;
> devicetree@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; linux-
> pwm@xxxxxxxxxxxxxxx; linux-gpio@xxxxxxxxxxxxxxx; linux-doc@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH v9 4/6] iio: adc: ad4691: add SPI offload support
> 
> [External]
> 
> On Thu, 30 Apr 2026 13:16:46 +0300
> Radu Sabau via B4 Relay <devnull+radu.sabau.analog.com@xxxxxxxxxx>
> wrote:
> 
> > From: Radu Sabau <radu.sabau@xxxxxxxxxx>
> >
> > 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, IIO_BE) is shared
> > between the software triggered-buffer and offload paths; no separate
> > scan_type or channel array is needed for the offload case. The
> > ad4691_manual_channels[] array introduced in the triggered-buffer
> > commit is reused here: it hides the IIO_CHAN_INFO_OVERSAMPLING_RATIO
> > attribute, which is not applicable in Manual Mode.
> >
> > Kconfig gains a dependency on IIO_BUFFER_DMAENGINE.
> >
> > Signed-off-by: Radu Sabau <radu.sabau@xxxxxxxxxx>
> In general have a read through Sashiko reviews once they come in and
> if you agree with them reply to your own patches to say what you are
> changing.
> https://urldefense.com/v3/__https://sashiko.dev/*/patchset/20260430-
> ad4692-multichannel-sar-adc-driver-v9-0-
> 33e439e4fb87*40analog.com__;IyU!!A3Ni8CS0y2Y!-
> G5xU6m5PVXdQJCRVp_OOtLEM0gRiLsoZigLcBOrGi00oHLlyYgtxQAtx7azQuyZ
> Bkv8I3Cgy2WoEg$
> No perfect but another one in here is something I missed completely.
> 
> A few of them called out here but please make sure you've addressed them
> all or established them to be false (which happens!)
> 

Will have a look at Sashiko review in order to address everything in the next
version.
I will also reply to each patch and mention the change, argue to why I think the
raised concern could be false and perhaps have a follow-up discussion here.