All of lore.kernel.org
 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: continuous mode support 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.