[PATCH v6 0/8] Add SPI offload support to AD4030

[PATCH v6 0/8] Add SPI offload support to AD4030

[Marcelo Schmitt]

Hi,

Thanks for all reviews and suggestions to v5.
I believe to have addressed them all and here comes v6.

Change log v5 -> v6
[DT]
- Picked up Conor's review tag.
[IIO]
- Adjusted comment on list of average modes.
- Dropped link associated with Suggested-by tag.
- Fixed IIO device number of channels in base offload support patch for AD4030.
- Dropped st->offload_trigger check in paths only reachable with offload support.
- Adjusted comment about sample averaging and sampling frequency configurations.
- Dropped redundant parentheses on declaration of ADAQ hw gain table.
- Dropped unneeded cast to u64.
- Use constant for number of ADAQ PGA pins in error message.
- Picked up review tags.
- Re-added common-mode channel for offload setups in a separate patch.

There is a patch to the SPI subsystem [1] that contains a feature required by
AD4030 offload support.

[1]: https://lore.kernel.org/linux-spi/cd315e95c0bd8523f00e91c400abcd6a418e5924.1759760519.git.marcelo.schmitt@analog.com/

When that patch become available in an immutable branch or similar, I'll gladly
rebase this series on top of that.

Thanks,
Marcelo


Marcelo Schmitt (8):
  dt-bindings: iio: adc: adi,ad4030: Reference spi-peripheral-props
  Docs: iio: ad4030: Add double PWM SPI offload doc
  dt-bindings: iio: adc: adi,ad4030: Add PWM
  iio: adc: ad4030: Use BIT macro to improve code readability
  iio: adc: ad4030: Add SPI offload support
  dt-bindings: iio: adc: adi,ad4030: Add ADAQ4216 and ADAQ4224
  iio: adc: ad4030: Add support for ADAQ4216 and ADAQ4224
  iio: adc: ad4030: Support common-mode channels with SPI offloading

 .../bindings/iio/adc/adi,ad4030.yaml          |  76 +-
 Documentation/iio/ad4030.rst                  |  39 ++
 drivers/iio/adc/Kconfig                       |   5 +
 drivers/iio/adc/ad4030.c                      | 658 +++++++++++++++++-
 4 files changed, 753 insertions(+), 25 deletions(-)


base-commit: 4b17a60d1e1c2d9d2ccbd58642f6f4ac2fa364ba
-- 
2.39.2

[PATCH v6 1/8] dt-bindings: iio: adc: adi,ad4030: Reference spi-peripheral-props

[Marcelo Schmitt]

AD4030 and similar devices all connect to the system as SPI peripherals.
Reference spi-peripheral-props so common SPI peripheral can be used from
ad4030 dt-binding.

Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
---
 Documentation/devicetree/bindings/iio/adc/adi,ad4030.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad4030.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad4030.yaml
index 54e7349317b7..a8fee4062d0e 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad4030.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad4030.yaml
@@ -20,6 +20,8 @@ description: |
   * https://www.analog.com/media/en/technical-documentation/data-sheets/ad4630-24_ad4632-24.pdf
   * https://www.analog.com/media/en/technical-documentation/data-sheets/ad4630-16-4632-16.pdf
 
+$ref: /schemas/spi/spi-peripheral-props.yaml#
+
 properties:
   compatible:
     enum:
-- 
2.39.2

[PATCH v6 2/8] Docs: iio: ad4030: Add double PWM SPI offload doc

[Marcelo Schmitt]

Document double PWM setup SPI offload wiring schema.

Reviewed-by: David Lechner <dlechner@baylibre.com>
Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
---
 Documentation/iio/ad4030.rst | 39 ++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/Documentation/iio/ad4030.rst b/Documentation/iio/ad4030.rst
index b57424b650a8..9caafa4148b0 100644
--- a/Documentation/iio/ad4030.rst
+++ b/Documentation/iio/ad4030.rst
@@ -92,6 +92,45 @@ Interleaved mode
 In this mode, both channels conversion results are bit interleaved one SDO line.
 As such the wiring is the same as `One lane mode`_.
 
+SPI offload wiring
+^^^^^^^^^^^^^^^^^^
+
+.. code-block::
+
+    +-------------+         +-------------+
+    |         CNV |<-----+--| GPIO        |
+    |             |      +--| PWM0        |
+    |             |         |             |
+    |             |      +--| PWM1        |
+    |             |      |  +-------------+
+    |             |      +->| TRIGGER     |
+    |          CS |<--------| CS          |
+    |             |         |             |
+    |     ADC     |         |     SPI     |
+    |             |         |             |
+    |         SDI |<--------| SDO         |
+    |         SDO |-------->| SDI         |
+    |        SCLK |<--------| SCLK        |
+    +-------------+         +-------------+
+
+In this mode, both the ``cnv-gpios`` and a ``pwms`` properties are required.
+The ``pwms`` property specifies the PWM that is connected to the ADC CNV pin.
+The SPI offload will have a ``trigger-sources`` property to indicate the SPI
+offload (PWM) trigger source. For AD4030 and similar ADCs, there are two
+possible data transfer zones for sample N. One of them (zone 1) starts after the
+data conversion for sample N is complete while the other one (zone 2) starts 9.8
+nanoseconds after the rising edge of CNV for sample N + 1.
+
+The configuration depicted in the above diagram is intended to perform data
+transfer in zone 2. To achieve high sample rates while meeting ADC timing
+requirements, an offset is added between the rising edges of PWM0 and PWM1 to
+delay the SPI transfer until 9.8 nanoseconds after CNV rising edge. This
+requires a specialized PWM controller that can provide such an offset.
+The `AD4630-FMC HDL project`_, for example, can be configured to sample AD4030
+data during zone 2 data read window.
+
+.. _AD4630-FMC HDL project: https://analogdevicesinc.github.io/hdl/projects/ad4630_fmc/index.html
+
 SPI Clock mode
 --------------
 
-- 
2.39.2

[PATCH v6 3/8] dt-bindings: iio: adc: adi,ad4030: Add PWM

[Marcelo Schmitt]

In setups designed for high speed data rate capture, a PWM is used to
generate the CNV signal that issues data captures from the ADC. Document
the use of a PWM for AD4030 and similar devices.

Reviewed-by: David Lechner <dlechner@baylibre.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
---
 Documentation/devicetree/bindings/iio/adc/adi,ad4030.yaml | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad4030.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad4030.yaml
index a8fee4062d0e..564b6f67a96e 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad4030.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad4030.yaml
@@ -64,6 +64,10 @@ properties:
       The Reset Input (/RST). Used for asynchronous device reset.
     maxItems: 1
 
+  pwms:
+    description: PWM signal connected to the CNV pin.
+    maxItems: 1
+
   interrupts:
     description:
       The BUSY pin is used to signal that the conversions results are available
-- 
2.39.2

[PATCH v6 4/8] iio: adc: ad4030: Use BIT macro to improve code readability

[Marcelo Schmitt]

Use BIT macro to make the list of average modes more readable.

Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
---
Change log v5 -> v6
- Adjusted comment on list of average modes.
- Dropped link associated with Suggested-by tag.

 drivers/iio/adc/ad4030.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/iio/adc/ad4030.c b/drivers/iio/adc/ad4030.c
index 4393160c7c77..e413003f1a17 100644
--- a/drivers/iio/adc/ad4030.c
+++ b/drivers/iio/adc/ad4030.c
@@ -232,10 +232,16 @@ struct ad4030_state {
 	.num_ext_scan_type = ARRAY_SIZE(_scan_type),			\
 }
 
+/*
+ * AD4030 can average over 2^N samples, where N = 1, 2, 3, ..., 16.
+ * We use N = 0 to mean no sample averaging.
+ */
 static const int ad4030_average_modes[] = {
-	1, 2, 4, 8, 16, 32, 64, 128,
-	256, 512, 1024, 2048, 4096, 8192, 16384, 32768,
-	65536,
+	BIT(0),
+	BIT(1), BIT(2), BIT(3), BIT(4),
+	BIT(5), BIT(6), BIT(7), BIT(8),
+	BIT(9), BIT(10), BIT(11), BIT(12),
+	BIT(13), BIT(14), BIT(15), BIT(16),
 };
 
 static int ad4030_enter_config_mode(struct ad4030_state *st)
-- 
2.39.2

[PATCH v6 5/8] iio: adc: ad4030: Add SPI offload support

[Marcelo Schmitt]

AD4030 and similar ADCs can capture data at sample rates up to 2 mega
samples per second (MSPS). Not all SPI controllers are able to achieve such
high throughputs and even when the controller is fast enough to run
transfers at the required speed, it may be costly to the CPU to handle
transfer data at such high sample rates. Add SPI offload support for AD4030
and similar ADCs to enable data capture at maximum sample rates.

Reviewed-by: David Lechner <dlechner@baylibre.com>
Co-developed-by: Trevor Gamblin <tgamblin@baylibre.com>
Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>
Co-developed-by: Axel Haslam <ahaslam@baylibre.com>
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
---
Change log v5 -> v6
- Fixed IIO device number of channels.
- Dropped st->offload_trigger check in paths only reachable with offload support.
- Adjusted comment about sample averaging and sampling frequency configurations.

 drivers/iio/adc/Kconfig  |   5 +
 drivers/iio/adc/ad4030.c | 414 +++++++++++++++++++++++++++++++++++++--
 2 files changed, 405 insertions(+), 14 deletions(-)

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index b0580fcefef5..f76df0609b3d 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -60,9 +60,14 @@ config AD4030
 	tristate "Analog Devices AD4030 ADC Driver"
 	depends on SPI
 	depends on GPIOLIB
+	depends on PWM
 	select REGMAP
 	select IIO_BUFFER
+	select IIO_BUFFER_DMA
+	select IIO_BUFFER_DMAENGINE
 	select IIO_TRIGGERED_BUFFER
+	select SPI_OFFLOAD
+	select SPI_OFFLOAD_TRIGGER_PWM
 	help
 	  Say yes here to build support for Analog Devices AD4030 and AD4630 high speed
 	  SPI analog to digital converters (ADC).
diff --git a/drivers/iio/adc/ad4030.c b/drivers/iio/adc/ad4030.c
index e413003f1a17..08f06ffb6b21 100644
--- a/drivers/iio/adc/ad4030.c
+++ b/drivers/iio/adc/ad4030.c
@@ -14,15 +14,25 @@
  */
 
 #include <linux/bitfield.h>
+#include <linux/cleanup.h>
 #include <linux/clk.h>
+#include <linux/dmaengine.h>
+#include <linux/iio/buffer-dmaengine.h>
 #include <linux/iio/iio.h>
 #include <linux/iio/trigger_consumer.h>
 #include <linux/iio/triggered_buffer.h>
+#include <linux/limits.h>
+#include <linux/log2.h>
+#include <linux/math64.h>
+#include <linux/minmax.h>
+#include <linux/pwm.h>
 #include <linux/regmap.h>
 #include <linux/regulator/consumer.h>
+#include <linux/spi/offload/consumer.h>
 #include <linux/spi/spi.h>
 #include <linux/unaligned.h>
 #include <linux/units.h>
+#include <linux/types.h>
 
 #define AD4030_REG_INTERFACE_CONFIG_A			0x00
 #define     AD4030_REG_INTERFACE_CONFIG_A_SW_RESET	(BIT(0) | BIT(7))
@@ -111,6 +121,8 @@
 #define AD4632_TCYC_NS			2000
 #define AD4632_TCYC_ADJUSTED_NS		(AD4632_TCYC_NS - AD4030_TCNVL_NS)
 #define AD4030_TRESET_COM_DELAY_MS	750
