From: Jonathan Cameron <jic23@kernel.org>
To: Jorge Marques <jorge.marques@analog.com>
Cc: "Lars-Peter Clausen" <lars@metafoo.de>,
"Michael Hennerich" <Michael.Hennerich@analog.com>,
"David Lechner" <dlechner@baylibre.com>,
"Nuno Sá" <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>,
"Jonathan Corbet" <corbet@lwn.net>,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH 7/7] iio: adc: ad4062: Add IIO Events support
Date: Sat, 18 Oct 2025 17:26:25 +0100 [thread overview]
Message-ID: <20251018172625.42f13f4a@jic23-huawei> (raw)
In-Reply-To: <20251013-staging-ad4062-v1-7-0f8ce7fef50c@analog.com>
On Mon, 13 Oct 2025 09:28:05 +0200
Jorge Marques <jorge.marques@analog.com> wrote:
> Adds support for IIO Events. Optionally, gp0 is assigned as Threshold
> Either signal, if not present, fallback to an I3C IBI with the same
> role.
>
> Signed-off-by: Jorge Marques <jorge.marques@analog.com>
The one bit of this that I'm not sure on is the apparent dropping out
of monitor mode on most userspace interactions that cause register accesses.
That seems like a fairly unintuitive ABI. It might be better to block the access
until the events are turned off. Perhaps I missed something?
Thanks,
Jonathan
> ---
> drivers/iio/adc/ad4062.c | 351 ++++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 347 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/iio/adc/ad4062.c b/drivers/iio/adc/ad4062.c
> index 40b7c10b8ce7145b010bb11e8e4698baacb6b3d3..b5b12f81c71b52f244600ed23dad11253290b868 100644
> --- a/drivers/iio/adc/ad4062.c
> +++ b/drivers/iio/adc/ad4062.c
> @@ -13,6 +13,7 @@
> +/**
> + * A register access will cause the device to drop from monitor mode
> + * into configuration mode, update the state to reflect that.
> + */
> +static void ad4062_exit_monitor_mode(struct ad4062_state *st)
> +{
> + if (st->wait_event) {
> + pm_runtime_mark_last_busy(&st->i3cdev->dev);
> + pm_runtime_put_autosuspend(&st->i3cdev->dev);
As elsewhere, no longer need to have the mark_last_busy() call here.
> + st->wait_event = 0;
> + }
> +}
> +static ssize_t sampling_frequency_available_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct ad4062_state *st = iio_priv(dev_to_iio_dev(dev));
> + int ret = 0;
> +
> + for (u8 i = AD4062_FS_OFFSET(st->chip->grade);
> + i < AD4062_FS_LEN(st->chip->grade); i++)
> + ret += sysfs_emit_at(buf, ret, "%s ", ad4062_conversion_freqs[i]);
> +
> + ret += sysfs_emit_at(buf, ret, "\n");
> + return ret;
Has slightly ugly format of " \n" at end rather than "\n"
There are various ways to handle this perhaps easiest is something like
for (u8 i = AD4062_FS_OFFSET(st->chip->grade);
i < AD4062_FS_LEN(st->chip->grade); i++)
ret += sysfs_emit_at(buf, ret, "%s%c", ad4062_conversion_freqs[i],
i != (AD4062_FS_LEN(st->chip_grade) - 1) ? "\n", " ");
> +}
> static irqreturn_t ad4062_poll_handler(int irq, void *p)
> @@ -523,6 +645,24 @@ static int ad4062_request_irq(struct iio_dev *indio_dev)
> struct device *dev = &st->i3cdev->dev;
> int ret;
>
> + ret = fwnode_irq_get_byname(dev_fwnode(&st->i3cdev->dev), "gp0");
> + if (ret >= 0) {
> + ret = devm_request_threaded_irq(dev, ret, NULL,
> + ad4062_irq_handler_thresh,
> + IRQF_ONESHOT, indio_dev->name,
> + indio_dev);
> + if (ret)
> + return ret;
> + } else if (ret != -EPROBE_DEFER) {
> + ret = regmap_update_bits(st->regmap, AD4062_REG_ADC_IBI_EN,
> + AD4062_REG_ADC_IBI_EN_MAX | AD4062_REG_ADC_IBI_EN_MIN,
> + AD4062_REG_ADC_IBI_EN_MAX | AD4062_REG_ADC_IBI_EN_MIN);
> + if (ret)
> + return ret;
> + } else {
> + return ret;
As before. I'd prefer error cases handled first. The earlier code suggestion
doesn't quite work but something along those lines should be doable.
> + }
> +
> ret = fwnode_irq_get_byname(dev_fwnode(&st->i3cdev->dev), "gp1");
> if (ret >= 0) {
> ret = devm_request_threaded_irq(dev, ret, NULL,
> @@ -779,6 +923,196 @@ static int ad4062_write_raw(struct iio_dev *indio_dev,
> return ret;
> }
>
> +static int ad4062_monitor_mode_enable(struct ad4062_state *st, bool enable)
> +{
> + int ret = 0;
> +
> + if (!enable)
> + goto out_suspend;
> +
> + ret = pm_runtime_resume_and_get(&st->i3cdev->dev);
> + if (ret)
> + return ret;
> +
> + ret = ad4062_conversion_frequency_set(st, st->events_frequency);
> + if (ret)
> + goto out_suspend;
> +
> + ret = ad4062_set_operation_mode(st, AD4062_MONITOR_MODE);
> + if (ret)
> + goto out_suspend;
> +
> + return ret;
return 0;
> +out_suspend:
> + pm_runtime_put_autosuspend(&st->i3cdev->dev);
> + return ret;
> +}
> static int ad4062_triggered_buffer_postenable(struct iio_dev *indio_dev)
> {
> struct ad4062_state *st = iio_priv(indio_dev);
> @@ -788,6 +1122,7 @@ static int ad4062_triggered_buffer_postenable(struct iio_dev *indio_dev)
> ret = pm_runtime_resume_and_get(&st->i3cdev->dev);
> if (ret)
> return ret;
> + ad4062_exit_monitor_mode(st);
Hmm. So you always exist monitor mode if we enable the buffer. I assume that doesn't
change detection of events because the buffered mode also allows that?
Do we not need something to turn monitor mode on again once we disable buffered capture?
>
> ret = ad4062_set_operation_mode(st, st->mode);
> if (ret)
> @@ -833,6 +1168,7 @@ static int ad4062_debugfs_reg_access(struct iio_dev *indio_dev, unsigned int reg
>
> if (!iio_device_claim_direct(indio_dev))
> return -EBUSY;
> + ad4062_exit_monitor_mode(st);
This probably needs a comment. Not obvious to me how you end up in with it enabled
again after the debugfs read / write finishes.
>
> if (readval)
> ret = regmap_read(st->regmap, reg, readval);
next prev parent reply other threads:[~2025-10-18 16:26 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-13 7:27 [PATCH 0/7] Add support for AD4062 device family Jorge Marques
2025-10-13 7:27 ` [PATCH 1/7] dt-bindings: iio: adc: Add adi,ad4062 Jorge Marques
2025-10-13 19:50 ` Conor Dooley
2025-10-26 16:35 ` Jorge Marques
2025-10-18 15:11 ` Jonathan Cameron
2025-10-26 16:37 ` Jorge Marques
2025-10-13 7:28 ` [PATCH 2/7] docs: iio: New docs for ad4062 driver Jorge Marques
2025-10-18 15:21 ` Jonathan Cameron
2025-10-28 15:31 ` Jorge Marques
2025-11-02 12:37 ` Jonathan Cameron
2025-11-03 10:19 ` Jorge Marques
2025-11-03 12:22 ` Jorge Marques
2025-11-09 12:16 ` Jonathan Cameron
2025-11-09 12:31 ` Jonathan Cameron
2025-10-13 7:28 ` [PATCH 3/7] iio: adc: Add support for ad4062 Jorge Marques
2025-10-18 16:10 ` Jonathan Cameron
2025-11-23 19:48 ` Jorge Marques
2025-11-24 7:43 ` Andy Shevchenko
2025-11-24 8:57 ` Jorge Marques
2025-11-24 9:10 ` Andy Shevchenko
2025-12-06 16:31 ` Jonathan Cameron
2025-11-24 9:11 ` Andy Shevchenko
2025-11-24 9:24 ` Jorge Marques
2025-10-13 7:28 ` [PATCH 4/7] docs: iio: ad4062: Add IIO Trigger support Jorge Marques
2025-10-13 7:28 ` [PATCH 5/7] iio: adc: " Jorge Marques
2025-10-18 16:14 ` Jonathan Cameron
2025-11-23 19:48 ` Jorge Marques
2025-10-13 7:28 ` [PATCH 6/7] docs: iio: ad4062: Add IIO Events support Jorge Marques
2025-10-13 7:28 ` [PATCH 7/7] iio: adc: " Jorge Marques
2025-10-18 16:26 ` Jonathan Cameron [this message]
2025-11-23 19:48 ` Jorge Marques
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=20251018172625.42f13f4a@jic23-huawei \
--to=jic23@kernel.org \
--cc=Michael.Hennerich@analog.com \
--cc=andy@kernel.org \
--cc=conor+dt@kernel.org \
--cc=corbet@lwn.net \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--cc=jorge.marques@analog.com \
--cc=krzk+dt@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-doc@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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 NNTP newsgroup(s).