Message-ID: <20251109121259.4e4c1f3f@jic23-huawei>
Date: Sun, 9 Nov 2025 12:12:59 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Marcelo Schmitt <marcelo.schmitt1@...il.com>
Cc: David Lechner <dlechner@...libre.com>, Nuno Sá
 <noname.nuno@...il.com>, 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,
 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 Mon, 3 Nov 2025 18:56:21 -0300
Marcelo Schmitt <marcelo.schmitt1@...il.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@...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.  
> > > 
> > > 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

Powered by blists - more mailing lists