From: Jonathan Cameron <jic23@kernel.org>
To: Jonathan Santos <Jonathan.Santos@analog.com>
Cc: <linux-iio@vger.kernel.org>, <devicetree@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <linux-gpio@vger.kernel.org>,
<lars@metafoo.de>, <Michael.Hennerich@analog.com>,
<marcelo.schmitt@analog.com>, <robh@kernel.org>,
<krzk+dt@kernel.org>, <conor+dt@kernel.org>,
<linus.walleij@linaro.org>, <brgl@bgdev.pl>,
<lgirdwood@gmail.com>, <broonie@kernel.org>,
<dlechner@baylibre.com>, <marcelo.schmitt1@gmail.com>,
<jonath4nns@gmail.com>, Pop Paul <paul.pop@analog.com>
Subject: Re: [PATCH v4 16/17] iio: adc: ad7768-1: add filter type and oversampling ratio attributes
Date: Sat, 8 Mar 2025 13:56:20 +0000 [thread overview]
Message-ID: <20250308135620.3c95b951@jic23-huawei> (raw)
In-Reply-To: <3586a75e3b7bf09c271a44390b2fed9f1ffc8565.1741268122.git.Jonathan.Santos@analog.com>
On Thu, 6 Mar 2025 18:04:24 -0300
Jonathan Santos <Jonathan.Santos@analog.com> wrote:
> Separate filter type and decimation rate from the sampling frequency
> attribute. The new filter type attribute enables sinc3, sinc3+rej60
> and wideband filters, which were previously unavailable.
>
> Previously, combining decimation and MCLK divider in the sampling
> frequency obscured performance trade-offs. Lower MCLK divider
> settings increase power usage, while lower decimation rates reduce
> precision by decreasing averaging. By creating an oversampling
> attribute, which controls the decimation, users gain finer control
> over performance.
>
> The addition of those attributes allows a wider range of sampling
> frequencies and more access to the device features. Sampling frequency
> table is updated after every digital filter paramerter change.
>
> Co-developed-by: Pop Paul <paul.pop@analog.com>
> Signed-off-by: Pop Paul <paul.pop@analog.com>
> Signed-off-by: Jonathan Santos <Jonathan.Santos@analog.com>
> ---
> v4 Changes:
> * Sampling frequency table is dinamically updated after every
Good to spell check. Dynamically
> filter configuration.
Currently this runs into the potential race conditions we get with
read_avail callbacks. If we update the avail values in parallel
with consumer code in a kernel driver reading them we can get tearing.
So better if possible to do it all before those interfaces are exposed
and just pick from a set of static arrays.
> +static struct iio_chan_spec_ext_info ad7768_ext_info[] = {
> + IIO_ENUM("filter_type", IIO_SHARED_BY_ALL, &ad7768_flt_type_iio_enum),
> + IIO_ENUM_AVAILABLE("filter_type", IIO_SHARED_BY_ALL, &ad7768_flt_type_iio_enum),
> + { },
No trailing comma on a terminating entry as we don't want it to be easy
to accidentally add stuff after this.
> +};
> +static int ad7768_configure_dig_fil(struct iio_dev *dev,
> + enum ad7768_filter_type filter_type,
> + unsigned int dec_rate)
> +{
> + struct ad7768_state *st = iio_priv(dev);
> + unsigned int dec_rate_idx, dig_filter_regval;
> + int ret;
> +
> + switch (filter_type) {
> + case AD7768_FILTER_SINC3:
> + dig_filter_regval = AD7768_DIG_FIL_FIL(AD7768_FILTER_REGVAL_SINC3);
> + break;
> + case AD7768_FILTER_SINC3_REJ60:
> + dig_filter_regval = AD7768_DIG_FIL_FIL(AD7768_FILTER_REGVAL_SINC3_REJ60);
> + break;
> + case AD7768_FILTER_WIDEBAND:
> + /* Skip decimations 8 and 16, not supported by the wideband filter */
> + dec_rate_idx = find_closest(dec_rate, &ad7768_dec_rate_values[2],
> + ARRAY_SIZE(ad7768_dec_rate_values) - 2);
> + dig_filter_regval = AD7768_DIG_FIL_FIL(AD7768_FILTER_REGVAL_WIDEBAND) |
> + AD7768_DIG_FIL_DEC_RATE(dec_rate_idx);
> + /* Correct the index offset */
> + dec_rate_idx += 2;
> + break;
> + case AD7768_FILTER_SINC5:
> + dec_rate_idx = find_closest(dec_rate, ad7768_dec_rate_values,
> + ARRAY_SIZE(ad7768_dec_rate_values));
> +
> + /*
> + * Decimations 8 (idx 0) and 16 (idx 1) are set in the
> + * FILTER[6:4] field. The other decimations are set in the
> + * DEC_RATE[2:0] field, and the idx need to be offsetted by two.
> + */
> + if (dec_rate_idx == 0)
> + dig_filter_regval = AD7768_DIG_FIL_FIL(AD7768_FILTER_REGVAL_SINC5_X8);
> + else if (dec_rate_idx == 1)
> + dig_filter_regval = AD7768_DIG_FIL_FIL(AD7768_FILTER_REGVAL_SINC5_X16);
> + else
> + dig_filter_regval = AD7768_DIG_FIL_FIL(AD7768_FILTER_REGVAL_SINC5) |
> + AD7768_DIG_FIL_DEC_RATE(dec_rate_idx - 2);
> + break;
> + }
> +
> + ret = regmap_write(st->regmap, AD7768_REG_DIGITAL_FILTER, dig_filter_regval);
> + if (ret)
> return ret;
>
> - /* A sync-in pulse is required every time the filter dec rate changes */
> + st->filter_type = filter_type;
> + /*
> + * The decimation for SINC3 filters are configured in different
> + * registers
> + */
> + if (filter_type == AD7768_FILTER_SINC3 ||
> + filter_type == AD7768_FILTER_SINC3_REJ60) {
> + ret = ad7768_set_sinc3_dec_rate(st, dec_rate);
> + if (ret)
> + return ret;
> + } else {
> + st->oversampling_ratio = ad7768_dec_rate_values[dec_rate_idx];
Looks like an extra space after =
> + }
> +
> + ad7768_fill_samp_freq_tbl(st);
This is opens a potentially complex race condition if we have the an
in kernel consumer reading the data in this array as it is being updated
(currently we can't stop that happening though solutions to that problem
have been much discussed).
There aren't that many oversampling ratios so perhaps it is better
to precalculate all the potential available values as an array indexed
by oversampling ratio. That way all the data is const, it's just possible
to get stale pointer to the wrong entry which can always happen anyway
if the read vs update happen in different entities.
> +
> + /* A sync-in pulse is required after every configuration change */
> return ad7768_send_sync_pulse(st);
> }
>
> +static int ad7768_write_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int val, int val2, long info)
> +{
> + int ret;
> +
> + ret = iio_device_claim_direct_mode(indio_dev);
update to use if (!iio_device_claim_direct())
> + if (ret)
> + return ret;
> +
> + ret = __ad7768_write_raw(indio_dev, chan, val, val2, info);
> + iio_device_release_direct_mode(indio_dev);
> +
> + return ret;
> +}
next prev parent reply other threads:[~2025-03-08 13:56 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-06 21:00 [PATCH v4 00/17] iio: adc: ad7768-1: Add features, improvements, and fixes Jonathan Santos
2025-03-06 21:00 ` [PATCH v4 01/17] iio: adc: ad7768-1: Fix conversion result sign Jonathan Santos
2025-03-08 13:13 ` Jonathan Cameron
2025-03-06 21:00 ` [PATCH v4 02/17] iio: adc: ad7768-1: set MOSI idle state to prevent accidental reset Jonathan Santos
2025-03-07 12:06 ` Marcelo Schmitt
2025-03-08 13:15 ` Jonathan Cameron
2025-03-31 13:16 ` Jonathan Santos
2025-03-06 21:00 ` [PATCH v4 03/17] dt-bindings: iio: adc: ad7768-1: add trigger-sources property Jonathan Santos
2025-03-08 13:17 ` Jonathan Cameron
2025-04-01 16:15 ` David Lechner
2025-03-06 21:01 ` [PATCH v4 04/17] dt-bindings: iio: adc: ad7768-1: Document GPIO controller Jonathan Santos
2025-03-07 13:46 ` Bartosz Golaszewski
2025-03-14 10:22 ` Linus Walleij
2025-03-06 21:01 ` [PATCH v4 05/17] dt-bindings: iio: adc: ad7768-1: document regulator provider property Jonathan Santos
2025-04-01 16:20 ` David Lechner
2025-03-06 21:01 ` [PATCH v4 06/17] Documentation: ABI: add wideband filter type to sysfs-bus-iio Jonathan Santos
2025-03-07 12:45 ` Marcelo Schmitt
2025-03-08 13:20 ` Jonathan Cameron
2025-03-06 21:01 ` [PATCH v4 07/17] iio: adc: ad7768-1: remove unnecessary locking Jonathan Santos
2025-03-08 13:24 ` Jonathan Cameron
2025-03-06 21:02 ` [PATCH v4 08/17] iio: adc: ad7768-1: convert driver to use regmap Jonathan Santos
2025-03-07 13:20 ` Marcelo Schmitt
2025-03-08 13:27 ` Jonathan Cameron
2025-04-01 16:31 ` David Lechner
2025-04-01 16:38 ` David Lechner
2025-03-06 21:02 ` [PATCH v4 09/17] iio: adc: ad7768-1: Add reset gpio Jonathan Santos
2025-03-07 13:42 ` Marcelo Schmitt
2025-03-08 13:30 ` Jonathan Cameron
2025-03-06 21:02 ` [PATCH v4 10/17] iio: adc: ad7768-1: Move buffer allocation to a separate function Jonathan Santos
2025-03-07 13:52 ` Marcelo Schmitt
2025-03-08 13:33 ` Jonathan Cameron
2025-03-06 21:02 ` [PATCH v4 11/17] iio: adc: ad7768-1: add regulator to control VCM output Jonathan Santos
2025-03-07 14:32 ` Marcelo Schmitt
2025-03-08 13:08 ` Jonathan Cameron
2025-03-08 13:38 ` Jonathan Cameron
2025-03-06 21:03 ` [PATCH v4 12/17] iio: adc: ad7768-1: Add GPIO controller support Jonathan Santos
2025-03-07 13:45 ` Bartosz Golaszewski
2025-03-08 13:41 ` Jonathan Cameron
2025-04-04 21:12 ` Marcelo Schmitt
2025-03-06 21:03 ` [PATCH v4 13/17] iio: adc: ad7768-1: add multiple scan types to support 16-bits mode Jonathan Santos
2025-03-06 21:03 ` [PATCH v4 14/17] iio: adc: ad7768-1: add support for Synchronization over SPI Jonathan Santos
2025-04-01 17:02 ` David Lechner
2025-03-06 21:04 ` [PATCH v4 15/17] iio: adc: ad7768-1: replace manual attribute declaration Jonathan Santos
2025-03-07 14:49 ` Marcelo Schmitt
2025-04-01 17:05 ` David Lechner
2025-03-06 21:04 ` [PATCH v4 16/17] iio: adc: ad7768-1: add filter type and oversampling ratio attributes Jonathan Santos
2025-03-08 13:56 ` Jonathan Cameron [this message]
2025-04-01 0:18 ` Jonathan Santos
2025-04-06 10:49 ` Jonathan Cameron
2025-03-06 21:04 ` [PATCH v4 17/17] iio: adc: ad7768-1: add low pass -3dB cutoff attribute Jonathan Santos
2025-03-07 15:12 ` Marcelo Schmitt
2025-04-01 17:12 ` 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=20250308135620.3c95b951@jic23-huawei \
--to=jic23@kernel.org \
--cc=Jonathan.Santos@analog.com \
--cc=Michael.Hennerich@analog.com \
--cc=brgl@bgdev.pl \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--cc=jonath4nns@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=lars@metafoo.de \
--cc=lgirdwood@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@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=paul.pop@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).