+/* Datasheet says 9.8ns, so use the closest integer value */
+#define AD4030_TQUIET_CNV_DELAY_NS	10
 
 enum ad4030_out_mode {
 	AD4030_OUT_DATA_MD_DIFF,
@@ -136,11 +148,13 @@ struct ad4030_chip_info {
 	const char *name;
 	const unsigned long *available_masks;
 	const struct iio_chan_spec channels[AD4030_MAX_IIO_CHANNEL_NB];
+	const struct iio_chan_spec offload_channels[AD4030_MAX_IIO_CHANNEL_NB];
 	u8 grade;
 	u8 precision_bits;
 	/* Number of hardware channels */
 	int num_voltage_inputs;
 	unsigned int tcyc_ns;
+	unsigned int max_sample_rate_hz;
 };
 
 struct ad4030_state {
@@ -153,6 +167,14 @@ struct ad4030_state {
 	int offset_avail[3];
 	unsigned int avg_log2;
 	enum ad4030_out_mode mode;
+	/* Offload sampling */
+	struct spi_transfer offload_xfer;
+	struct spi_message offload_msg;
+	struct spi_offload *offload;
+	struct spi_offload_trigger *offload_trigger;
+	struct spi_offload_trigger_config offload_trigger_config;
+	struct pwm_device *cnv_trigger;
+	struct pwm_waveform cnv_wf;
 
 	/*
 	 * DMA (thus cache coherency maintenance) requires the transfer buffers
@@ -209,8 +231,9 @@ struct ad4030_state {
  * - voltage0-voltage1
  * - voltage2-voltage3
  */
-#define AD4030_CHAN_DIFF(_idx, _scan_type) {				\
+#define __AD4030_CHAN_DIFF(_idx, _scan_type, _offload) {		\
 	.info_mask_shared_by_all =					\
+		(_offload ? BIT(IIO_CHAN_INFO_SAMP_FREQ) : 0) |		\
 		BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO),			\
 	.info_mask_shared_by_all_available =				\
 		BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO),			\
@@ -232,6 +255,12 @@ struct ad4030_state {
 	.num_ext_scan_type = ARRAY_SIZE(_scan_type),			\
 }
 
+#define AD4030_CHAN_DIFF(_idx, _scan_type)				\
+	__AD4030_CHAN_DIFF(_idx, _scan_type, 0)
+
+#define AD4030_OFFLOAD_CHAN_DIFF(_idx, _scan_type)			\
+	__AD4030_CHAN_DIFF(_idx, _scan_type, 1)
+
 /*
  * AD4030 can average over 2^N samples, where N = 1, 2, 3, ..., 16.
  * We use N = 0 to mean no sample averaging.
@@ -244,6 +273,11 @@ static const int ad4030_average_modes[] = {
 	BIT(13), BIT(14), BIT(15), BIT(16),
 };
 
+static const struct spi_offload_config ad4030_offload_config = {
+	.capability_flags = SPI_OFFLOAD_CAP_TRIGGER |
+			    SPI_OFFLOAD_CAP_RX_STREAM_DMA,
+};
+
 static int ad4030_enter_config_mode(struct ad4030_state *st)
 {
 	st->tx_data[0] = AD4030_REG_ACCESS;
@@ -457,6 +491,96 @@ static int ad4030_get_chan_calibbias(struct iio_dev *indio_dev,
 	}
 }
 
+static void ad4030_get_sampling_freq(struct ad4030_state *st, int *freq)
+{
+	struct spi_offload_trigger_config *config = &st->offload_trigger_config;
+
+	/*
+	 * Conversion data is fetched from the device when the offload transfer
+	 * is triggered. Thus, provide the SPI offload trigger frequency as the
+	 * sampling frequency.
+	 */
+	*freq = config->periodic.frequency_hz;
+}
+
+static int ad4030_update_conversion_rate(struct ad4030_state *st,
+					 unsigned int freq_hz, unsigned int avg_log2)
+{
+	struct spi_offload_trigger_config *config = &st->offload_trigger_config;
+	struct pwm_waveform cnv_wf = { };
+	u64 target = AD4030_TCNVH_NS;
+	unsigned int cnv_rate_hz;
+	u64 offload_period_ns;
+	u64 offload_offset_ns;
+	int ret;
+
+	/*
+	 * When averaging/oversampling over N samples, we fire the offload
+	 * trigger once at every N pulses of the CNV signal. Conversely, the CNV
+	 * signal needs to be N times faster than the offload trigger. Take that
+	 * into account to correctly re-evaluate both the PWM waveform connected
+	 * to CNV and the SPI offload trigger.
+	 */
+	cnv_rate_hz = freq_hz << avg_log2;
+
+	cnv_wf.period_length_ns = DIV_ROUND_CLOSEST(NSEC_PER_SEC, cnv_rate_hz);
+	/*
+	 * The datasheet lists a minimum time of 9.8 ns, but no maximum. If the
+	 * rounded PWM's value is less than 10, increase the target value by 10
+	 * and attempt to round the waveform again, until the value is at least
+	 * 10 ns. Use a separate variable to represent the target in case the
+	 * rounding is severe enough to keep putting the first few results under
+	 * the minimum 10ns condition checked by the while loop.
+	 */
+	do {
+		cnv_wf.duty_length_ns = target;
+		ret = pwm_round_waveform_might_sleep(st->cnv_trigger, &cnv_wf);
+		if (ret)
+			return ret;
+		target += AD4030_TCNVH_NS;
+	} while (cnv_wf.duty_length_ns < AD4030_TCNVH_NS);
+
+	if (!in_range(cnv_wf.period_length_ns, AD4030_TCYC_NS, INT_MAX))
+		return -EINVAL;
+
+	offload_period_ns = DIV_ROUND_CLOSEST(NSEC_PER_SEC, freq_hz);
+
+	config->periodic.frequency_hz = DIV_ROUND_UP_ULL(NSEC_PER_SEC,
+							 offload_period_ns);
+
+	/*
+	 * The hardware does the capture on zone 2 (when SPI trigger PWM
+	 * is used). This means that the SPI trigger signal should happen at
+	 * tsync + tquiet_con_delay being tsync the conversion signal period
+	 * and tquiet_con_delay 9.8ns. Hence set the PWM phase accordingly.
+	 *
+	 * The PWM waveform API only supports nanosecond resolution right now,
+	 * so round this setting to the closest available value.
+	 */
+	offload_offset_ns = AD4030_TQUIET_CNV_DELAY_NS;
+	do {
+		config->periodic.offset_ns = offload_offset_ns;
+		ret = spi_offload_trigger_validate(st->offload_trigger, config);
+		if (ret)
+			return ret;
+		offload_offset_ns += AD4030_TQUIET_CNV_DELAY_NS;
+	} while (config->periodic.offset_ns < AD4030_TQUIET_CNV_DELAY_NS);
+
+	st->cnv_wf = cnv_wf;
+
+	return 0;
+}
+
+static int ad4030_set_sampling_freq(struct iio_dev *indio_dev, int freq_hz)
+{
+	struct ad4030_state *st = iio_priv(indio_dev);
+
+	if (!in_range(freq_hz, 1, st->chip->max_sample_rate_hz))
+		return -EINVAL;
+
+	return ad4030_update_conversion_rate(st, freq_hz, st->avg_log2);
+}
+
 static int ad4030_set_chan_calibscale(struct iio_dev *indio_dev,
 				      struct iio_chan_spec const *chan,
 				      int gain_int,
@@ -516,11 +640,30 @@ static int ad4030_set_avg_frame_len(struct iio_dev *dev, int avg_val)
 	struct ad4030_state *st = iio_priv(dev);
 	unsigned int avg_log2 = ilog2(avg_val);
 	unsigned int last_avg_idx = ARRAY_SIZE(ad4030_average_modes) - 1;
+	int freq_hz;
 	int ret;
 
 	if (avg_val < 0 || avg_val > ad4030_average_modes[last_avg_idx])
 		return -EINVAL;
 
+	if (st->offload_trigger) {
+		/*
+		 * The sample averaging and sampling frequency configurations
+		 * are mutually dependent on each other. That's because the
+		 * effective data sample rate is fCNV / 2^N, where N is the
+		 * number of samples being averaged.
+		 *
+		 * When SPI offload is supported and we have control over the
+		 * sample rate, the conversion start signal (CNV) and the SPI
+		 * offload trigger frequencies must be re-evaluated so data is
+		 * fetched only after 'avg_val' conversions.
+		 */
+		ad4030_get_sampling_freq(st, &freq_hz);
+		ret = ad4030_update_conversion_rate(st, freq_hz, avg_log2);
+		if (ret)
+			return ret;
+	}
+
 	ret = regmap_write(st->regmap, AD4030_REG_AVG,
 			   AD4030_REG_AVG_MASK_AVG_SYNC |
 			   FIELD_PREP(AD4030_REG_AVG_MASK_AVG_VAL, avg_log2));
@@ -773,6 +916,10 @@ static int ad4030_read_raw_dispatch(struct iio_dev *indio_dev,
 		*val = BIT(st->avg_log2);
 		return IIO_VAL_INT;
 
+	case IIO_CHAN_INFO_SAMP_FREQ:
+		ad4030_get_sampling_freq(st, val);
+		return IIO_VAL_INT;
+
 	default:
 		return -EINVAL;
 	}
@@ -813,6 +960,9 @@ static int ad4030_write_raw_dispatch(struct iio_dev *indio_dev,
 	case IIO_CHAN_INFO_OVERSAMPLING_RATIO:
 		return ad4030_set_avg_frame_len(indio_dev, val);
 
+	case IIO_CHAN_INFO_SAMP_FREQ:
+		return ad4030_set_sampling_freq(indio_dev, val);
+
 	default:
 		return -EINVAL;
 	}
@@ -902,6 +1052,104 @@ static const struct iio_buffer_setup_ops ad4030_buffer_setup_ops = {
 	.validate_scan_mask = ad4030_validate_scan_mask,
 };
 
+static void ad4030_prepare_offload_msg(struct iio_dev *indio_dev)
+{
+	struct ad4030_state *st = iio_priv(indio_dev);
+	u8 offload_bpw;
+
+	if (st->mode == AD4030_OUT_DATA_MD_30_AVERAGED_DIFF)
+		offload_bpw = 32;
+	else
+		offload_bpw = st->chip->precision_bits;
+
+	st->offload_xfer.bits_per_word = offload_bpw;
+	st->offload_xfer.len = spi_bpw_to_bytes(offload_bpw);
+	st->offload_xfer.offload_flags = SPI_OFFLOAD_XFER_RX_STREAM;
+	spi_message_init_with_transfers(&st->offload_msg, &st->offload_xfer, 1);
+}
+
+static int ad4030_offload_buffer_postenable(struct iio_dev *indio_dev)
+{
+	struct ad4030_state *st = iio_priv(indio_dev);
+	unsigned int reg_modes;
+	int ret, ret2;
+
+	/*
+	 * When data from 2 analog input channels is output through a single
+	 * bus line (interleaved mode (LANE_MD == 0b11)) and gets pushed through
+	 * DMA, extra hardware is required to do the de-interleaving. While we
+	 * don't support such hardware configurations, disallow interleaved mode
+	 * when using SPI offload.
+	 */
+	ret = regmap_read(st->regmap, AD4030_REG_MODES, &reg_modes);
+	if (ret)
+		return ret;
+
+	if (st->chip->num_voltage_inputs > 1 &&
+	    FIELD_GET(AD4030_REG_MODES_MASK_LANE_MODE, reg_modes) == AD4030_LANE_MD_INTERLEAVED)
+		return -EINVAL;
+
+	ret = ad4030_exit_config_mode(st);
+	if (ret)
+		return ret;
+
+	ad4030_prepare_offload_msg(indio_dev);
+	st->offload_msg.offload = st->offload;
+	ret = spi_optimize_message(st->spi, &st->offload_msg);
+	if (ret)
+		goto out_reset_mode;
+
+	ret = pwm_set_waveform_might_sleep(st->cnv_trigger, &st->cnv_wf, false);
+	if (ret)
+		goto out_unoptimize;
+
+	ret = spi_offload_trigger_enable(st->offload, st->offload_trigger,
+					 &st->offload_trigger_config);
+	if (ret)
+		goto out_pwm_disable;
+
+	return 0;
+
+out_pwm_disable:
+	pwm_disable(st->cnv_trigger);
+out_unoptimize:
+	spi_unoptimize_message(&st->offload_msg);
+out_reset_mode:
+	/* reenter register configuration mode */
+	ret2 = ad4030_enter_config_mode(st);
+	if (ret2)
+		dev_err(&st->spi->dev,
+			"couldn't reenter register configuration mode: %d\n",
+			ret2);
+
+	return ret;
+}
+
+static int ad4030_offload_buffer_predisable(struct iio_dev *indio_dev)
+{
+	struct ad4030_state *st = iio_priv(indio_dev);
+	int ret;
+
+	spi_offload_trigger_disable(st->offload, st->offload_trigger);
+
+	pwm_disable(st->cnv_trigger);
+
+	spi_unoptimize_message(&st->offload_msg);
+
+	/* reenter register configuration mode */
+	ret = ad4030_enter_config_mode(st);
+	if (ret)
+		dev_err(&st->spi->dev,
+			"couldn't reenter register configuration mode\n");
+
+	return ret;
+}
+
+static const struct iio_buffer_setup_ops ad4030_offload_buffer_setup_ops = {
+	.postenable = &ad4030_offload_buffer_postenable,
+	.predisable = &ad4030_offload_buffer_predisable,
+};
+
 static int ad4030_regulators_get(struct ad4030_state *st)
 {
 	struct device *dev = &st->spi->dev;
@@ -971,6 +1219,24 @@ static int ad4030_detect_chip_info(const struct ad4030_state *st)
 	return 0;
 }
 
+static int ad4030_pwm_get(struct ad4030_state *st)
+{
+	struct device *dev = &st->spi->dev;
+
+	st->cnv_trigger = devm_pwm_get(dev, NULL);
+	if (IS_ERR(st->cnv_trigger))
+		return dev_err_probe(dev, PTR_ERR(st->cnv_trigger),
+				     "Failed to get CNV PWM\n");
+
+	/*
+	 * Preemptively disable the PWM, since we only want to enable it with
+	 * the buffer.
+	 */
+	pwm_disable(st->cnv_trigger);
+
+	return 0;
+}
+
 static int ad4030_config(struct ad4030_state *st)
 {
 	int ret;
@@ -998,6 +1264,31 @@ static int ad4030_config(struct ad4030_state *st)
 	return 0;
 }
 
+static int ad4030_spi_offload_setup(struct iio_dev *indio_dev,
+				    struct ad4030_state *st)
+{
+	struct device *dev = &st->spi->dev;
+	struct dma_chan *rx_dma;
+
+	indio_dev->setup_ops = &ad4030_offload_buffer_setup_ops;
+
+	st->offload_trigger = devm_spi_offload_trigger_get(dev, st->offload,
+							   SPI_OFFLOAD_TRIGGER_PERIODIC);
+	if (IS_ERR(st->offload_trigger))
+		return dev_err_probe(dev, PTR_ERR(st->offload_trigger),
+				     "failed to get offload trigger\n");
+
+	st->offload_trigger_config.type = SPI_OFFLOAD_TRIGGER_PERIODIC;
+
+	rx_dma = devm_spi_offload_rx_stream_request_dma_chan(dev, st->offload);
+	if (IS_ERR(rx_dma))
+		return dev_err_probe(dev, PTR_ERR(rx_dma),
+				     "failed to get offload RX DMA\n");
+
+	return devm_iio_dmaengine_buffer_setup_with_handle(dev, indio_dev, rx_dma,
+							   IIO_BUFFER_DIRECTION_IN);
+}
+
 static int ad4030_probe(struct spi_device *spi)
 {
 	struct device *dev = &spi->dev;
@@ -1049,24 +1340,60 @@ static int ad4030_probe(struct spi_device *spi)
 		return dev_err_probe(dev, PTR_ERR(st->cnv_gpio),
 				     "Failed to get cnv gpio\n");
 
-	/*
-	 * One hardware channel is split in two software channels when using
-	 * common byte mode. Add one more channel for the timestamp.
-	 */
-	indio_dev->num_channels = 2 * st->chip->num_voltage_inputs + 1;
 	indio_dev->name = st->chip->name;
 	indio_dev->modes = INDIO_DIRECT_MODE;
 	indio_dev->info = &ad4030_iio_info;
-	indio_dev->channels = st->chip->channels;
 	indio_dev->available_scan_masks = st->chip->available_masks;
 
-	ret = devm_iio_triggered_buffer_setup(dev, indio_dev,
-					      iio_pollfunc_store_time,
-					      ad4030_trigger_handler,
-					      &ad4030_buffer_setup_ops);
-	if (ret)
-		return dev_err_probe(dev, ret,
-				     "Failed to setup triggered buffer\n");
+	st->offload = devm_spi_offload_get(dev, spi, &ad4030_offload_config);
+	ret = PTR_ERR_OR_ZERO(st->offload);
+	if (ret && ret != -ENODEV)
+		return dev_err_probe(dev, ret, "failed to get offload\n");
+
+	/* Fall back to low speed usage when no SPI offload is available. */
+	if (ret == -ENODEV) {
+		/*
+		 * One hardware channel is split in two software channels when
+		 * using common byte mode. Add one more channel for the timestamp.
+		 */
+		indio_dev->num_channels = 2 * st->chip->num_voltage_inputs + 1;
+		indio_dev->channels = st->chip->channels;
+
+		ret = devm_iio_triggered_buffer_setup(dev, indio_dev,
+						      iio_pollfunc_store_time,
+						      ad4030_trigger_handler,
+						      &ad4030_buffer_setup_ops);
+		if (ret)
+			return dev_err_probe(dev, ret,
+					     "Failed to setup triggered buffer\n");
+	} else {
+		/*
+		 * Offloaded SPI transfers can't support software timestamp so
+		 * no additional timestamp channel is added.
+		 */
+		indio_dev->num_channels = st->chip->num_voltage_inputs;
+		indio_dev->channels = st->chip->offload_channels;
+		ret = ad4030_spi_offload_setup(indio_dev, st);
+		if (ret)
+			return dev_err_probe(dev, ret,
+					     "Failed to setup SPI offload\n");
+
+		ret = ad4030_pwm_get(st);
+		if (ret)
+			return dev_err_probe(&spi->dev, ret,
+					     "Failed to get PWM: %d\n", ret);
+
+		/*
+		 * Start with a slower sampling rate so there is some room for
+		 * adjusting the sample averaging and the sampling frequency
+		 * without hitting the maximum conversion rate.
+		 */
+		ret = ad4030_update_conversion_rate(st, st->chip->max_sample_rate_hz >> 4,
+						    st->avg_log2);
+		if (ret)
+			return dev_err_probe(&spi->dev, ret,
+					     "Failed to set offload samp freq\n");
+	}
 
 	return devm_iio_device_register(dev, indio_dev);
 }
@@ -1104,6 +1431,23 @@ static const struct iio_scan_type ad4030_24_scan_types[] = {
 	},
 };
 
