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

[Marcelo Schmitt <marcelo.schmitt1@gmail.com>]

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.