mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Liu Yufei <lyf98405@gmail.com>
Cc: "Alex Lanzano" <lanzano.alex@gmail.com>,
	"David Lechner" <dlechner@baylibre.com>,
	"Nuno Sá" <nuno.sa@analog.com>,
	"Andy Shevchenko" <andy@kernel.org>,
	"Gustavo Silva" <gustavograzs@gmail.com>,
	linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH] iio: imu: bmi270: fix zero timestamp in triggered buffer
Date: Sun, 1 Nov 2026 18:23:27 +0000	[thread overview]
Message-ID: <20261101182327.4fd27ceb@jic23-hlaptop> (raw)
In-Reply-To: <20261028-bmi270-fix-timestamp-v1-1-99c0e5fe7d0c@gmail.com>

On Wed, 28 Oct 2026 10:59:26 +0800
Liu Yufei <lyf98405@gmail.com> wrote:

> When the device's own data ready trigger is used, the trigger is
> polled with iio_trigger_poll_nested() from the threaded IRQ handler.
> In that path the pollfunc top half, iio_pollfunc_store_time(), is
> never run, so pf->timestamp is left at zero and every sample pushed
> to the buffer carries a zero timestamp.
> 
> Take the timestamp in the trigger handler itself and drop the top
> half, so that a valid timestamp is provided for all triggers.
> 
> Fixes: a1854d55f54b ("iio: imu: bmi270: add support for data ready interrupt trigger")
> Cc: stable@vger.kernel.org
> Signed-off-by: Liu Yufei <lyf98405@gmail.com>

Firstly. Do you have a setup where you actually care about this, or is this
found by reading code / LLM etc? If nothing else that changes
the urgency.

This is an old problem. I really need to find some time to write
a more consistent solution for timestamp acquistion that would
indicate if we have a better timestamp or not and stop this
being a driver problem.  We used to avoid this by having most
triggers go through the irq_work dance but that was considered
too much of an overhead.

As Andy suggested we do want to grab the timestamp if appropriate
in the top half if it is our own trigger (the one registered
by the driver) because we then know it is the best possible
for a dataready trigger.

The way some drivers handle this is to check on whether the
trigger set is our own or not. Now ideally we'd do that check
in some helper code, but writing that is less than trivial
(which is why I've not done it already)

https://elixir.bootlin.com/linux/v7.3/source/drivers/iio/light/rpr0521.c
is an example I found with a quick grep, but perhaps not
coded in the cleanest way!  So take the idea, not necessarily
the implementation from there. 

Jonathan


> ---
>  drivers/iio/imu/bmi270/bmi270_core.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/iio/imu/bmi270/bmi270_core.c b/drivers/iio/imu/bmi270/bmi270_core.c
> index fbcf6bb87acc..40ed1ee5ac58 100644
> --- a/drivers/iio/imu/bmi270/bmi270_core.c
> +++ b/drivers/iio/imu/bmi270/bmi270_core.c
> @@ -840,6 +840,7 @@ static irqreturn_t bmi270_trigger_handler(int irq, void *p)
>  	struct iio_poll_func *pf = p;
>  	struct iio_dev *indio_dev = pf->indio_dev;
>  	struct bmi270_data *data = iio_priv(indio_dev);
> +	s64 timestamp = iio_get_time_ns(indio_dev);
>  	int ret;
>  
>  	guard(mutex)(&data->mutex);
> @@ -852,7 +853,7 @@ static irqreturn_t bmi270_trigger_handler(int irq, void *p)
>  		goto done;
>  
>  	iio_push_to_buffers_with_timestamp(indio_dev, &data->buffer,
> -					   pf->timestamp);
> +					   timestamp);
>  done:
>  	iio_trigger_notify_done(indio_dev->trig);
>  	return IRQ_HANDLED;
> @@ -1630,8 +1631,7 @@ int bmi270_core_probe(struct device *dev, struct regmap *regmap,
>  	if (ret)
>  		return ret;
>  
> -	ret = devm_iio_triggered_buffer_setup(dev, indio_dev,
> -					      iio_pollfunc_store_time,
> +	ret = devm_iio_triggered_buffer_setup(dev, indio_dev, NULL,
>  					      bmi270_trigger_handler, NULL);
>  	if (ret)
>  		return ret;
> 
> ---
> base-commit: 09f742b49cb2728086d78be2b0b35e4d1d71fc85
> change-id: 20261028-bmi270-fix-timestamp-48a194b69db1
> 
> Best regards,
> --  
> Liu Yufei <lyf98405@gmail.com>
> 


      parent reply	other threads:[~2026-11-01 18:23 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-28  2:59 Liu Yufei
2026-10-28  8:58 ` Andy Shevchenko
2026-10-28 14:24   ` Liu Yufei
2026-10-29 13:19     ` Andy Shevchenko
2026-11-01 18:10       ` Jonathan Cameron
2026-11-01 18:23 ` Jonathan Cameron [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=20261101182327.4fd27ceb@jic23-hlaptop \
    --to=jic23@kernel.org \
    --cc=andy@kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=gustavograzs@gmail.com \
    --cc=lanzano.alex@gmail.com \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lyf98405@gmail.com \
    --cc=nuno.sa@analog.com \
    --cc=stable@vger.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

all inboxes | Powered by JetHome®