Message-ID: <aQisqe5EWARTwpQq@debian-BULLSEYE-live-builder-AMD64>
Date: Mon, 3 Nov 2025 10:22:49 -0300
From: Marcelo Schmitt <marcelo.schmitt1@...il.com>
To: Nuno Sá <noname.nuno@...il.com>
Cc: Jonathan Cameron <jic23@...nel.org>,
	Marcelo Schmitt <marcelo.schmitt@...log.com>,
	linux-iio@...r.kernel.org, devicetree@...r.kernel.org,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	michael.hennerich@...log.com, nuno.sa@...log.com,
	eblanc@...libre.com, dlechner@...libre.com, andy@...nel.org,
	robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org,
	corbet@....net
Subject: Re: [PATCH v6 8/8] iio: adc: ad4030: Support common-mode channels
 with SPI offloading

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@...log.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@...log.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.

Powered by blists - more mailing lists