From: "Sabau, Radu bogdan" <Radu.Sabau@analog.com>
To: "David Lechner" <dlechner@baylibre.com>,
"Lars-Peter Clausen" <lars@metafoo.de>,
"Hennerich, Michael" <Michael.Hennerich@analog.com>,
"Jonathan Cameron" <jic23@kernel.org>,
"Sa, Nuno" <Nuno.Sa@analog.com>,
"Andy Shevchenko" <andy@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Uwe Kleine-König" <ukleinek@kernel.org>,
"Liam Girdwood" <lgirdwood@gmail.com>,
"Mark Brown" <broonie@kernel.org>,
"Linus Walleij" <linusw@kernel.org>,
"Bartosz Golaszewski" <brgl@kernel.org>,
"Philipp Zabel" <p.zabel@pengutronix.de>,
"Jonathan Corbet" <corbet@lwn.net>,
"Shuah Khan" <skhan@linuxfoundation.org>
Cc: "linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-pwm@vger.kernel.org" <linux-pwm@vger.kernel.org>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>
Subject: RE: [PATCH v6 4/4] iio: adc: ad4691: add SPI offload support
Date: Mon, 6 Apr 2026 09:34:35 +0000 [thread overview]
Message-ID: <LV9PR03MB84145906CC191F6AB8D2D3DAF75DA@LV9PR03MB8414.namprd03.prod.outlook.com> (raw)
In-Reply-To: <1d0d41c8-7867-4459-a91a-a2c6774b1885@baylibre.com>
> -----Original Message-----
> From: David Lechner <dlechner@baylibre.com>
> Sent: Saturday, April 4, 2026 6:34 PM
...
> >
> > Add driver documentation under Documentation/iio/ad4691.rst covering
> > operating modes, oversampling, reference voltage, SPI offload paths,
> > and buffer data layout; register in MAINTAINERS and index.rst
>
> Documentation should be separate patch. It covers more than just SPI
> offload.
>
Noted. Thanks for this.
> >
> > Kconfig gains a dependency on IIO_BUFFER_DMAENGINE.
> >
> > Signed-off-by: Radu Sabau <radu.sabau@analog.com>
> > ---
...
> > +Selected when a ``pwms`` property is present in the device tree. The PWM
> drives
> > +the CNV pin independently of SPI at the configured conversion rate, and a
> GP
> > +pin (identified by ``interrupt-names``) asserts DATA_READY at end-of-burst
> to
> > +signal that the AVG_IN result registers are ready to be read.
> > +
> > +The IRQ handler stops the PWM, fires the IIO trigger, and the trigger
> handler
>
> If we stop the PWM after an IRQ, then we don't get a consistent sample rate.
> Ideally, we would leave the PWM running and just pick a rate slow enough
> that
> there is plenty of time to read the data. Otherwise, this mode doesn't seem
> particularly useful.
Should there also be a condition when setting the sampling frequency, that will
protect from setting too fast sample rates?
>
> > +reads all active ``AVG_IN(n)`` registers in a single optimised SPI message and
> > +pushes the scan to the buffer.
> > +
> > +The buffer sampling frequency (i.e. the PWM rate) is controlled by the
> > +``sampling_frequency`` attribute on the IIO buffer. Valid values span from
> the
> > +chip's minimum oscillator rate up to its maximum conversion rate
> > +(500 kSPS for AD4691/AD4693, 1 MSPS for AD4692/AD4694).
>
> Valid, but not usable without SPI offload.
The PWM is also be used with triggered-buffer in CNV Burst Mode.
>
> > +
> > +Autonomous Mode (idle / single-shot)
> > +-------------------------------------
> > +
...
> > +
> > +Manual offload
> > +--------------
> > +
> > +Used when no ``pwms`` property is present and SPI offload is available.
> > +
> > +A periodic SPI offload trigger controls the conversion rate. On each trigger
> > +period, the SPI engine executes an N+1 transfer message (same pipelined
> scheme
>
> How does this work with oversampling?
As per previous versions discussions, Manual Mode doesn't support oversampling,
since the chip only transfers the raw unfiltered 16-bit data without register interaction
in this mode.
>
> > +as software Manual Mode) and streams the data directly to the IIO DMA
> buffer.
...
> > +IIO DMA buffer:
> > +
> > +* **CNV Burst offload**: the SPI engine reads AVG_IN registers with a 2-
> byte
> > + address phase followed by a 2-byte data phase; the 16-bit result lands in
> > + the lower half of the 32-bit word (``shift=0``).
> > +* **Manual offload**: each 32-bit SPI word carries the channel byte in the
> > + first byte; the 16-bit result is returned in the upper half of the 32-bit
>
> I would expect the "first" byte to be in the "upper half" of the 32-bits as
> well. This layout could be explained better.
>
> Also, since extra data has to be read in this mode, does this affect the max
> conversion rate?
This is bad documentation on my part. "channel byte" isn't used anymore,
this is previous version behaviour. Right now, only 16-bits worth of actual
channel data are used.
>
> > + word (``shift=16``).
> > +
> > +The ``in_voltageN_type`` sysfs attribute reflects the active scan type.
> > +
> > +
> > +Unimplemented features
> > +======================
> > +
> > +* GPIO controller functionality of the GP pins
> > +* Clamp status and overrange events
> > +* Raw accumulator (ACC_IN) and accumulator status registers
> > +* ADC_BUSY and overrun status interrupts
next prev parent reply other threads:[~2026-04-06 9:34 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-03 11:03 [PATCH v6 0/4] iio: adc: ad4691: add driver for AD4691 multichannel SAR ADC family Radu Sabau via B4 Relay
2026-04-03 11:03 ` [PATCH v6 1/4] dt-bindings: iio: adc: add AD4691 family Radu Sabau via B4 Relay
2026-04-03 11:03 ` [PATCH v6 2/4] iio: adc: ad4691: add initial driver for " Radu Sabau via B4 Relay
2026-04-04 14:25 ` David Lechner
2026-04-03 11:03 ` [PATCH v6 3/4] iio: adc: ad4691: add triggered buffer support Radu Sabau via B4 Relay
2026-04-04 15:12 ` David Lechner
2026-04-05 8:57 ` Andy Shevchenko
2026-04-06 9:22 ` Sabau, Radu bogdan
2026-04-06 13:39 ` David Lechner
2026-04-03 11:03 ` [PATCH v6 4/4] iio: adc: ad4691: add SPI offload support Radu Sabau via B4 Relay
2026-04-04 15:34 ` David Lechner
2026-04-06 9:34 ` Sabau, Radu bogdan [this message]
2026-04-06 13:44 ` David Lechner
2026-04-06 14:16 ` Sabau, Radu bogdan
2026-04-06 15:02 ` David Lechner
2026-04-07 12:38 ` Sabau, Radu bogdan
2026-04-04 15:57 ` David Lechner
2026-04-06 10:39 ` Sabau, Radu bogdan
2026-04-06 11:08 ` Sabau, Radu bogdan
2026-04-06 13:30 ` Sabau, Radu bogdan
2026-04-06 13:56 ` David Lechner
2026-04-06 14:20 ` Sabau, Radu bogdan
2026-04-06 13:53 ` 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=LV9PR03MB84145906CC191F6AB8D2D3DAF75DA@LV9PR03MB8414.namprd03.prod.outlook.com \
--to=radu.sabau@analog.com \
--cc=Michael.Hennerich@analog.com \
--cc=Nuno.Sa@analog.com \
--cc=andy@kernel.org \
--cc=brgl@kernel.org \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=corbet@lwn.net \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--cc=jic23@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=lars@metafoo.de \
--cc=lgirdwood@gmail.com \
--cc=linusw@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=robh@kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=ukleinek@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 read-only IMAP folder(s) and NNTP newsgroup(s).