* Re: [PATCH v2 5/5] iio: adc: ad4130: add new supported parts
[not found] ` <9295ce0b3376481bf8530d1c53bb77a70e8761d1.1773311639.git.Jonathan.Santos@analog.com>
@ 2026-03-21 19:08 ` Jonathan Cameron
0 siblings, 0 replies; only message in thread
From: Jonathan Cameron @ 2026-03-21 19:08 UTC (permalink / raw)
To: Jonathan Santos
Cc: linux-iio, linux-kernel, devicetree, lars, Michael.Hennerich,
cosmin.tanislav, dlechner, nuno.sa, andy, robh, krzk+dt, conor+dt
On Mon, 16 Mar 2026 08:45:45 -0300
Jonathan Santos <Jonathan.Santos@analog.com> wrote:
> Add support for AD4129-4/8, AD4130-4, and AD4131-4/8 variants.
>
> The AD4129 series supports the same FIFO interface as the AD4130 but with
> reduced resolution (16-bit). The AD4131 series lacks FIFO support, so
> triggered buffer functionality is introduced.
>
> The 4-channel variants feature fewer analog inputs, GPIOs, and sparse pin
> mappings for VBIAS, analog inputs, and excitation currents. The driver now
> handles these differences with chip-specific configurations, including pin
> mappings and GPIO counts.
>
> Signed-off-by: Jonathan Santos <Jonathan.Santos@analog.com>
Just one additional comment below. Given it is either fifo or the other
path can we share physical storage for the two?
> * DMA (thus cache coherency maintenance) requires any transfer
> @@ -324,6 +395,9 @@ struct ad4130_state {
> u8 fifo_tx_buf[2];
> u8 fifo_rx_buf[AD4130_FIFO_SIZE *
> AD4130_FIFO_MAX_SAMPLE_SIZE];
> +
> + /* Triggered buffer data with timestamp */
> + IIO_DECLARE_DMA_BUFFER_WITH_TS(u32, scan_channels, AD4130_MAX_CHANNELS);
Could we put this in a union with some of the fifo stuff given it seems
to always be a case of using one or the other?
We are already in an area that should be safe for dma due to the aligned
marking some lines up. So to overlap you'd need to use the IIO_DECLARE_BUFFER_WITH_TS()
macro that doesn't force the alignment.
> };
^ permalink raw reply [flat|nested] only message in thread