mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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,
> +};
> +

  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®