From: Jonathan Cameron <jic23@kernel.org>
To: "David Lechner (TI)" <dlechner@baylibre.com>
Cc: "Nuno Sá" <nuno.sa@analog.com>,
"Andy Shevchenko" <andy@kernel.org>, "Chris Hall" <c-hall@ti.com>,
"Patrick Edwards" <pedwards@ti.com>,
"Kurt Borja" <kuurtb@gmail.com>,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 3/3] iio: adc: ti-ads112c14: add continuous mode support
Date: Sun, 2 Aug 2026 19:17:53 +0100 [thread overview]
Message-ID: <20260802191753.2c98d7bb@jic23-huawei> (raw)
In-Reply-To: <20260731-iio-adc-ti-ads112c14-continuous-mode-v2-3-eb13da38e8fc@baylibre.com>
On Fri, 31 Jul 2026 18:48:12 -0500
"David Lechner (TI)" <dlechner@baylibre.com> wrote:
> Add support for continuous mode in the TI ADS112C14 ADC driver. In this
> mode the ADC itself is starting each conversion, so we add a trigger
> based on the DRDY interrupt to read each sample. This mode is also
> limited in that only one channel can be enabled at a time since the
> chip does not have a sequencer or simultaneous sampling capability.
> Continuous mode will only be used when this new trigger is the current
> trigger.
>
> Signed-off-by: David Lechner (TI) <dlechner@baylibre.com>
There is some follow on stuff in here from the earlier suggestion to
check the status register even when datardy involved
> ---
> drivers/iio/adc/ti-ads112c14.c | 146 ++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 144 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iio/adc/ti-ads112c14.c b/drivers/iio/adc/ti-ads112c14.c
> index c6d83298c312..5147d10785fb 100644
> --- a/drivers/iio/adc/ti-ads112c14.c
> +++ b/drivers/iio/adc/ti-ads112c14.c
> @@ -9,6 +9,7 @@
> */
>
> #include <linux/bitfield.h>
> +#include <linux/bitmap.h>
> #include <linux/cleanup.h>
> #include <linux/completion.h>
> #include <linux/crc8.h>
> @@ -18,6 +19,7 @@
> #include <linux/i2c.h>
> #include <linux/iio/buffer.h>
> #include <linux/iio/iio.h>
> +#include <linux/iio/trigger.h>
> #include <linux/iio/trigger_consumer.h>
> #include <linux/iio/triggered_buffer.h>
> #include <linux/interrupt.h>
> @@ -257,6 +259,7 @@ struct ads112c14_measurement {
> struct ads112c14_data {
> const struct ads112c14_chip_info *chip_info;
> struct regmap *regmap;
> + struct iio_trigger *drdy_trig;
> /* Synchronizes access to register value fields. */
> struct mutex lock;
> int drdy_irq;
> @@ -280,11 +283,32 @@ static irqreturn_t ads112c14_drdy_irq_handler(int irq, void *private)
> struct iio_dev *indio_dev = private;
> struct ads112c14_data *data = iio_priv(indio_dev);
>
> - complete(&data->drdy_completion);
> + if (indio_dev->trig && iio_trigger_using_own(indio_dev))
> + iio_trigger_poll(data->drdy_trig);
Even for this path we should be checking it wasn't a spurious interrupt.
If that's happening in a threaded interrupt we'll then call iio_trigger_poll_nested()
and the handler will happen in the interrupt thread. So the overhead
of that check should just be the check.
> + else
> + complete(&data->drdy_completion);
For this single shot read we are probably less bothered by overhead so
moving this to a thread should be fine I think.
>
> return IRQ_HANDLED;
> }
>
> +static int ads112c14_trigger_set_state(struct iio_trigger *trig, bool state)
> +{
> + struct iio_dev *indio_dev = iio_trigger_get_drvdata(trig);
> + struct ads112c14_data *data = iio_priv(indio_dev);
> +
> + if (state)
> + enable_irq(data->drdy_irq);
> + else
> + disable_irq(data->drdy_irq);
> +
So do we need to do this to avoid some condition, or is this the defensive
stuff you pointed out in that other thread?
I'd normally expect a dataready trigger to be controlling if the interrupt
is generated at all rather than masking host end.
> + return 0;
> +}
> +
> +static const struct iio_trigger_ops ads112c14_trigger_ops = {
> + .set_trigger_state = ads112c14_trigger_set_state,
> + .validate_device = iio_trigger_validate_own_device,
> +};
> +
next prev parent reply other threads:[~2026-08-02 18:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-31 23:48 [PATCH v2 0/3] iio: adc: ti-ads112c14: " David Lechner (TI)
2026-07-31 23:48 ` [PATCH v2 1/3] iio: adc: ti-ads112c14: add DRDY interrupt support David Lechner (TI)
2026-08-02 18:10 ` Jonathan Cameron
2026-07-31 23:48 ` [PATCH v2 2/3] iio: adc: ti-ads112c14: create data read helper functions David Lechner (TI)
2026-07-31 23:48 ` [PATCH v2 3/3] iio: adc: ti-ads112c14: add continuous mode support David Lechner (TI)
2026-08-02 18:17 ` Jonathan Cameron [this message]
2026-08-02 19:05 ` 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=20260802191753.2c98d7bb@jic23-huawei \
--to=jic23@kernel.org \
--cc=andy@kernel.org \
--cc=c-hall@ti.com \
--cc=dlechner@baylibre.com \
--cc=kuurtb@gmail.com \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nuno.sa@analog.com \
--cc=pedwards@ti.com \
/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
all inboxes | Powered by JetHome®