All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vasileios Amoiridis <vassilisamir@gmail.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: Vasileios Amoiridis <vassilisamir@gmail.com>,
	lars@metafoo.de, andy.shevchenko@gmail.com,
	u.kleine-koenig@pengutronix.de, linux-iio@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC v1 2/2] iio: light: rpr0521: Drop unnecessary checks for timestamp value
Date: Sun, 29 Sep 2024 12:33:44 +0200	[thread overview]
Message-ID: <20240929103344.GA92011@vamoiridPC> (raw)
In-Reply-To: <20240928161527.73fe0ac1@jic23-huawei>

On Sat, Sep 28, 2024 at 04:15:27PM +0100, Jonathan Cameron wrote:
> On Sun, 22 Sep 2024 18:20:41 +0200
> Vasileios Amoiridis <vassilisamir@gmail.com> wrote:
> 
> > The rpr0521_trigger_consumer_handler() is registered as the trigger
> > threaded handler in the devm_iio_triggered_buffer_setup() function.
> > This function is being called in 2 ways:
> > 
> > a) when there is a registered trigger being trigger like sysfs or hrt.
> > The call of the trigger handler (which is the iio_pollfunc_store_time())
> > follows which saves the timestamp and then, wakes up the trigger
> > threaded handler.
> > 
> > b) The irq handler is using the iio_trigger_poll_nested() which wakes
> > up the trigger threaded handler.
> > 
> > In both cases, the pf->timestamp has already been assigned a value
> > so there is no need to check if it is 0, neither to 0 it after
> > the push to the buffer.
> 
> Not quite right (I think).  The caller of iio_trigger_poll_nested() might not
> be this driver.  There are other potential triggers that are nested
> because of need to check some status register, but can still be used
> for other devices.   In theory you could drive light capture of
> the as3935 for when you want to know how bright it was just after
> a lightening strike :)
> 
> We don't have a general solution for timestamps when that
> happens, so this driver is papering over that with this code.
> 
> 
> Jonathan
> 

Hi Jonathan,

Thank you very much for the reply! I see your point, I also think I 
am wrong after all. I was just interested to see why this driver makes
it so different from the other ones when it is coming to trigger/irq
handling. Thank you very much for the explanation!

Cheers,
Vasilis

> 
> 
> > 
> > Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com>
> > ---
> >  drivers/iio/light/rpr0521.c | 8 +-------
> >  1 file changed, 1 insertion(+), 7 deletions(-)
> > 
> > diff --git a/drivers/iio/light/rpr0521.c b/drivers/iio/light/rpr0521.c
> > index 56f5fbbf79ac..ae6a22b91b8d 100644
> > --- a/drivers/iio/light/rpr0521.c
> > +++ b/drivers/iio/light/rpr0521.c
> > @@ -446,13 +446,8 @@ static irqreturn_t rpr0521_trigger_consumer_handler(int irq, void *p)
> >  	int err;
> >  
> >  	/* Use irq timestamp when reasonable. */
> > -	if (iio_trigger_using_own(indio_dev) && data->irq_timestamp) {
> > +	if (iio_trigger_using_own(indio_dev))
> >  		pf->timestamp = data->irq_timestamp;
> > -		data->irq_timestamp = 0;
> > -	}
> > -	/* Other chained trigger polls get timestamp only here. */
> > -	if (!pf->timestamp)
> > -		pf->timestamp = iio_get_time_ns(indio_dev);
> >  
> >  	err = regmap_bulk_read(data->regmap, RPR0521_REG_PXS_DATA,
> >  		data->scan.channels,
> > @@ -463,7 +458,6 @@ static irqreturn_t rpr0521_trigger_consumer_handler(int irq, void *p)
> >  	else
> >  		dev_err(&data->client->dev,
> >  			"Trigger consumer can't read from sensor.\n");
> > -	pf->timestamp = 0;
> >  
> >  	iio_trigger_notify_done(indio_dev->trig);
> >  
> 

      reply	other threads:[~2024-09-29 10:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-22 16:20 [PATCH RFC v1 0/2] iio: Simplify IRQ and trigger management in RPR0521 Vasileios Amoiridis
2024-09-22 16:20 ` [PATCH RFC v1 1/2] iio: light: rpr0521: Use generic iio_pollfunc_store_time() Vasileios Amoiridis
2024-09-28 15:10   ` Jonathan Cameron
2024-10-12 16:12     ` Jonathan Cameron
2024-09-22 16:20 ` [PATCH RFC v1 2/2] iio: light: rpr0521: Drop unnecessary checks for timestamp value Vasileios Amoiridis
2024-09-28 15:15   ` Jonathan Cameron
2024-09-29 10:33     ` Vasileios Amoiridis [this message]

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=20240929103344.GA92011@vamoiridPC \
    --to=vassilisamir@gmail.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=jic23@kernel.org \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=u.kleine-koenig@pengutronix.de \
    /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.