+static const struct iio_scan_type ad4030_24_offload_scan_types[] = {
+	[AD4030_SCAN_TYPE_NORMAL] = {
+		.sign = 's',
+		.storagebits = 32,
+		.realbits = 24,
+		.shift = 0,
+		.endianness = IIO_CPU,
+	},
+	[AD4030_SCAN_TYPE_AVG] = {
+		.sign = 's',
+		.storagebits = 32,
+		.realbits = 30,
+		.shift = 2,
+		.endianness = IIO_CPU,
+	},
+};
+
 static const struct iio_scan_type ad4030_16_scan_types[] = {
 	[AD4030_SCAN_TYPE_NORMAL] = {
 		.sign = 's',
@@ -1121,6 +1465,23 @@ static const struct iio_scan_type ad4030_16_scan_types[] = {
 	}
 };
 
+static const struct iio_scan_type ad4030_16_offload_scan_types[] = {
+	[AD4030_SCAN_TYPE_NORMAL] = {
+		.sign = 's',
+		.storagebits = 32,
+		.realbits = 16,
+		.shift = 0,
+		.endianness = IIO_CPU,
+	},
+	[AD4030_SCAN_TYPE_AVG] = {
+		.sign = 's',
+		.storagebits = 32,
+		.realbits = 30,
+		.shift = 2,
+		.endianness = IIO_CPU,
+	},
+};
+
 static const struct ad4030_chip_info ad4030_24_chip_info = {
 	.name = "ad4030-24",
 	.available_masks = ad4030_channel_masks,
@@ -1129,10 +1490,14 @@ static const struct ad4030_chip_info ad4030_24_chip_info = {
 		AD4030_CHAN_CMO(1, 0),
 		IIO_CHAN_SOFT_TIMESTAMP(2),
 	},
+	.offload_channels = {
+		AD4030_OFFLOAD_CHAN_DIFF(0, ad4030_24_offload_scan_types),
+	},
 	.grade = AD4030_REG_CHIP_GRADE_AD4030_24_GRADE,
 	.precision_bits = 24,
 	.num_voltage_inputs = 1,
 	.tcyc_ns = AD4030_TCYC_ADJUSTED_NS,
+	.max_sample_rate_hz = 2 * HZ_PER_MHZ,
 };
 
 static const struct ad4030_chip_info ad4630_16_chip_info = {
@@ -1145,10 +1510,15 @@ static const struct ad4030_chip_info ad4630_16_chip_info = {
 		AD4030_CHAN_CMO(3, 1),
 		IIO_CHAN_SOFT_TIMESTAMP(4),
 	},
+	.offload_channels = {
+		AD4030_OFFLOAD_CHAN_DIFF(0, ad4030_16_offload_scan_types),
+		AD4030_OFFLOAD_CHAN_DIFF(1, ad4030_16_offload_scan_types),
+	},
 	.grade = AD4030_REG_CHIP_GRADE_AD4630_16_GRADE,
 	.precision_bits = 16,
 	.num_voltage_inputs = 2,
 	.tcyc_ns = AD4030_TCYC_ADJUSTED_NS,
+	.max_sample_rate_hz = 2 * HZ_PER_MHZ,
 };
 
 static const struct ad4030_chip_info ad4630_24_chip_info = {
@@ -1161,10 +1531,15 @@ static const struct ad4030_chip_info ad4630_24_chip_info = {
 		AD4030_CHAN_CMO(3, 1),
 		IIO_CHAN_SOFT_TIMESTAMP(4),
 	},
+	.offload_channels = {
+		AD4030_OFFLOAD_CHAN_DIFF(0, ad4030_24_offload_scan_types),
+		AD4030_OFFLOAD_CHAN_DIFF(1, ad4030_24_offload_scan_types),
+	},
 	.grade = AD4030_REG_CHIP_GRADE_AD4630_24_GRADE,
 	.precision_bits = 24,
 	.num_voltage_inputs = 2,
 	.tcyc_ns = AD4030_TCYC_ADJUSTED_NS,
+	.max_sample_rate_hz = 2 * HZ_PER_MHZ,
 };
 
 static const struct ad4030_chip_info ad4632_16_chip_info = {
@@ -1177,10 +1552,15 @@ static const struct ad4030_chip_info ad4632_16_chip_info = {
 		AD4030_CHAN_CMO(3, 1),
 		IIO_CHAN_SOFT_TIMESTAMP(4),
 	},
+	.offload_channels = {
+		AD4030_OFFLOAD_CHAN_DIFF(0, ad4030_16_offload_scan_types),
+		AD4030_OFFLOAD_CHAN_DIFF(1, ad4030_16_offload_scan_types),
+	},
 	.grade = AD4030_REG_CHIP_GRADE_AD4632_16_GRADE,
 	.precision_bits = 16,
 	.num_voltage_inputs = 2,
 	.tcyc_ns = AD4632_TCYC_ADJUSTED_NS,
+	.max_sample_rate_hz = 500 * HZ_PER_KHZ,
 };
 
 static const struct ad4030_chip_info ad4632_24_chip_info = {
@@ -1193,10 +1573,15 @@ static const struct ad4030_chip_info ad4632_24_chip_info = {
 		AD4030_CHAN_CMO(3, 1),
 		IIO_CHAN_SOFT_TIMESTAMP(4),
 	},
+	.offload_channels = {
+		AD4030_OFFLOAD_CHAN_DIFF(0, ad4030_24_offload_scan_types),
+		AD4030_OFFLOAD_CHAN_DIFF(1, ad4030_24_offload_scan_types),
+	},
 	.grade = AD4030_REG_CHIP_GRADE_AD4632_24_GRADE,
 	.precision_bits = 24,
 	.num_voltage_inputs = 2,
 	.tcyc_ns = AD4632_TCYC_ADJUSTED_NS,
+	.max_sample_rate_hz = 500 * HZ_PER_KHZ,
 };
 
 static const struct spi_device_id ad4030_id_table[] = {
@@ -1232,3 +1617,4 @@ module_spi_driver(ad4030_driver);
 MODULE_AUTHOR("Esteban Blanc <eblanc@baylibre.com>");
 MODULE_DESCRIPTION("Analog Devices AD4630 ADC family driver");
 MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("IIO_DMAENGINE_BUFFER");
-- 
2.39.2

[PATCH v6 6/8] dt-bindings: iio: adc: adi,ad4030: Add ADAQ4216 and ADAQ4224

[Marcelo Schmitt]

ADAQ4216 and ADAQ4224 are similar to AD4030 except that ADAQ devices have a
PGA (programmable gain amplifier) that scales the input signal prior to it
reaching the ADC inputs. The PGA is controlled through a couple of pins (A0
and A1) that set one of four possible signal gain configurations.

Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
---
Change log v5 -> v6
- Picked up Conor's review tag.

 .../bindings/iio/adc/adi,ad4030.yaml          | 70 +++++++++++++++++--
 1 file changed, 65 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad4030.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad4030.yaml
index 564b6f67a96e..3890cd4ba93e 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad4030.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad4030.yaml
@@ -19,6 +19,8 @@ description: |
   * https://www.analog.com/media/en/technical-documentation/data-sheets/ad4030-24-4032-24.pdf
   * https://www.analog.com/media/en/technical-documentation/data-sheets/ad4630-24_ad4632-24.pdf
   * https://www.analog.com/media/en/technical-documentation/data-sheets/ad4630-16-4632-16.pdf
+  * https://www.analog.com/media/en/technical-documentation/data-sheets/adaq4216.pdf
+  * https://www.analog.com/media/en/technical-documentation/data-sheets/adaq4224.pdf
 
 $ref: /schemas/spi/spi-peripheral-props.yaml#
 
@@ -31,6 +33,8 @@ properties:
       - adi,ad4630-24
       - adi,ad4632-16
       - adi,ad4632-24
+      - adi,adaq4216
+      - adi,adaq4224
 
   reg:
     maxItems: 1
@@ -54,6 +58,14 @@ properties:
     description:
       Internal buffered Reference. Used when ref-supply is not connected.
 
+  vddh-supply:
+    description:
+      PGIA Positive Power Supply.
+
+  vdd-fda-supply:
+    description:
+      FDA Positive Power Supply.
+
   cnv-gpios:
     description:
       The Convert Input (CNV). It initiates the sampling conversions.
@@ -64,6 +76,13 @@ properties:
       The Reset Input (/RST). Used for asynchronous device reset.
     maxItems: 1
 
+  pga-gpios:
+    description:
+      A0 and A1 pins for gain selection. For devices that have PGA configuration
+      input pins, pga-gpios should be defined.
+    minItems: 2
+    maxItems: 2
+
   pwms:
     description: PWM signal connected to the CNV pin.
     maxItems: 1
@@ -86,11 +105,29 @@ required:
   - vio-supply
   - cnv-gpios
 
-oneOf:
-  - required:
-      - ref-supply
-  - required:
-      - refin-supply
+allOf:
+  - oneOf:
+      - required:
+          - ref-supply
+      - required:
+          - refin-supply
+  # ADAQ devices require a gain property to indicate how hardware PGA is set
+  - if:
+      properties:
+        compatible:
+          contains:
+            pattern: ^adi,adaq
+    then:
+      required:
+        - vddh-supply
+        - vdd-fda-supply
+        - pga-gpios
+      properties:
+        ref-supply: false
+    else:
+      properties:
+        pga-gpios: false
+
 
 unevaluatedProperties: false
 
@@ -114,3 +151,26 @@ examples:
             reset-gpios = <&gpio0 1 GPIO_ACTIVE_LOW>;
         };
     };
