From: David Lechner <dlechner@baylibre.com>
To: "Sabau, Radu bogdan" <Radu.Sabau@analog.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>
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>
Subject: Re: [PATCH v3 3/4] iio: adc: ad4691: add triggered buffer support
Date: Mon, 16 Mar 2026 11:44:44 -0500 [thread overview]
Message-ID: <06b48810-f997-40a4-86db-d3b7db9dfc18@baylibre.com> (raw)
In-Reply-To: <LV9PR03MB84146ADC269645000849795AF740A@LV9PR03MB8414.namprd03.prod.outlook.com>
On 3/16/26 10:56 AM, Sabau, Radu bogdan wrote:
>
>
>> -----Original Message-----
>> From: David Lechner <dlechner@baylibre.com>
>> Sent: Monday, March 16, 2026 5:38 PM
>> To: Sabau, Radu bogdan <Radu.Sabau@analog.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>
>> Cc: linux-iio@vger.kernel.org; devicetree@vger.kernel.org; linux-
>> kernel@vger.kernel.org; linux-pwm@vger.kernel.org; linux-
>> gpio@vger.kernel.org
>> Subject: Re: [PATCH v3 3/4] iio: adc: ad4691: add triggered buffer support
>>
>> [External]
>>
>> On 3/16/26 8:22 AM, Sabau, Radu bogdan wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: David Lechner <dlechner@baylibre.com>
>>>> Sent: Saturday, March 14, 2026 8:38 PM
>>>
>>> ...
>>>
>>>>> Both operating modes share a single IIO trigger and trigger handler.
>>>>> The handler builds a complete scan — one u32 slot per channel at its
>>>>> scan_index position, followed by a timestamp — and pushes it to the
>>>>> IIO buffer in a single iio_push_to_buffers_with_ts() call.
>>>>
>>>> It would really help here to see some timing diagrams to know if we
>>>> are implementing this right.
>>>>
>>>> For example, it isn't clear that in clocked mode if CNV triggers a
>>>> single conversion in the sequencer (i.e. IIO_SAMP_FREQ should be
>>>> info_mask_separate) or if it triggers the sequence (i.e. IIO_SAMP_FREQ
>>>> should be info_mask_shared_by_all).
>>>>
>>>
>>> The CNV triggers the sequence and IIO_SAMP_FREQ is
>> info_mask_shared_by_all.
>>>
>>> As per datasheet page 31 (Accumulator Section), when each accumulator
>>> receives a sample, the ACC_COUNT is increased. In clocked mode we
>>> are setting the ACC_COUNT limit to 1, therefore having one sample per
>>> channel (no oversampling as discussed in previous versions). So each
>>> period of the CNV PWM is respective to one sample of a channel.
>>
>> Assuming that "a" channel means "one" channel...
>>
>> In this case then sampling_frequency should be per channel (separate).
>>
>> A sampling_frequency that is shared_by_all means that each period of
>> CNV should trigger one sample each for _all_ channels. In other words,
>> the sampling frequency gives one complete set of samples for all enabled
>> channels pushed to the buffer.
>>
>
> Oh, ok then, will have them separate. I assumed that since the PWM period
> is constant with each pulse, then the sampling rate will be the same for
> each channel, thus having them as shared_by_all, but I assume you are
> right about this in this case, I will have them as separate in this case, the
> update will happen in the previous patch upon next version.
>
Does the sampling stop after one "burst" (reading each enabled channel once)?
If yes, then what controls when the next set of samples starts?
Looking at Figure 63 in the datasheet for CNV Clock mode, it looks like it
depends entirely on how long the SPI message takes. So the actual sample rate
is going to be quite random instead of the sum of each channel as the IIO ABI
says it should. It seems a waste of the PWM to do it this way since we end
up with a random sample rate.
It seems to me like the CNV Burst mode would actually be better suited to
how IIO usually does things. In this case, the PWM frequency would control
the effective sample rate (one PWM pulse triggers one complete set of
samples) and the internal oscillator controls triggering each individual
conversion.
In this setup, we would still have the info_mask_separate IIO_SAMP_FREQ,
but it would control the internal oscillator. Then we would have a separate
buffer0/sampling_frequency attribute that controlled the PWM frequency.
Then, as long as the PWM frequency was slow enough that the SPI message
can be done, it can make samples with almost no jitter. This is why I would
expect PWM to almost always be used with SPI offload though, otherwise
it has to be quite slow compared to what the chip is capable of.
I suppose the CNV Clock mode could also be made to work with the typical
IIO trigger so that we could control the actual sample rate. It just
wouldn't be as precise.
If you have some examples of how this chip should actually be used in the
real world, that could help pick what is the right thing to do here.
next prev parent reply other threads:[~2026-03-16 16:44 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-13 10:07 [PATCH v3 0/4] iio: adc: ad4691: add driver for AD4691 multichannel SAR ADC family Radu Sabau via B4 Relay
2026-03-13 10:07 ` [PATCH v3 1/4] dt-bindings: iio: adc: add bindings for AD4691 family Radu Sabau via B4 Relay
2026-03-14 9:41 ` Krzysztof Kozlowski
2026-03-16 11:55 ` Sabau, Radu bogdan
2026-03-14 15:29 ` David Lechner
2026-03-14 16:19 ` David Lechner
2026-03-16 12:39 ` Sabau, Radu bogdan
2026-03-16 12:55 ` Sabau, Radu bogdan
2026-03-16 15:14 ` David Lechner
2026-03-16 15:47 ` Sabau, Radu bogdan
2026-03-14 18:18 ` David Lechner
2026-03-13 10:07 ` [PATCH v3 2/4] iio: adc: ad4691: add initial driver " Radu Sabau via B4 Relay
2026-03-13 10:58 ` Andy Shevchenko
2026-03-16 15:29 ` Sabau, Radu bogdan
2026-03-16 15:51 ` David Lechner
2026-03-16 15:57 ` Sabau, Radu bogdan
2026-03-16 16:13 ` Andy Shevchenko
2026-03-14 11:04 ` Nuno Sá
2026-03-16 14:29 ` Sabau, Radu bogdan
2026-03-16 16:00 ` Sabau, Radu bogdan
2026-03-14 16:36 ` David Lechner
2026-03-16 13:01 ` Sabau, Radu bogdan
2026-03-25 15:01 ` kernel test robot
2026-03-13 10:07 ` [PATCH v3 3/4] iio: adc: ad4691: add triggered buffer support Radu Sabau via B4 Relay
2026-03-13 11:13 ` Andy Shevchenko
2026-03-13 12:09 ` Sabau, Radu bogdan
2026-03-13 14:40 ` Andy Shevchenko
2026-03-14 18:37 ` David Lechner
2026-03-16 13:22 ` Sabau, Radu bogdan
2026-03-16 15:37 ` David Lechner
2026-03-16 15:56 ` Sabau, Radu bogdan
2026-03-16 16:44 ` David Lechner [this message]
2026-03-17 9:27 ` Sabau, Radu bogdan
2026-03-13 10:07 ` [PATCH v3 4/4] iio: adc: ad4691: add SPI offload support Radu Sabau via B4 Relay
2026-03-14 19:37 ` David Lechner
2026-03-16 13:31 ` Sabau, Radu bogdan
2026-03-13 11:14 ` [PATCH v3 0/4] iio: adc: ad4691: add driver for AD4691 multichannel SAR ADC family Andy Shevchenko
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=06b48810-f997-40a4-86db-d3b7db9dfc18@baylibre.com \
--to=dlechner@baylibre.com \
--cc=Michael.Hennerich@analog.com \
--cc=Nuno.Sa@analog.com \
--cc=Radu.Sabau@analog.com \
--cc=andy@kernel.org \
--cc=brgl@kernel.org \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jic23@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=lars@metafoo.de \
--cc=lgirdwood@gmail.com \
--cc=linusw@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=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).