From: David Lechner <dlechner@baylibre.com>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: "Jonathan Cameron" <jic23@kernel.org>,
"Julien Stephan" <jstephan@baylibre.com>,
"Lars-Peter Clausen" <lars@metafoo.de>,
"Michael Hennerich" <Michael.Hennerich@analog.com>,
"Nuno Sá" <nuno.sa@analog.com>, "Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Liam Girdwood" <lgirdwood@gmail.com>,
"Mark Brown" <broonie@kernel.org>,
"kernel test robot" <lkp@intel.com>,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC v6 09/10] iio: adc: ad7380: add support for rolling average oversampling mode
Date: Thu, 9 May 2024 17:01:14 -0500 [thread overview]
Message-ID: <CAMknhBH=R2D4yu6Psnh+gv=OpCNAEwi8fpvMcJd0n9-SBfNWqg@mail.gmail.com> (raw)
In-Reply-To: <20240508122556.00005f71@Huawei.com>
On Wed, May 8, 2024 at 6:26 AM Jonathan Cameron
<Jonathan.Cameron@huawei.com> wrote:
>
> On Mon, 6 May 2024 10:04:10 -0500
> David Lechner <dlechner@baylibre.com> wrote:
>
> > On Mon, May 6, 2024 at 9:17 AM Jonathan Cameron <jic23@kernel.org> wrote:
> > >
> > > On Wed, 01 May 2024 16:55:42 +0200
> > > Julien Stephan <jstephan@baylibre.com> wrote:
> > >
> > > > Adds support for rolling average oversampling mode.
> > > >
> > > > Rolling oversampling mode uses a first in, first out (FIFO) buffer of
> > > > the most recent samples in the averaging calculation, allowing the ADC
> > > > throughput rate and output data rate to stay the same, since we only need
> > > > to take only one sample for each new conversion.
> > > >
> > > > The FIFO length is 8, thus the available oversampling ratios are 1, 2, 4, 8
> > > > in this mode (vs 1, 2, 4, 8, 16, 32 for the normal average)
> > >
> > > Ah. I should have read on!
> > >
> > > >
> > > > In order to be able to change the averaging mode, this commit also adds
> > > > the new "oversampling_mode" and "oversampling_mode_available" custom
> > > > attributes along with the according documentation file in
> > > > Documentation/ABI/testing/sysfs-bus-iio-adc-ad7380 since no standard
> > > > attributes correspond to this use case.
> > >
> > > This comes to the comment I stuck in the previous patch.
> > >
> > > To most people this is not a form of oversampling because the data rate
> > > remains unchanged. It's a cheap low pass filter (boxcar) Google pointed me at:
> > > https://dsp.stackexchange.com/questions/9966/what-is-the-cut-off-frequency-of-a-moving-average-filter
> > >
> > > in_voltage_low_pass_3db_frequency would be the most appropriate standard
> > > ABI for this if we do treat it as a low pass filter control.
> > >
> > > I'm not necessarily saying we don't want new ABI for this, but I would
> > > like to consider the pros and cons of just using the 3db frequency.
> > >
> > > So would that work for this part or am I missing something?
> > >
> >
> > I like the idea. But from the link, it looks like the 3dB frequency
> > depends on the sampling frequency which is unknown (e.g. could come
> > from hrtimer trigger).
> >
> > Would it be reasonable to calculate the 3db frequency at the max
> > sample rate that the chip allows and just use those numbers?
> >
> Ah. So looking at datasheet the normal average oversampling is
> self clocked, but this version is not.
>
> So, I'll ask the dumb question. What is this feature for?
> We have to pump the SPI bus anyway why not just do the maths in
> userspace? Oversampling is normally about data rate reduction
> with a bonus in precision obtained.
>
> Jonathan
>
I asked the apps engineers and the answer I got is that it a way to
enable oversampling while still maintaining a high sample rate.
Another thing to consider here is that we can only enable the extra
resolution bits if oversampling is enabled (normal or rolling mode).
The chip might not work right if we try to enable the extra bits
without oversampling enabled.
So my thinking is perhaps it is better to keep the rolling mode as
oversampling rather than trying to call it a low pass filter. As you
said, normal mode is about data rate reduction with bonus precision.
Rolling average oversampling mode then would then just be for the
bonus precision.
next prev parent reply other threads:[~2024-05-09 22:01 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-01 14:55 [PATCH RFC v6 00/10] iio: adc: add new ad7380 driver Julien Stephan
2024-05-01 14:55 ` [PATCH RFC v6 01/10] dt-bindings: iio: adc: Add binding for AD7380 ADCs Julien Stephan
2024-05-01 14:55 ` [PATCH RFC v6 02/10] iio: adc: ad7380: new driver " Julien Stephan
2024-05-06 13:56 ` Jonathan Cameron
2024-05-01 14:55 ` [PATCH RFC v6 03/10] dt-bindings: iio: adc: ad7380: add pseudo-differential parts Julien Stephan
2024-05-01 14:55 ` [PATCH RFC v6 04/10] iio: adc: ad7380: add support for " Julien Stephan
2024-05-01 14:55 ` [PATCH RFC v6 05/10] iio: adc: ad7380: prepare for parts with more channels Julien Stephan
2024-05-01 14:55 ` [PATCH RFC v6 06/10] dt-bindings: iio: adc: ad7380: add support for ad738x-4 4 channels variants Julien Stephan
2024-05-01 14:55 ` [PATCH RFC v6 07/10] " Julien Stephan
2024-05-01 14:55 ` [PATCH RFC v6 08/10] iio: adc: ad7380: add oversampling support Julien Stephan
2024-05-06 8:20 ` Nuno Sá
2024-05-06 14:05 ` Jonathan Cameron
2024-05-01 14:55 ` [PATCH RFC v6 09/10] iio: adc: ad7380: add support for rolling average oversampling mode Julien Stephan
2024-05-06 8:33 ` Nuno Sá
2024-05-06 14:17 ` Jonathan Cameron
2024-05-06 15:04 ` David Lechner
2024-05-08 11:25 ` Jonathan Cameron
2024-05-09 22:01 ` David Lechner [this message]
2024-05-11 11:47 ` Jonathan Cameron
2024-05-01 14:55 ` [PATCH RFC v6 10/10] iio: adc: ad7380: add support for resolution boost Julien Stephan
2024-05-06 8:55 ` Nuno Sá
2024-05-06 13:46 ` Jonathan Cameron
2024-05-06 14:20 ` Jonathan Cameron
2024-05-06 14:44 ` David Lechner
2024-05-08 11:32 ` Jonathan Cameron
2024-05-06 15:09 ` David Lechner
2024-05-06 14:29 ` Jonathan Cameron
2024-05-06 21:45 ` 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='CAMknhBH=R2D4yu6Psnh+gv=OpCNAEwi8fpvMcJd0n9-SBfNWqg@mail.gmail.com' \
--to=dlechner@baylibre.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=Michael.Hennerich@analog.com \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jic23@kernel.org \
--cc=jstephan@baylibre.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lars@metafoo.de \
--cc=lgirdwood@gmail.com \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.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 read-only IMAP folder(s) and NNTP newsgroup(s).