+  - |
+    #include <dt-bindings/gpio/gpio.h>
+    spi {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        adc@0 {
+            compatible = "adi,adaq4216";
+            reg = <0>;
+            spi-max-frequency = <80000000>;
+            vdd-5v-supply = <&supply_5V>;
+            vdd-1v8-supply = <&supply_1_8V>;
+            vio-supply = <&supply_1_8V>;
+            refin-supply = <&refin_sup>;
+            vddh-supply = <&vddh>;
+            vdd-fda-supply = <&vdd_fda>;
+            cnv-gpios = <&gpio0 0 GPIO_ACTIVE_HIGH>;
+            reset-gpios = <&gpio0 1 GPIO_ACTIVE_LOW>;
+            pga-gpios = <&gpio0 2 GPIO_ACTIVE_HIGH>,
+                        <&gpio0 3 GPIO_ACTIVE_HIGH>;
+        };
+    };
+...
-- 
2.39.2

[PATCH v6 7/8] iio: adc: ad4030: Add support for ADAQ4216 and ADAQ4224

[Marcelo Schmitt]

ADAQ4216 and ADAQ4224 are similar to AD4030, but feature a PGA circuitry
that scales the analog input signal prior to it reaching the ADC. The PGA
is controlled through a pair of pins (A0 and A1) whose state define the
gain that is applied to the input signal.

Add support for ADAQ4216 and ADAQ4224. Provide a list of PGA options
through the IIO device channel scale available interface and enable control
of the PGA through the channel scale interface.

Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
---
Change log v5 -> v6
- Dropped redundant parentheses on declaration of ADAQ hw gain table.
- Dropped unneeded cast to u64.
- Use constant for number of ADAQ PGA pins in error message.

 drivers/iio/adc/ad4030.c | 201 ++++++++++++++++++++++++++++++++++++++-
 1 file changed, 198 insertions(+), 3 deletions(-)

diff --git a/drivers/iio/adc/ad4030.c b/drivers/iio/adc/ad4030.c
index 08f06ffb6b21..5f968f2a2b3c 100644
--- a/drivers/iio/adc/ad4030.c
+++ b/drivers/iio/adc/ad4030.c
@@ -47,6 +47,8 @@
 #define     AD4030_REG_CHIP_GRADE_AD4630_24_GRADE	0x00
 #define     AD4030_REG_CHIP_GRADE_AD4632_16_GRADE	0x05
 #define     AD4030_REG_CHIP_GRADE_AD4632_24_GRADE	0x02
+#define     AD4030_REG_CHIP_GRADE_ADAQ4216_GRADE	0x1E
+#define     AD4030_REG_CHIP_GRADE_ADAQ4224_GRADE	0x1C
 #define     AD4030_REG_CHIP_GRADE_MASK_CHIP_GRADE	GENMASK(7, 3)
 #define AD4030_REG_SCRATCH_PAD			0x0A
 #define AD4030_REG_SPI_REVISION			0x0B
@@ -124,6 +126,10 @@
 /* Datasheet says 9.8ns, so use the closest integer value */
 #define AD4030_TQUIET_CNV_DELAY_NS	10
 
