devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Nuno Sá" <noname.nuno@gmail.com>
To: Marcelo Schmitt <marcelo.schmitt1@gmail.com>,
	Jonathan Cameron <jic23@kernel.org>
Cc: Marcelo Schmitt <marcelo.schmitt@analog.com>,
	linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
	linux-doc@vger.kernel.org,  linux-kernel@vger.kernel.org,
	michael.hennerich@analog.com, nuno.sa@analog.com,
		eblanc@baylibre.com, dlechner@baylibre.com, andy@kernel.org,
	robh@kernel.org, 	krzk+dt@kernel.org, conor+dt@kernel.org,
	corbet@lwn.net
Subject: Re: [PATCH v6 8/8] iio: adc: ad4030: Support common-mode channels with SPI offloading
Date: Thu, 30 Oct 2025 09:28:54 +0000	[thread overview]
Message-ID: <ca6760182b4662c96df6204bae903d8affa6a8e3.camel@gmail.com> (raw)
In-Reply-To: <aQJY7XizVWbE68ll@debian-BULLSEYE-live-builder-AMD64>

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á

  reply	other threads:[~2025-10-30  9:28 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-20 19:13 [PATCH v6 0/8] Add SPI offload support to AD4030 Marcelo Schmitt
2025-10-20 19:13 ` [PATCH v6 1/8] dt-bindings: iio: adc: adi,ad4030: Reference spi-peripheral-props Marcelo Schmitt
2025-10-20 19:13 ` [PATCH v6 2/8] Docs: iio: ad4030: Add double PWM SPI offload doc Marcelo Schmitt
2025-10-20 19:14 ` [PATCH v6 3/8] dt-bindings: iio: adc: adi,ad4030: Add PWM Marcelo Schmitt
2025-10-20 19:14 ` [PATCH v6 4/8] iio: adc: ad4030: Use BIT macro to improve code readability Marcelo Schmitt
2025-10-20 19:14 ` [PATCH v6 5/8] iio: adc: ad4030: Add SPI offload support Marcelo Schmitt
2025-10-20 19:15 ` [PATCH v6 6/8] dt-bindings: iio: adc: adi,ad4030: Add ADAQ4216 and ADAQ4224 Marcelo Schmitt
2025-10-20 19:15 ` [PATCH v6 7/8] iio: adc: ad4030: Add support for " Marcelo Schmitt
2025-10-20 19:15 ` [PATCH v6 8/8] iio: adc: ad4030: Support common-mode channels with SPI offloading Marcelo Schmitt
2025-10-27 14:04   ` Jonathan Cameron
2025-10-29 18:11     ` Marcelo Schmitt
2025-10-30  9:28       ` Nuno Sá [this message]
2025-11-03 13:22         ` Marcelo Schmitt
2025-11-03 14:30           ` Nuno Sá
2025-11-03 14:46             ` David Lechner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ca6760182b4662c96df6204bae903d8affa6a8e3.camel@gmail.com \
    --to=noname.nuno@gmail.com \
    --cc=andy@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=corbet@lwn.net \
    --cc=devicetree@vger.kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=eblanc@baylibre.com \
    --cc=jic23@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo.schmitt1@gmail.com \
    --cc=marcelo.schmitt@analog.com \
    --cc=michael.hennerich@analog.com \
    --cc=nuno.sa@analog.com \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).