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: Tue, 7 Apr 2026 12:38:27 +0000 [thread overview]
Message-ID: <LV9PR03MB8414DE6AA9FC7BB7B6326888F75AA@LV9PR03MB8414.namprd03.prod.outlook.com> (raw)
In-Reply-To: <420dba4a-0c31-47bc-b84a-5d29702b115e@baylibre.com>
> -----Original Message-----
> From: David Lechner <dlechner@baylibre.com>
> Sent: Monday, April 6, 2026 4:44 PM
...
> >> 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?
>
> I haven't figured out a good way to do this since the real max rate
> depends on a lot of different things and when not using offloading,
> the time it takes to do SPI xfers is non-deterministic.
>
There is another question that pops in my mind. How would osr work for the buffer
sampling frequency? Since that controls the PWM period, and if say channels 0, 1, 2
are used with osr 1, 4, 8 respectively, then it would mean the PWM "required
frequency" would be something like :
osr_avg = (osr[0] + osr[1] + osr[2]) / 3;
actual_samp_freq = samp_freq / osr_avg;
The problem here being - beside what you already stated that the xfer is non-deterministic -
that the implementation could be fragile, since buffer_sampling frequency wouldn't really
know for sure which channels are enabled and so couldn't account for osr in a safe way.
The solution I propose is letting PWM run from buffer enable to disable, the whole time,
while only disabling/enabling the irq in the handler before and after spi transfer, to also
assure they are rightly happening. This way, the PWM runs at the desired rate, the only
thing here is that if the PWM is set to a too high of a frequency, some periods will be
missed, which is normal if you think about it.
For example : if the user uses a 1MHz SPI for some reason, and wants a PWM of 500kHz,
and enables 4 channels with maximum osr and maximum per-channel samp_freq.
tPWM = 1/500kHz = 2us;
tOSR_per_channel = 32 * tOSC = 32us;
-> tPWM is already too fast, but there would be more
tOSR_total = 4 * 32 = 128us;
tSPI_per_channel = 32 * tSPI = 32us (too say the least)
tSPI_total = 128us;
tSEQ_total = 256us (again, to say the least)
so the actual sampling freq is 256us in this case, but that's non-determinstic, since this
is nothing but a best case scenario, time would vary between 256-280us to say so in
reality.
I would then say so, setting a too high buffer sampling frequency (PWM frequency) implies
by itself that samples will be missed.
So then, PWM freq should be set by the user, to the desired value without capping of the
value since that capping depends on too much run-time variables set by the same user.
next prev parent reply other threads:[~2026-04-07 12:39 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
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 [this message]
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=LV9PR03MB8414DE6AA9FC7BB7B6326888F75AA@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).