+/* HARDWARE_GAIN */
+#define ADAQ4616_PGA_PINS		2
+#define ADAQ4616_PGA_GAIN_MAX_NANO	(NANO * 2 / 3)
+
 enum ad4030_out_mode {
 	AD4030_OUT_DATA_MD_DIFF,
 	AD4030_OUT_DATA_MD_16_DIFF_8_COM,
@@ -144,6 +150,23 @@ enum {
 	AD4030_SCAN_TYPE_AVG,
 };
 
+/*
+ * Gains computed as fractions of 1000 so they can be expressed by integers.
+ */
+static const int adaq4216_hw_gains_vpv[] = {
+	MILLI / 3,		/* 333 */
+	5 * MILLI / 9,		/* 555 */
+	20 * MILLI / 9,		/* 2222 */
+	20 * MILLI / 3,		/* 6666 */
+};
+
+static const int adaq4216_hw_gains_frac[][2] = {
+	{ 1, 3 },  /* 1/3 V/V gain */
+	{ 5, 9 },  /* 5/9 V/V gain */
+	{ 20, 9 }, /* 20/9 V/V gain */
+	{ 20, 3 }, /* 20/3 V/V gain */
+};
+
 struct ad4030_chip_info {
 	const char *name;
 	const unsigned long *available_masks;
@@ -151,6 +174,7 @@ struct ad4030_chip_info {
 	const struct iio_chan_spec offload_channels[AD4030_MAX_IIO_CHANNEL_NB];
 	u8 grade;
 	u8 precision_bits;
+	bool has_pga;
 	/* Number of hardware channels */
 	int num_voltage_inputs;
 	unsigned int tcyc_ns;
@@ -174,7 +198,11 @@ struct ad4030_state {
 	struct spi_offload_trigger *offload_trigger;
 	struct spi_offload_trigger_config offload_trigger_config;
 	struct pwm_device *cnv_trigger;
+	size_t scale_avail_size;
 	struct pwm_waveform cnv_wf;
+	unsigned int scale_avail[ARRAY_SIZE(adaq4216_hw_gains_vpv)][2];
+	struct gpio_descs *pga_gpios;
+	unsigned int pga_index;
 
 	/*
 	 * DMA (thus cache coherency maintenance) requires the transfer buffers
@@ -231,7 +259,7 @@ struct ad4030_state {
  * - voltage0-voltage1
  * - voltage2-voltage3
  */
-#define __AD4030_CHAN_DIFF(_idx, _scan_type, _offload) {		\
+#define __AD4030_CHAN_DIFF(_idx, _scan_type, _offload, _pga) {		\
 	.info_mask_shared_by_all =					\
 		(_offload ? BIT(IIO_CHAN_INFO_SAMP_FREQ) : 0) |		\
 		BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO),			\
@@ -242,6 +270,7 @@ struct ad4030_state {
 		BIT(IIO_CHAN_INFO_CALIBBIAS) |				\
 		BIT(IIO_CHAN_INFO_RAW),					\
 	.info_mask_separate_available = BIT(IIO_CHAN_INFO_CALIBBIAS) |	\
+		(_pga ? BIT(IIO_CHAN_INFO_SCALE) : 0) |			\
 		BIT(IIO_CHAN_INFO_CALIBSCALE),				\
 	.type = IIO_VOLTAGE,						\
 	.indexed = 1,							\
@@ -256,10 +285,16 @@ struct ad4030_state {
 }
 
 #define AD4030_CHAN_DIFF(_idx, _scan_type)				\
-	__AD4030_CHAN_DIFF(_idx, _scan_type, 0)
+	__AD4030_CHAN_DIFF(_idx, _scan_type, 0, 0)
 
 #define AD4030_OFFLOAD_CHAN_DIFF(_idx, _scan_type)			\
-	__AD4030_CHAN_DIFF(_idx, _scan_type, 1)
+	__AD4030_CHAN_DIFF(_idx, _scan_type, 1, 0)
+
+#define ADAQ4216_CHAN_DIFF(_idx, _scan_type)				\
+	__AD4030_CHAN_DIFF(_idx, _scan_type, 0, 1)
+
+#define ADAQ4216_OFFLOAD_CHAN_DIFF(_idx, _scan_type)			\
+	__AD4030_CHAN_DIFF(_idx, _scan_type, 1, 1)
 
 /*
  * AD4030 can average over 2^N samples, where N = 1, 2, 3, ..., 16.
@@ -417,6 +452,65 @@ static const struct regmap_config ad4030_regmap_config = {
 	.max_register = AD4030_REG_DIG_ERR,
 };
 
+static void ad4030_fill_scale_avail(struct ad4030_state *st)
+{
+	unsigned int mag_bits, int_part, fract_part, i;
+	u64 range;
+
+	/*
+	 * The maximum precision of differential channels is retrieved from the
+	 * chip properties. The output code of differential channels is in two's
+	 * complement format (i.e. signed), so the MSB is the sign bit and only
+	 * (precision_bits - 1) bits express voltage magnitude.
+	 */
+	mag_bits = st->chip->precision_bits - 1;
+
+	for (i = 0; i < ARRAY_SIZE(adaq4216_hw_gains_frac); i++) {
+		range = mult_frac(st->vref_uv, adaq4216_hw_gains_frac[i][1],
+				  adaq4216_hw_gains_frac[i][0]);
+		/*
+		 * If range were in mV, we would multiply it by NANO below.
+		 * Though, range is in µV so multiply it by MICRO only so the
+		 * result after right shift and division scales output codes to
+		 * millivolts.
+		 */
+		int_part = div_u64_rem((range * MICRO) >> mag_bits, NANO, &fract_part);
+		st->scale_avail[i][0] = int_part;
+		st->scale_avail[i][1] = fract_part;
+	}
+}
+
+static int ad4030_set_pga_gain(struct ad4030_state *st)
+{
+	DECLARE_BITMAP(bitmap, ADAQ4616_PGA_PINS) = { };
+
+	bitmap_write(bitmap, st->pga_index, 0, ADAQ4616_PGA_PINS);
+
+	return gpiod_multi_set_value_cansleep(st->pga_gpios, bitmap);
+}
+
+static int ad4030_set_pga(struct iio_dev *indio_dev, int gain_int, int gain_fract)
+{
+	struct ad4030_state *st = iio_priv(indio_dev);
+	unsigned int mag_bits = st->chip->precision_bits - 1;
+	u64 gain_nano, tmp;
+
+	if (!st->pga_gpios)
+		return -EINVAL;
+
+	gain_nano = gain_int * NANO + gain_fract;
+
+	if (!in_range(gain_nano, 1, ADAQ4616_PGA_GAIN_MAX_NANO))
+		return -EINVAL;
+
+	tmp = DIV_ROUND_CLOSEST_ULL(gain_nano << mag_bits, NANO);
+	gain_nano = DIV_ROUND_CLOSEST_ULL(st->vref_uv, tmp);
+	st->pga_index = find_closest(gain_nano, adaq4216_hw_gains_vpv,
+				     ARRAY_SIZE(adaq4216_hw_gains_vpv));
+
+	return ad4030_set_pga_gain(st);
+}
+
 static int ad4030_get_chan_scale(struct iio_dev *indio_dev,
 				 struct iio_chan_spec const *chan,
 				 int *val,
@@ -429,6 +523,13 @@ static int ad4030_get_chan_scale(struct iio_dev *indio_dev,
 	if (IS_ERR(scan_type))
 		return PTR_ERR(scan_type);
 
+	/* The LSB of the 8-bit common-mode data is always vref/256. */
+	if (st->chip->has_pga && scan_type->realbits != 8) {
+		*val = st->scale_avail[st->pga_index][0];
+		*val2 = st->scale_avail[st->pga_index][1];
+		return IIO_VAL_INT_PLUS_NANO;
+	}
+
 	if (chan->differential)
 		*val = (st->vref_uv * 2) / MILLI;
 	else
@@ -891,6 +992,15 @@ static int ad4030_read_avail(struct iio_dev *indio_dev,
 		*length = ARRAY_SIZE(ad4030_average_modes);
 		return IIO_AVAIL_LIST;
 
+	case IIO_CHAN_INFO_SCALE:
+		if (st->scale_avail_size == 1)
+			*vals = (int *)st->scale_avail[st->pga_index];
+		else
+			*vals = (int *)st->scale_avail;
+		*length = st->scale_avail_size * 2; /* print int and nano part */
+		*type = IIO_VAL_INT_PLUS_NANO;
+		return IIO_AVAIL_LIST;
+
 	default:
 		return -EINVAL;
 	}
@@ -963,6 +1073,9 @@ static int ad4030_write_raw_dispatch(struct iio_dev *indio_dev,
 	case IIO_CHAN_INFO_SAMP_FREQ:
 		return ad4030_set_sampling_freq(indio_dev, val);
 
+	case IIO_CHAN_INFO_SCALE:
+		return ad4030_set_pga(indio_dev, val, val2);
+
 	default:
 		return -EINVAL;
 	}
@@ -984,6 +1097,17 @@ static int ad4030_write_raw(struct iio_dev *indio_dev,
 	return ret;
 }
 
+static int ad4030_write_raw_get_fmt(struct iio_dev *indio_dev,
+				    struct iio_chan_spec const *chan, long mask)
+{
+	switch (mask) {
+	case IIO_CHAN_INFO_SCALE:
+		return IIO_VAL_INT_PLUS_NANO;
+	default:
+		return IIO_VAL_INT_PLUS_MICRO;
+	}
+}
+
 static int ad4030_reg_access(struct iio_dev *indio_dev, unsigned int reg,
 			     unsigned int writeval, unsigned int *readval)
 {
@@ -1030,6 +1154,7 @@ static const struct iio_info ad4030_iio_info = {
 	.read_avail = ad4030_read_avail,
 	.read_raw = ad4030_read_raw,
 	.write_raw = ad4030_write_raw,
+	.write_raw_get_fmt = &ad4030_write_raw_get_fmt,
 	.debugfs_reg_access = ad4030_reg_access,
 	.read_label = ad4030_read_label,
 	.get_current_scan_type = ad4030_get_current_scan_type,
@@ -1289,6 +1414,26 @@ static int ad4030_spi_offload_setup(struct iio_dev *indio_dev,
 							   IIO_BUFFER_DIRECTION_IN);
 }
 
+static int ad4030_setup_pga(struct device *dev, struct iio_dev *indio_dev,
+			    struct ad4030_state *st)
+{
+	/* Setup GPIOs for PGA control */
+	st->pga_gpios = devm_gpiod_get_array(dev, "pga", GPIOD_OUT_LOW);
+	if (IS_ERR(st->pga_gpios))
+		return dev_err_probe(dev, PTR_ERR(st->pga_gpios),
+				     "Failed to get PGA gpios.\n");
+
+	if (st->pga_gpios->ndescs != ADAQ4616_PGA_PINS)
+		return dev_err_probe(dev, -EINVAL,
+				     "Expected %d GPIOs for PGA control.\n",
+				     ADAQ4616_PGA_PINS);
+
+	st->scale_avail_size = ARRAY_SIZE(adaq4216_hw_gains_vpv);
+	st->pga_index = 0;
+
+	return 0;
+}
+
 static int ad4030_probe(struct spi_device *spi)
 {
 	struct device *dev = &spi->dev;
@@ -1331,6 +1476,14 @@ static int ad4030_probe(struct spi_device *spi)
 	if (ret)
 		return ret;
 
+	if (st->chip->has_pga) {
+		ret = ad4030_setup_pga(dev, indio_dev, st);
+		if (ret)
+			return ret;
+
+		ad4030_fill_scale_avail(st);
+	}
+
 	ret = ad4030_config(st);
 	if (ret)
 		return ret;
@@ -1584,12 +1737,52 @@ static const struct ad4030_chip_info ad4632_24_chip_info = {
 	.max_sample_rate_hz = 500 * HZ_PER_KHZ,
 };
 
+static const struct ad4030_chip_info adaq4216_chip_info = {
+	.name = "adaq4216",
+	.available_masks = ad4030_channel_masks,
+	.channels = {
+		ADAQ4216_CHAN_DIFF(0, ad4030_16_scan_types),
+		AD4030_CHAN_CMO(1, 0),
+		IIO_CHAN_SOFT_TIMESTAMP(2),
+	},
+	.offload_channels = {
+		ADAQ4216_OFFLOAD_CHAN_DIFF(0, ad4030_16_offload_scan_types),
+	},
+	.grade = AD4030_REG_CHIP_GRADE_ADAQ4216_GRADE,
+	.precision_bits = 16,
+	.has_pga = true,
+	.num_voltage_inputs = 1,
+	.tcyc_ns = AD4030_TCYC_ADJUSTED_NS,
+	.max_sample_rate_hz = 2 * HZ_PER_MHZ,
+};
+
+static const struct ad4030_chip_info adaq4224_chip_info = {
+	.name = "adaq4224",
+	.available_masks = ad4030_channel_masks,
+	.channels = {
+		ADAQ4216_CHAN_DIFF(0, ad4030_24_scan_types),
+		AD4030_CHAN_CMO(1, 0),
+		IIO_CHAN_SOFT_TIMESTAMP(2),
+	},
+	.offload_channels = {
+		ADAQ4216_OFFLOAD_CHAN_DIFF(0, ad4030_24_offload_scan_types),
+	},
+	.grade = AD4030_REG_CHIP_GRADE_ADAQ4224_GRADE,
+	.precision_bits = 24,
+	.has_pga = true,
+	.num_voltage_inputs = 1,
+	.tcyc_ns = AD4030_TCYC_ADJUSTED_NS,
+	.max_sample_rate_hz = 2 * HZ_PER_MHZ,
+};
+
 static const struct spi_device_id ad4030_id_table[] = {
 	{ "ad4030-24", (kernel_ulong_t)&ad4030_24_chip_info },
 	{ "ad4630-16", (kernel_ulong_t)&ad4630_16_chip_info },
 	{ "ad4630-24", (kernel_ulong_t)&ad4630_24_chip_info },
 	{ "ad4632-16", (kernel_ulong_t)&ad4632_16_chip_info },
 	{ "ad4632-24", (kernel_ulong_t)&ad4632_24_chip_info },
+	{ "adaq4216", (kernel_ulong_t)&adaq4216_chip_info },
+	{ "adaq4224", (kernel_ulong_t)&adaq4224_chip_info },
 	{ }
 };
 MODULE_DEVICE_TABLE(spi, ad4030_id_table);
@@ -1600,6 +1793,8 @@ static const struct of_device_id ad4030_of_match[] = {
 	{ .compatible = "adi,ad4630-24", .data = &ad4630_24_chip_info },
 	{ .compatible = "adi,ad4632-16", .data = &ad4632_16_chip_info },
 	{ .compatible = "adi,ad4632-24", .data = &ad4632_24_chip_info },
+	{ .compatible = "adi,adaq4216", .data = &adaq4216_chip_info },
+	{ .compatible = "adi,adaq4224", .data = &adaq4224_chip_info },
 	{ }
 };
 MODULE_DEVICE_TABLE(of, ad4030_of_match);
-- 
2.39.2

[PATCH v6 8/8] iio: adc: ad4030: Support common-mode channels with SPI offloading

[Marcelo Schmitt]

AD4030 and similar devices can read common-mode voltage together with
ADC sample data. When enabled, common-mode voltage data is provided in a
separate IIO channel since it measures something other than the primary
ADC input signal and requires separate scaling to convert to voltage
units. The initial SPI offload support patch for AD4030 only provided
differential channels. Now, extend the AD4030 driver to also provide
common-mode IIO channels when setup with SPI offloading capability.

Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
---
New patch.
I hope this works for ADCs with two channels. It's not clear if works as
expected with current HDL and single-channel ADCs (like ADAQ4216).

The ad4630_fmc HDL project was designed for ADCs with two channels and
always streams two data channels to DMA (even when the ADC has only one
physical channel). Though, if the ADC has only one physical channel, the
data that would come from the second ADC channel comes in as noise and
would have to be discarded. Because of that, when using single-channel
ADCs, the ADC driver would need to use a special DMA buffer to filter out
half of the data that reaches DMA memory. With that, the ADC sample data
could be delivered to user space without any noise being added to the IIO
buffer. I have implemented a prototype of such specialized buffer
(industrialio-buffer-dmaengine-filtered), but it is awful and only worked
with CONFIG_IIO_DMA_BUF_MMAP_LEGACY (only present in ADI Linux tree). Usual
differential channel data is also affected by the extra 0xFFFFFFFF data
pushed to DMA. Though, for the differential channel, it's easier to see it
shall work for two-channel ADCs (the sine wave appears "filled" in
iio-oscilloscope).

So, I sign this, but don't guarantee it to work.

 drivers/iio/adc/ad4030.c | 49 ++++++++++++++++++++++++++++++++--------
 1 file changed, 40 insertions(+), 9 deletions(-)

diff --git a/drivers/iio/adc/ad4030.c b/drivers/iio/adc/ad4030.c
index 5f968f2a2b3c..74ff35742cda 100644
--- a/drivers/iio/adc/ad4030.c
+++ b/drivers/iio/adc/ad4030.c
@@ -192,7 +192,7 @@ struct ad4030_state {
 	unsigned int avg_log2;
 	enum ad4030_out_mode mode;
 	/* Offload sampling */
-	struct spi_transfer offload_xfer;
+	struct spi_transfer offload_xfer[2];
 	struct spi_message offload_msg;
 	struct spi_offload *offload;
 	struct spi_offload_trigger *offload_trigger;
@@ -237,7 +237,7 @@ struct ad4030_state {
  * - _idx - _ch * 2 + _ch gives the channel number for this specific common-mode
  *   channel
  */
-#define AD4030_CHAN_CMO(_idx, _ch)  {					\
+#define __AD4030_CHAN_CMO(_idx, _ch, _offload)  {			\
 	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |			\
 		BIT(IIO_CHAN_INFO_SCALE),				\
 	.type = IIO_VOLTAGE,						\
@@ -247,12 +247,18 @@ struct ad4030_state {
 	.scan_index = (_idx),						\
 	.scan_type = {							\
 		.sign = 'u',						\
-		.storagebits = 8,					\
+		.storagebits = (_offload ? 32 : 8),			\
 		.realbits = 8,						\
-		.endianness = IIO_BE,					\
+		.endianness = (_offload ? IIO_CPU : IIO_BE),		\
 	},								\
 }
 
+#define AD4030_CHAN_CMO(_idx, _ch)					\
+	__AD4030_CHAN_CMO(_idx, _ch, 0)
+
+#define AD4030_OFFLOAD_CHAN_CMO(_idx, _ch)				\
+	__AD4030_CHAN_CMO(_idx, _ch, 1)
+
 /*
  * For a chip with 2 hardware channel this will be used to create 2 differential
  * channels:
@@ -1180,6 +1186,7 @@ static const struct iio_buffer_setup_ops ad4030_buffer_setup_ops = {
 static void ad4030_prepare_offload_msg(struct iio_dev *indio_dev)
 {
 	struct ad4030_state *st = iio_priv(indio_dev);
+	bool common_mode;
 	u8 offload_bpw;
 
 	if (st->mode == AD4030_OUT_DATA_MD_30_AVERAGED_DIFF)
@@ -1187,10 +1194,22 @@ static void ad4030_prepare_offload_msg(struct iio_dev *indio_dev)
 	else
 		offload_bpw = st->chip->precision_bits;
 
-	st->offload_xfer.bits_per_word = offload_bpw;
-	st->offload_xfer.len = spi_bpw_to_bytes(offload_bpw);
-	st->offload_xfer.offload_flags = SPI_OFFLOAD_XFER_RX_STREAM;
-	spi_message_init_with_transfers(&st->offload_msg, &st->offload_xfer, 1);
+	st->offload_xfer[0].bits_per_word = offload_bpw;
+	st->offload_xfer[0].len = spi_bpw_to_bytes(offload_bpw);
+	st->offload_xfer[0].offload_flags = SPI_OFFLOAD_XFER_RX_STREAM;
+
+	common_mode = st->mode == AD4030_OUT_DATA_MD_24_DIFF_8_COM ||
+		      st->mode == AD4030_OUT_DATA_MD_16_DIFF_8_COM;
+
+	if (common_mode) {
+		offload_bpw = 8;
+		st->offload_xfer[1].bits_per_word = offload_bpw;
+		st->offload_xfer[1].len = spi_bpw_to_bytes(offload_bpw);
+		st->offload_xfer[1].offload_flags = SPI_OFFLOAD_XFER_RX_STREAM;
+	}
+
+	spi_message_init_with_transfers(&st->offload_msg, st->offload_xfer,
+					common_mode ? 2 : 1);
 }
 
 static int ad4030_offload_buffer_postenable(struct iio_dev *indio_dev)
@@ -1273,6 +1292,7 @@ static int ad4030_offload_buffer_predisable(struct iio_dev *indio_dev)
 static const struct iio_buffer_setup_ops ad4030_offload_buffer_setup_ops = {
 	.postenable = &ad4030_offload_buffer_postenable,
 	.predisable = &ad4030_offload_buffer_predisable,
+	.validate_scan_mask = ad4030_validate_scan_mask,
 };
 
 static int ad4030_regulators_get(struct ad4030_state *st)
@@ -1524,7 +1544,7 @@ static int ad4030_probe(struct spi_device *spi)
 		 * Offloaded SPI transfers can't support software timestamp so
 		 * no additional timestamp channel is added.
 		 */
-		indio_dev->num_channels = st->chip->num_voltage_inputs;
+		indio_dev->num_channels = 2 * st->chip->num_voltage_inputs;
 		indio_dev->channels = st->chip->offload_channels;
 		ret = ad4030_spi_offload_setup(indio_dev, st);
 		if (ret)
@@ -1645,6 +1665,7 @@ static const struct ad4030_chip_info ad4030_24_chip_info = {
 	},
 	.offload_channels = {
 		AD4030_OFFLOAD_CHAN_DIFF(0, ad4030_24_offload_scan_types),
+		AD4030_OFFLOAD_CHAN_CMO(1, 0),
 	},
 	.grade = AD4030_REG_CHIP_GRADE_AD4030_24_GRADE,
 	.precision_bits = 24,
@@ -1666,6 +1687,8 @@ static const struct ad4030_chip_info ad4630_16_chip_info = {
 	.offload_channels = {
 		AD4030_OFFLOAD_CHAN_DIFF(0, ad4030_16_offload_scan_types),
 		AD4030_OFFLOAD_CHAN_DIFF(1, ad4030_16_offload_scan_types),
+		AD4030_OFFLOAD_CHAN_CMO(2, 0),
+		AD4030_OFFLOAD_CHAN_CMO(3, 1),
 	},
 	.grade = AD4030_REG_CHIP_GRADE_AD4630_16_GRADE,
 	.precision_bits = 16,
@@ -1687,6 +1710,8 @@ static const struct ad4030_chip_info ad4630_24_chip_info = {
 	.offload_channels = {
 		AD4030_OFFLOAD_CHAN_DIFF(0, ad4030_24_offload_scan_types),
 		AD4030_OFFLOAD_CHAN_DIFF(1, ad4030_24_offload_scan_types),
+		AD4030_OFFLOAD_CHAN_CMO(2, 0),
+		AD4030_OFFLOAD_CHAN_CMO(3, 1),
 	},
 	.grade = AD4030_REG_CHIP_GRADE_AD4630_24_GRADE,
 	.precision_bits = 24,
@@ -1708,6 +1733,8 @@ static const struct ad4030_chip_info ad4632_16_chip_info = {
 	.offload_channels = {
 		AD4030_OFFLOAD_CHAN_DIFF(0, ad4030_16_offload_scan_types),
 		AD4030_OFFLOAD_CHAN_DIFF(1, ad4030_16_offload_scan_types),
+		AD4030_OFFLOAD_CHAN_CMO(2, 0),
+		AD4030_OFFLOAD_CHAN_CMO(3, 1),
 	},
 	.grade = AD4030_REG_CHIP_GRADE_AD4632_16_GRADE,
 	.precision_bits = 16,
@@ -1729,6 +1756,8 @@ static const struct ad4030_chip_info ad4632_24_chip_info = {
 	.offload_channels = {
 		AD4030_OFFLOAD_CHAN_DIFF(0, ad4030_24_offload_scan_types),
 		AD4030_OFFLOAD_CHAN_DIFF(1, ad4030_24_offload_scan_types),
+		AD4030_OFFLOAD_CHAN_CMO(2, 0),
+		AD4030_OFFLOAD_CHAN_CMO(3, 1),
 	},
 	.grade = AD4030_REG_CHIP_GRADE_AD4632_24_GRADE,
 	.precision_bits = 24,
@@ -1747,6 +1776,7 @@ static const struct ad4030_chip_info adaq4216_chip_info = {
 	},
 	.offload_channels = {
 		ADAQ4216_OFFLOAD_CHAN_DIFF(0, ad4030_16_offload_scan_types),
+		AD4030_OFFLOAD_CHAN_CMO(1, 0),
 	},
 	.grade = AD4030_REG_CHIP_GRADE_ADAQ4216_GRADE,
 	.precision_bits = 16,
@@ -1766,6 +1796,7 @@ static const struct ad4030_chip_info adaq4224_chip_info = {
 	},
 	.offload_channels = {
 		ADAQ4216_OFFLOAD_CHAN_DIFF(0, ad4030_24_offload_scan_types),
+		AD4030_OFFLOAD_CHAN_CMO(1, 0),
 	},
 	.grade = AD4030_REG_CHIP_GRADE_ADAQ4224_GRADE,
 	.precision_bits = 24,
-- 
2.39.2

Re: [PATCH v6 8/8] iio: adc: ad4030: Support common-mode channels with SPI offloading

[Jonathan Cameron]

On Mon, 20 Oct 2025 16:15:39 -0300
Marcelo Schmitt <marcelo.schmitt@analog.com> wrote:

> AD4030 and similar devices can read common-mode voltage together with
> ADC sample data. When enabled, common-mode voltage data is provided in a
> separate IIO channel since it measures something other than the primary
> ADC input signal and requires separate scaling to convert to voltage
> units. The initial SPI offload support patch for AD4030 only provided
> differential channels. Now, extend the AD4030 driver to also provide
> common-mode IIO channels when setup with SPI offloading capability.
> 
> Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
> ---
> New patch.
> I hope this works for ADCs with two channels. It's not clear if works as
> expected with current HDL and single-channel ADCs (like ADAQ4216).
> 
> The ad4630_fmc HDL project was designed for ADCs with two channels and
> always streams two data channels to DMA (even when the ADC has only one
> physical channel). Though, if the ADC has only one physical channel, the
> data that would come from the second ADC channel comes in as noise and
> would have to be discarded. Because of that, when using single-channel
> ADCs, the ADC driver would need to use a special DMA buffer to filter out
> half of the data that reaches DMA memory. With that, the ADC sample data
> could be delivered to user space without any noise being added to the IIO
> buffer. I have implemented a prototype of such specialized buffer
> (industrialio-buffer-dmaengine-filtered), but it is awful and only worked
> with CONFIG_IIO_DMA_BUF_MMAP_LEGACY (only present in ADI Linux tree). Usual
> differential channel data is also affected by the extra 0xFFFFFFFF data
> pushed to DMA. Though, for the differential channel, it's easier to see it
> shall work for two-channel ADCs (the sine wave appears "filled" in
> iio-oscilloscope).
> 
> So, I sign this, but don't guarantee it to work.

So what's the path to resolve this?  Waiting on HDL changes or not support
those devices until we have a clean solution?

Also, just to check, is this only an issue with the additional stuff this
patch adds or do we have a problem with SPI offload in general (+ this
IP) and those single channel devices?

Jonathan

Re: [PATCH v6 8/8] iio: adc: ad4030: Support common-mode channels with SPI offloading

[Marcelo Schmitt]

On 10/27, Jonathan Cameron wrote:
> On Mon, 20 Oct 2025 16:15:39 -0300
> Marcelo Schmitt <marcelo.schmitt@analog.com> wrote:
> 
> > AD4030 and similar devices can read common-mode voltage together with
> > ADC sample data. When enabled, common-mode voltage data is provided in a
> > separate IIO channel since it measures something other than the primary
> > ADC input signal and requires separate scaling to convert to voltage
> > units. The initial SPI offload support patch for AD4030 only provided
> > differential channels. Now, extend the AD4030 driver to also provide
> > common-mode IIO channels when setup with SPI offloading capability.
> > 
> > Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
> > ---
> > New patch.
> > I hope this works for ADCs with two channels. It's not clear if works as
> > expected with current HDL and single-channel ADCs (like ADAQ4216).
> > 
> > The ad4630_fmc HDL project was designed for ADCs with two channels and
> > always streams two data channels to DMA (even when the ADC has only one
> > physical channel). Though, if the ADC has only one physical channel, the
> > data that would come from the second ADC channel comes in as noise and
> > would have to be discarded. Because of that, when using single-channel
> > ADCs, the ADC driver would need to use a special DMA buffer to filter out
> > half of the data that reaches DMA memory. With that, the ADC sample data
> > could be delivered to user space without any noise being added to the IIO
> > buffer. I have implemented a prototype of such specialized buffer
> > (industrialio-buffer-dmaengine-filtered), but it is awful and only worked
> > with CONFIG_IIO_DMA_BUF_MMAP_LEGACY (only present in ADI Linux tree). Usual
> > differential channel data is also affected by the extra 0xFFFFFFFF data
> > pushed to DMA. Though, for the differential channel, it's easier to see it
> > shall work for two-channel ADCs (the sine wave appears "filled" in
> > iio-oscilloscope).
> > 
> > So, I sign this, but don't guarantee it to work.
> 
> So what's the path to resolve this?  Waiting on HDL changes or not support
> those devices until we have a clean solution?

Waiting for HDL to get updated I'd say.

> 
> Also, just to check, is this only an issue with the additional stuff this
> patch adds or do we have a problem with SPI offload in general (+ this
> IP) and those single channel devices?

IMO, one solution would be to update the HDL project for AD4630 and similar ADCs
to not send data from channel 2 to DMA memory when single-channel ADCs are
connected. Another possibility would be to intercept and filter out the extra
data before pushing it to user space. My first attempt of doing that didn't
work out with upstream kernel but I may revisit that.

We could maybe split the driver into two. One for supporting two-channel ADCs
and one for single-channel. Though, we would fall into the same issue when
handling offloaded data for the single-channel driver.

Re: [PATCH v6 8/8] iio: adc: ad4030: Support common-mode channels with SPI offloading

[Nuno Sá]

On Wed, 2025-10-29 at 15:11 -0300, Marcelo Schmitt wrote:
> On 10/27, Jonathan Cameron wrote:
> > On Mon, 20 Oct 2025 16:15:39 -0300
> > Marcelo Schmitt <marcelo.schmitt@analog.com> wrote:
> > 
> > > AD4030 and similar devices can read common-mode voltage together with
> > > ADC sample data. When enabled, common-mode voltage data is provided in a
> > > separate IIO channel since it measures something other than the primary
> > > ADC input signal and requires separate scaling to convert to voltage
> > > units. The initial SPI offload support patch for AD4030 only provided
> > > differential channels. Now, extend the AD4030 driver to also provide
> > > common-mode IIO channels when setup with SPI offloading capability.
> > > 
> > > Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
> > > ---
> > > New patch.
> > > I hope this works for ADCs with two channels. It's not clear if works as
> > > expected with current HDL and single-channel ADCs (like ADAQ4216).
> > > 
> > > The ad4630_fmc HDL project was designed for ADCs with two channels and
> > > always streams two data channels to DMA (even when the ADC has only one
> > > physical channel). Though, if the ADC has only one physical channel, the
> > > data that would come from the second ADC channel comes in as noise and
> > > would have to be discarded. Because of that, when using single-channel
> > > ADCs, the ADC driver would need to use a special DMA buffer to filter out
> > > half of the data that reaches DMA memory. With that, the ADC sample data
> > > could be delivered to user space without any noise being added to the IIO
> > > buffer. I have implemented a prototype of such specialized buffer
> > > (industrialio-buffer-dmaengine-filtered), but it is awful and only worked
> > > with CONFIG_IIO_DMA_BUF_MMAP_LEGACY (only present in ADI Linux tree). Usual
> > > differential channel data is also affected by the extra 0xFFFFFFFF data
> > > pushed to DMA. Though, for the differential channel, it's easier to see it
> > > shall work for two-channel ADCs (the sine wave appears "filled" in
> > > iio-oscilloscope).
> > > 
> > > So, I sign this, but don't guarantee it to work.
> > 
> > So what's the path to resolve this?  Waiting on HDL changes or not support
> > those devices until we have a clean solution?
> 
> Waiting for HDL to get updated I'd say.

Agree. We kind of control the IP here so why should we do awful tricks in
SW right :)? At the very least I would expect hdl to be capable to discard the
data in HW.

> 
> > 
> > Also, just to check, is this only an issue with the additional stuff this
> > patch adds or do we have a problem with SPI offload in general (+ this
> > IP) and those single channel devices?
> 
> IMO, one solution would be to update the HDL project for AD4630 and similar ADCs
> to not send data from channel 2 to DMA memory when single-channel ADCs are
> connected. Another possibility would be to intercept and filter out the extra
> data before pushing it to user space. My first attempt of doing that didn't
> work out with upstream kernel but I may revisit that.

I'm also confused. Is this also an issue with the current series without common mode?

If I'm getting things right, one channel ADCs pretty much do not work right now with
spi offload?

If the above is correct I would just not support it for 1 channel ADCs.

- Nuno Sá

Re: [PATCH v6 8/8] iio: adc: ad4030: Support common-mode channels with SPI offloading

[Marcelo Schmitt]

On 10/30, Nuno Sá wrote:
> On Wed, 2025-10-29 at 15:11 -0300, Marcelo Schmitt wrote:
> > On 10/27, Jonathan Cameron wrote:
> > > On Mon, 20 Oct 2025 16:15:39 -0300
> > > Marcelo Schmitt <marcelo.schmitt@analog.com> wrote:
> > > 
> > > > AD4030 and similar devices can read common-mode voltage together with
> > > > ADC sample data. When enabled, common-mode voltage data is provided in a
> > > > separate IIO channel since it measures something other than the primary
> > > > ADC input signal and requires separate scaling to convert to voltage
> > > > units. The initial SPI offload support patch for AD4030 only provided
> > > > differential channels. Now, extend the AD4030 driver to also provide
> > > > common-mode IIO channels when setup with SPI offloading capability.
> > > > 
> > > > Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
> > > > ---
> > > > New patch.
> > > > I hope this works for ADCs with two channels. It's not clear if works as
> > > > expected with current HDL and single-channel ADCs (like ADAQ4216).
> > > > 
> > > > The ad4630_fmc HDL project was designed for ADCs with two channels and
> > > > always streams two data channels to DMA (even when the ADC has only one
> > > > physical channel). Though, if the ADC has only one physical channel, the
> > > > data that would come from the second ADC channel comes in as noise and
> > > > would have to be discarded. Because of that, when using single-channel
> > > > ADCs, the ADC driver would need to use a special DMA buffer to filter out
> > > > half of the data that reaches DMA memory. With that, the ADC sample data
> > > > could be delivered to user space without any noise being added to the IIO
> > > > buffer. I have implemented a prototype of such specialized buffer
> > > > (industrialio-buffer-dmaengine-filtered), but it is awful and only worked
> > > > with CONFIG_IIO_DMA_BUF_MMAP_LEGACY (only present in ADI Linux tree). Usual
> > > > differential channel data is also affected by the extra 0xFFFFFFFF data
> > > > pushed to DMA. Though, for the differential channel, it's easier to see it
> > > > shall work for two-channel ADCs (the sine wave appears "filled" in
> > > > iio-oscilloscope).
> > > > 
> > > > So, I sign this, but don't guarantee it to work.
> > > 
> > > So what's the path to resolve this?  Waiting on HDL changes or not support
> > > those devices until we have a clean solution?
> > 
> > Waiting for HDL to get updated I'd say.
> 
> Agree. We kind of control the IP here so why should we do awful tricks in
> SW right :)? At the very least I would expect hdl to be capable to discard the
> data in HW.
> 
> > 
> > > 
> > > Also, just to check, is this only an issue with the additional stuff this
> > > patch adds or do we have a problem with SPI offload in general (+ this
> > > IP) and those single channel devices?
> > 
> > IMO, one solution would be to update the HDL project for AD4630 and similar ADCs
> > to not send data from channel 2 to DMA memory when single-channel ADCs are
> > connected. Another possibility would be to intercept and filter out the extra
> > data before pushing it to user space. My first attempt of doing that didn't
> > work out with upstream kernel but I may revisit that.
> 
> I'm also confused. Is this also an issue with the current series without common mode?
> 
> If I'm getting things right, one channel ADCs pretty much do not work right now with
> spi offload?

Yes, that's correct. It kind of works for single-channel ADCs, but half of the
data we see in user space is valid and the other half is not. For two-channel
ADCs, everything should be fine.

> 
> If the above is correct I would just not support it for 1 channel ADCs.

Currently, it's just one part that is single-channel (AD4030). If patches 6 and
7 were accepted, it would be 3 single-channel parts supported. I can add an `if`
somewhere to check the number of channel, but it will eventually have to be
removed when HDL gets fixed.

Or, if HDL can't be fixed, then we'll need the `if` now and something else
latter to filter out extra data before pushing to IIO buffers as mentioned
above. Though, this scenario seems odd to me as I think the HDL wouldn't be 100%
compatible with single-channel AD4030-like parts. We would be writing code to
support AD4030 _and_ a peculiar data stream from this specific HDL project?

My suggestion is to apply all patches except patch 8. IMHO, SPI offload
single-channel ADC support is broken due to HDL IP data stream not being
compatible with single-channel parts. That's not a Linux driver issue.
Patch 8 (common-mode for single-channel) may be fine, but I haven't been able
to validate that since I only have remote access to a single-channel ADC that
has already required a buffer work around to test.

Re: [PATCH v6 8/8] iio: adc: ad4030: Support common-mode channels with SPI offloading

[Nuno Sá]

On Mon, 2025-11-03 at 10:22 -0300, Marcelo Schmitt wrote:
> On 10/30, Nuno Sá wrote:
> > On Wed, 2025-10-29 at 15:11 -0300, Marcelo Schmitt wrote:
> > > On 10/27, Jonathan Cameron wrote:
> > > > On Mon, 20 Oct 2025 16:15:39 -0300
> > > > Marcelo Schmitt <marcelo.schmitt@analog.com> wrote:
> > > > 
> > > > > AD4030 and similar devices can read common-mode voltage together with
> > > > > ADC sample data. When enabled, common-mode voltage data is provided in a
> > > > > separate IIO channel since it measures something other than the primary
> > > > > ADC input signal and requires separate scaling to convert to voltage
> > > > > units. The initial SPI offload support patch for AD4030 only provided
> > > > > differential channels. Now, extend the AD4030 driver to also provide
> > > > > common-mode IIO channels when setup with SPI offloading capability.
> > > > > 
> > > > > Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
> > > > > ---
> > > > > New patch.
> > > > > I hope this works for ADCs with two channels. It's not clear if works as
> > > > > expected with current HDL and single-channel ADCs (like ADAQ4216).
> > > > > 
> > > > > The ad4630_fmc HDL project was designed for ADCs with two channels and
> > > > > always streams two data channels to DMA (even when the ADC has only one
> > > > > physical channel). Though, if the ADC has only one physical channel, the
> > > > > data that would come from the second ADC channel comes in as noise and
> > > > > would have to be discarded. Because of that, when using single-channel
> > > > > ADCs, the ADC driver would need to use a special DMA buffer to filter out
> > > > > half of the data that reaches DMA memory. With that, the ADC sample data
> > > > > could be delivered to user space without any noise being added to the IIO
> > > > > buffer. I have implemented a prototype of such specialized buffer
> > > > > (industrialio-buffer-dmaengine-filtered), but it is awful and only worked
> > > > > with CONFIG_IIO_DMA_BUF_MMAP_LEGACY (only present in ADI Linux tree). Usual
> > > > > differential channel data is also affected by the extra 0xFFFFFFFF data
> > > > > pushed to DMA. Though, for the differential channel, it's easier to see it
> > > > > shall work for two-channel ADCs (the sine wave appears "filled" in
> > > > > iio-oscilloscope).
> > > > > 
> > > > > So, I sign this, but don't guarantee it to work.
> > > > 
> > > > So what's the path to resolve this?  Waiting on HDL changes or not support
> > > > those devices until we have a clean solution?
> > > 
> > > Waiting for HDL to get updated I'd say.
> > 
> > Agree. We kind of control the IP here so why should we do awful tricks in
> > SW right :)? At the very least I would expect hdl to be capable to discard the
> > data in HW.
> > 
> > > 
> > > > 
> > > > Also, just to check, is this only an issue with the additional stuff this
> > > > patch adds or do we have a problem with SPI offload in general (+ this
> > > > IP) and those single channel devices?
> > > 
> > > IMO, one solution would be to update the HDL project for AD4630 and similar ADCs
> > > to not send data from channel 2 to DMA memory when single-channel ADCs are
> > > connected. Another possibility would be to intercept and filter out the extra
> > > data before pushing it to user space. My first attempt of doing that didn't
> > > work out with upstream kernel but I may revisit that.
> > 
> > I'm also confused. Is this also an issue with the current series without common mode?
> > 
> > If I'm getting things right, one channel ADCs pretty much do not work right now with
> > spi offload?
> 
> Yes, that's correct. It kind of works for single-channel ADCs, but half of the
> data we see in user space is valid and the other half is not. For two-channel
> ADCs, everything should be fine.

To me that is something that does not work eheheh :). I mean, going with all this trouble
to sample as fast as we can just so we have to discard (or mask out) half of every sample
in userspace (even though I can imagine we still get better performance vs non offload case).

> 
> > 
> > If the above is correct I would just not support it for 1 channel ADCs.
> 
> Currently, it's just one part that is single-channel (AD4030). If patches 6 and
> 7 were accepted, it would be 3 single-channel parts supported. I can add an `if`
> somewhere to check the number of channel, but it will eventually have to be
> removed when HDL gets fixed.

I would probably do the above or maybe we just need to push for an hdl fix or some
final conclusion (like if they cannot fix it for some reason) and act accordingly.

> 
> Or, if HDL can't be fixed, then we'll need the `if` now and something else
> latter to filter out extra data before pushing to IIO buffers as mentioned
> above. Though, this scenario seems odd to me as I think the HDL wouldn't be 100%
> compatible with single-channel AD4030-like parts. We would be writing code to
> support AD4030 _and_ a peculiar data stream from this specific HDL project?
> 
> My suggestion is to apply all patches except patch 8. IMHO, SPI offload
> single-channel ADC support is broken due to HDL IP data stream not being
> compatible with single-channel parts. That's not a Linux driver issue.

Well, it's not a SW issue but we are driving the HW and we know it's broken so I
don't see a point in having something that does not work. Given that this is so
connected to the HDL part of it I'm not sure it's fine to ignore that offload does
not work for 1 channel parts. 

Anyways, it's odd to me but ultimately if Jonathan is fine with it, I won't object :)


- Nuno Sá

Re: [PATCH v6 8/8] iio: adc: ad4030: Support common-mode channels with SPI offloading

[David Lechner]

On 11/3/25 8:30 AM, Nuno Sá wrote:
> On Mon, 2025-11-03 at 10:22 -0300, Marcelo Schmitt wrote:
>> On 10/30, Nuno Sá wrote:
>>> On Wed, 2025-10-29 at 15:11 -0300, Marcelo Schmitt wrote:
>>>> On 10/27, Jonathan Cameron wrote:
>>>>> On Mon, 20 Oct 2025 16:15:39 -0300
>>>>> Marcelo Schmitt <marcelo.schmitt@analog.com> wrote:
>>>>>
>>>>>> AD4030 and similar devices can read common-mode voltage together with
>>>>>> ADC sample data. When enabled, common-mode voltage data is provided in a
>>>>>> separate IIO channel since it measures something other than the primary
>>>>>> ADC input signal and requires separate scaling to convert to voltage
>>>>>> units. The initial SPI offload support patch for AD4030 only provided
>>>>>> differential channels. Now, extend the AD4030 driver to also provide
>>>>>> common-mode IIO channels when setup with SPI offloading capability.
>>>>>>
>>>>>> Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
>>>>>> ---
>>>>>> New patch.
>>>>>> I hope this works for ADCs with two channels. It's not clear if works as
>>>>>> expected with current HDL and single-channel ADCs (like ADAQ4216).
>>>>>>
>>>>>> The ad4630_fmc HDL project was designed for ADCs with two channels and
>>>>>> always streams two data channels to DMA (even when the ADC has only one
>>>>>> physical channel). Though, if the ADC has only one physical channel, the
>>>>>> data that would come from the second ADC channel comes in as noise and
>>>>>> would have to be discarded. Because of that, when using single-channel
>>>>>> ADCs, the ADC driver would need to use a special DMA buffer to filter out
>>>>>> half of the data that reaches DMA memory. With that, the ADC sample data
>>>>>> could be delivered to user space without any noise being added to the IIO
>>>>>> buffer. I have implemented a prototype of such specialized buffer
>>>>>> (industrialio-buffer-dmaengine-filtered), but it is awful and only worked
>>>>>> with CONFIG_IIO_DMA_BUF_MMAP_LEGACY (only present in ADI Linux tree). Usual
>>>>>> differential channel data is also affected by the extra 0xFFFFFFFF data
>>>>>> pushed to DMA. Though, for the differential channel, it's easier to see it
>>>>>> shall work for two-channel ADCs (the sine wave appears "filled" in
>>>>>> iio-oscilloscope).
>>>>>>
>>>>>> So, I sign this, but don't guarantee it to work.
>>>>>
>>>>> So what's the path to resolve this?  Waiting on HDL changes or not support
>>>>> those devices until we have a clean solution?
>>>>
>>>> Waiting for HDL to get updated I'd say.
>>>
>>> Agree. We kind of control the IP here so why should we do awful tricks in
>>> SW right :)? At the very least I would expect hdl to be capable to discard the
>>> data in HW.
>>>
>>>>
>>>>>
>>>>> Also, just to check, is this only an issue with the additional stuff this
>>>>> patch adds or do we have a problem with SPI offload in general (+ this
>>>>> IP) and those single channel devices?
>>>>
>>>> IMO, one solution would be to update the HDL project for AD4630 and similar ADCs
>>>> to not send data from channel 2 to DMA memory when single-channel ADCs are
>>>> connected. Another possibility would be to intercept and filter out the extra
>>>> data before pushing it to user space. My first attempt of doing that didn't
>>>> work out with upstream kernel but I may revisit that.
>>>
>>> I'm also confused. Is this also an issue with the current series without common mode?
>>>
>>> If I'm getting things right, one channel ADCs pretty much do not work right now with
>>> spi offload?
>>
>> Yes, that's correct. It kind of works for single-channel ADCs, but half of the
>> data we see in user space is valid and the other half is not. For two-channel
>> ADCs, everything should be fine.
> 
> To me that is something that does not work eheheh :). I mean, going with all this trouble
> to sample as fast as we can just so we have to discard (or mask out) half of every sample
> in userspace (even though I can imagine we still get better performance vs non offload case).

If we are getting extra data to userspace, then either we aren't creating the
SPI message correctly and telling the controller to read too much data or
the HDL is broken.

> 
>>
>>>
>>> If the above is correct I would just not support it for 1 channel ADCs.
>>
>> Currently, it's just one part that is single-channel (AD4030). If patches 6 and
>> 7 were accepted, it would be 3 single-channel parts supported. I can add an `if`
>> somewhere to check the number of channel, but it will eventually have to be
>> removed when HDL gets fixed.
> 
> I would probably do the above or maybe we just need to push for an hdl fix or some
> final conclusion (like if they cannot fix it for some reason) and act accordingly.
> 
>>
>> Or, if HDL can't be fixed, then we'll need the `if` now and something else
>> latter to filter out extra data before pushing to IIO buffers as mentioned
>> above. Though, this scenario seems odd to me as I think the HDL wouldn't be 100%
>> compatible with single-channel AD4030-like parts. We would be writing code to
>> support AD4030 _and_ a peculiar data stream from this specific HDL project?
>>
>> My suggestion is to apply all patches except patch 8. IMHO, SPI offload
>> single-channel ADC support is broken due to HDL IP data stream not being
>> compatible with single-channel parts. That's not a Linux driver issue.
> 
> Well, it's not a SW issue but we are driving the HW and we know it's broken so I
> don't see a point in having something that does not work. Given that this is so
> connected to the HDL part of it I'm not sure it's fine to ignore that offload does
> not work for 1 channel parts. 
> 
> Anyways, it's odd to me but ultimately if Jonathan is fine with it, I won't object :)
> 
> 
> - Nuno Sá

If single-channel parts currently don't work and two-channel parts need [1] or
a hardware descrambler to work with a single data line, then it sounds like we
are blocked here until the HDL is improved or [1] is merged.

[1]: https://lore.kernel.org/linux-iio/20251014-spi-add-multi-bus-support-v1-0-2098c12d6f5f@baylibre.com/

Re: [PATCH v6 8/8] iio: adc: ad4030: Support common-mode channels with SPI offloading

[Marcelo Schmitt]

On 11/03, David Lechner wrote:
> On 11/3/25 8:30 AM, Nuno Sá wrote:
> > On Mon, 2025-11-03 at 10:22 -0300, Marcelo Schmitt wrote:
> >> On 10/30, Nuno Sá wrote:
> >>> On Wed, 2025-10-29 at 15:11 -0300, Marcelo Schmitt wrote:
> >>>> On 10/27, Jonathan Cameron wrote:
> >>>>> On Mon, 20 Oct 2025 16:15:39 -0300
> >>>>> Marcelo Schmitt <marcelo.schmitt@analog.com> wrote:
> >>>>>
> >>>>>> AD4030 and similar devices can read common-mode voltage together with
> >>>>>> ADC sample data. When enabled, common-mode voltage data is provided in a
> >>>>>> separate IIO channel since it measures something other than the primary
> >>>>>> ADC input signal and requires separate scaling to convert to voltage
> >>>>>> units. The initial SPI offload support patch for AD4030 only provided
> >>>>>> differential channels. Now, extend the AD4030 driver to also provide
> >>>>>> common-mode IIO channels when setup with SPI offloading capability.
> >>>>>>
> >>>>>> Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
> >>>>>> ---
> >>>>>> New patch.
> >>>>>> I hope this works for ADCs with two channels. It's not clear if works as
> >>>>>> expected with current HDL and single-channel ADCs (like ADAQ4216).
> >>>>>>
> >>>>>> The ad4630_fmc HDL project was designed for ADCs with two channels and
> >>>>>> always streams two data channels to DMA (even when the ADC has only one
> >>>>>> physical channel). Though, if the ADC has only one physical channel, the
> >>>>>> data that would come from the second ADC channel comes in as noise and
> >>>>>> would have to be discarded. Because of that, when using single-channel
> >>>>>> ADCs, the ADC driver would need to use a special DMA buffer to filter out
> >>>>>> half of the data that reaches DMA memory. With that, the ADC sample data
> >>>>>> could be delivered to user space without any noise being added to the IIO
> >>>>>> buffer. I have implemented a prototype of such specialized buffer
> >>>>>> (industrialio-buffer-dmaengine-filtered), but it is awful and only worked
> >>>>>> with CONFIG_IIO_DMA_BUF_MMAP_LEGACY (only present in ADI Linux tree). Usual
> >>>>>> differential channel data is also affected by the extra 0xFFFFFFFF data
> >>>>>> pushed to DMA. Though, for the differential channel, it's easier to see it
> >>>>>> shall work for two-channel ADCs (the sine wave appears "filled" in
> >>>>>> iio-oscilloscope).
> >>>>>>
> >>>>>> So, I sign this, but don't guarantee it to work.
> >>>>>
> >>>>> So what's the path to resolve this?  Waiting on HDL changes or not support
> >>>>> those devices until we have a clean solution?
> >>>>
> >>>> Waiting for HDL to get updated I'd say.
> >>>
> >>> Agree. We kind of control the IP here so why should we do awful tricks in
> >>> SW right :)? At the very least I would expect hdl to be capable to discard the
> >>> data in HW.
> >>>
> >>>>
> >>>>>
> >>>>> Also, just to check, is this only an issue with the additional stuff this
> >>>>> patch adds or do we have a problem with SPI offload in general (+ this
> >>>>> IP) and those single channel devices?
> >>>>
> >>>> IMO, one solution would be to update the HDL project for AD4630 and similar ADCs
> >>>> to not send data from channel 2 to DMA memory when single-channel ADCs are
> >>>> connected. Another possibility would be to intercept and filter out the extra
> >>>> data before pushing it to user space. My first attempt of doing that didn't
> >>>> work out with upstream kernel but I may revisit that.
> >>>
> >>> I'm also confused. Is this also an issue with the current series without common mode?
> >>>
> >>> If I'm getting things right, one channel ADCs pretty much do not work right now with
> >>> spi offload?
> >>
> >> Yes, that's correct. It kind of works for single-channel ADCs, but half of the
> >> data we see in user space is valid and the other half is not. For two-channel
> >> ADCs, everything should be fine.
> > 
> > To me that is something that does not work eheheh :).
Well, yeah, I tend to agree with that 😅

> > I mean, going with all this trouble
> > to sample as fast as we can just so we have to discard (or mask out) half of every sample
> > in userspace (even though I can imagine we still get better performance vs non offload case).
> 
> If we are getting extra data to userspace, then either we aren't creating the
> SPI message correctly and telling the controller to read too much data or
> the HDL is broken.

The current patch set version (v6) only asks for the amount of ADC precision
bits in each transfer when offloading messages. I can't see how that would work
but okay, I'll test it with smaller xfer length.

> 
> > 
> >>
> >>>
> >>> If the above is correct I would just not support it for 1 channel ADCs.
> >>
> >> Currently, it's just one part that is single-channel (AD4030). If patches 6 and
> >> 7 were accepted, it would be 3 single-channel parts supported. I can add an `if`
> >> somewhere to check the number of channel, but it will eventually have to be
> >> removed when HDL gets fixed.
> > 
> > I would probably do the above or maybe we just need to push for an hdl fix or some
> > final conclusion (like if they cannot fix it for some reason) and act accordingly.
> > 
> >>
> >> Or, if HDL can't be fixed, then we'll need the `if` now and something else
> >> latter to filter out extra data before pushing to IIO buffers as mentioned
> >> above. Though, this scenario seems odd to me as I think the HDL wouldn't be 100%
> >> compatible with single-channel AD4030-like parts. We would be writing code to
> >> support AD4030 _and_ a peculiar data stream from this specific HDL project?
> >>
> >> My suggestion is to apply all patches except patch 8. IMHO, SPI offload
> >> single-channel ADC support is broken due to HDL IP data stream not being
> >> compatible with single-channel parts. That's not a Linux driver issue.
> > 
> > Well, it's not a SW issue but we are driving the HW and we know it's broken so I
> > don't see a point in having something that does not work. Given that this is so
> > connected to the HDL part of it I'm not sure it's fine to ignore that offload does
> > not work for 1 channel parts. 
> > 
> > Anyways, it's odd to me but ultimately if Jonathan is fine with it, I won't object :)
> > 
> > 
> > - Nuno Sá
> 
> If single-channel parts currently don't work and two-channel parts need [1] or
> a hardware descrambler to work with a single data line, then it sounds like we
> are blocked here until the HDL is improved or [1] is merged.
> 
> [1]: https://lore.kernel.org/linux-iio/20251014-spi-add-multi-bus-support-v1-0-2098c12d6f5f@baylibre.com/

Ack, I think so.

Re: [PATCH v6 8/8] iio: adc: ad4030: Support common-mode channels with SPI offloading

[Jonathan Cameron]

On Mon, 3 Nov 2025 18:56:21 -0300
Marcelo Schmitt <marcelo.schmitt1@gmail.com> wrote:

> On 11/03, David Lechner wrote:
> > On 11/3/25 8:30 AM, Nuno Sá wrote:  
> > > On Mon, 2025-11-03 at 10:22 -0300, Marcelo Schmitt wrote:  
> > >> On 10/30, Nuno Sá wrote:  
> > >>> On Wed, 2025-10-29 at 15:11 -0300, Marcelo Schmitt wrote:  
> > >>>> On 10/27, Jonathan Cameron wrote:  
> > >>>>> On Mon, 20 Oct 2025 16:15:39 -0300
> > >>>>> Marcelo Schmitt <marcelo.schmitt@analog.com> wrote:
> > >>>>>  
> > >>>>>> AD4030 and similar devices can read common-mode voltage together with
> > >>>>>> ADC sample data. When enabled, common-mode voltage data is provided in a
> > >>>>>> separate IIO channel since it measures something other than the primary
> > >>>>>> ADC input signal and requires separate scaling to convert to voltage
> > >>>>>> units. The initial SPI offload support patch for AD4030 only provided
> > >>>>>> differential channels. Now, extend the AD4030 driver to also provide
> > >>>>>> common-mode IIO channels when setup with SPI offloading capability.
> > >>>>>>
> > >>>>>> Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
> > >>>>>> ---
> > >>>>>> New patch.
> > >>>>>> I hope this works for ADCs with two channels. It's not clear if works as
> > >>>>>> expected with current HDL and single-channel ADCs (like ADAQ4216).
> > >>>>>>
> > >>>>>> The ad4630_fmc HDL project was designed for ADCs with two channels and
> > >>>>>> always streams two data channels to DMA (even when the ADC has only one
> > >>>>>> physical channel). Though, if the ADC has only one physical channel, the
> > >>>>>> data that would come from the second ADC channel comes in as noise and
> > >>>>>> would have to be discarded. Because of that, when using single-channel
> > >>>>>> ADCs, the ADC driver would need to use a special DMA buffer to filter out
> > >>>>>> half of the data that reaches DMA memory. With that, the ADC sample data
> > >>>>>> could be delivered to user space without any noise being added to the IIO
> > >>>>>> buffer. I have implemented a prototype of such specialized buffer
> > >>>>>> (industrialio-buffer-dmaengine-filtered), but it is awful and only worked
> > >>>>>> with CONFIG_IIO_DMA_BUF_MMAP_LEGACY (only present in ADI Linux tree). Usual
> > >>>>>> differential channel data is also affected by the extra 0xFFFFFFFF data
> > >>>>>> pushed to DMA. Though, for the differential channel, it's easier to see it
> > >>>>>> shall work for two-channel ADCs (the sine wave appears "filled" in
> > >>>>>> iio-oscilloscope).
> > >>>>>>
> > >>>>>> So, I sign this, but don't guarantee it to work.  
> > >>>>>
> > >>>>> So what's the path to resolve this?  Waiting on HDL changes or not support
> > >>>>> those devices until we have a clean solution?  
> > >>>>
> > >>>> Waiting for HDL to get updated I'd say.  
> > >>>
> > >>> Agree. We kind of control the IP here so why should we do awful tricks in
> > >>> SW right :)? At the very least I would expect hdl to be capable to discard the
> > >>> data in HW.
> > >>>  
> > >>>>  
> > >>>>>
> > >>>>> Also, just to check, is this only an issue with the additional stuff this
> > >>>>> patch adds or do we have a problem with SPI offload in general (+ this
> > >>>>> IP) and those single channel devices?  
> > >>>>
> > >>>> IMO, one solution would be to update the HDL project for AD4630 and similar ADCs
> > >>>> to not send data from channel 2 to DMA memory when single-channel ADCs are
> > >>>> connected. Another possibility would be to intercept and filter out the extra
> > >>>> data before pushing it to user space. My first attempt of doing that didn't
> > >>>> work out with upstream kernel but I may revisit that.  
> > >>>
> > >>> I'm also confused. Is this also an issue with the current series without common mode?
> > >>>
> > >>> If I'm getting things right, one channel ADCs pretty much do not work right now with
> > >>> spi offload?  
> > >>
> > >> Yes, that's correct. It kind of works for single-channel ADCs, but half of the
> > >> data we see in user space is valid and the other half is not. For two-channel
> > >> ADCs, everything should be fine.  
> > > 
> > > To me that is something that does not work eheheh :).  
> Well, yeah, I tend to agree with that 😅
> 
> > > I mean, going with all this trouble
> > > to sample as fast as we can just so we have to discard (or mask out) half of every sample
> > > in userspace (even though I can imagine we still get better performance vs non offload case).  
> > 
> > If we are getting extra data to userspace, then either we aren't creating the
> > SPI message correctly and telling the controller to read too much data or
> > the HDL is broken.  
> 
> The current patch set version (v6) only asks for the amount of ADC precision
> bits in each transfer when offloading messages. I can't see how that would work
> but okay, I'll test it with smaller xfer length.
> 
> >   
> > >   
> > >>  
> > >>>
> > >>> If the above is correct I would just not support it for 1 channel ADCs.  
> > >>
> > >> Currently, it's just one part that is single-channel (AD4030). If patches 6 and
> > >> 7 were accepted, it would be 3 single-channel parts supported. I can add an `if`
> > >> somewhere to check the number of channel, but it will eventually have to be
> > >> removed when HDL gets fixed.  
> > > 
> > > I would probably do the above or maybe we just need to push for an hdl fix or some
> > > final conclusion (like if they cannot fix it for some reason) and act accordingly.
> > >   
> > >>
> > >> Or, if HDL can't be fixed, then we'll need the `if` now and something else
> > >> latter to filter out extra data before pushing to IIO buffers as mentioned
> > >> above. Though, this scenario seems odd to me as I think the HDL wouldn't be 100%
> > >> compatible with single-channel AD4030-like parts. We would be writing code to
> > >> support AD4030 _and_ a peculiar data stream from this specific HDL project?
> > >>
> > >> My suggestion is to apply all patches except patch 8. IMHO, SPI offload
> > >> single-channel ADC support is broken due to HDL IP data stream not being
> > >> compatible with single-channel parts. That's not a Linux driver issue.  
> > > 
> > > Well, it's not a SW issue but we are driving the HW and we know it's broken so I
> > > don't see a point in having something that does not work. Given that this is so
> > > connected to the HDL part of it I'm not sure it's fine to ignore that offload does
> > > not work for 1 channel parts. 
> > > 
> > > Anyways, it's odd to me but ultimately if Jonathan is fine with it, I won't object :)
> > > 
> > > 
> > > - Nuno Sá  
> > 
> > If single-channel parts currently don't work and two-channel parts need [1] or
> > a hardware descrambler to work with a single data line, then it sounds like we
> > are blocked here until the HDL is improved or [1] is merged.
> > 
> > [1]: https://lore.kernel.org/linux-iio/20251014-spi-add-multi-bus-support-v1-0-2098c12d6f5f@baylibre.com/  
> 
> Ack, I think so.

OK.  So let me know (send a new version) when we have something we can move forwards with.

Looks to me like we should rule out single channel parts + spi offload for now.
I'll take a look at [1] later today.

Jonathan