From: Jonathan Cameron <jic23@kernel.org>
To: inv.git-commit@tdk.com
Cc: lars@metafoo.de, linux-iio@vger.kernel.org,
stable@vger.kernel.org,
Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
Subject: Re: [PATCH] iio: invensense: fix timestamp glitches when switching frequency
Date: Wed, 1 May 2024 08:37:33 +0100 [thread overview]
Message-ID: <20240501083733.207c27a5@jic23-huawei> (raw)
In-Reply-To: <20240428141349.116ad03c@jic23-huawei>
On Sun, 28 Apr 2024 14:13:49 +0100
Jonathan Cameron <jic23@kernel.org> wrote:
> On Fri, 26 Apr 2024 09:48:35 +0000
> inv.git-commit@tdk.com wrote:
>
> > From: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
> >
> > When a sensor is running and there is a FIFO frequency change due to
> > another sensor turned on/off, there are glitches on timestamp. Fix that
> > by using only interrupt timestamp when there is the corresponding sensor
> > data in the FIFO.
> >
> > Delete FIFO period handling and simplify internal functions.
> >
> > Update integration inside inv_mpu6050 and inv_icm42600 drivers.
> >
> > Fixes: 0ecc363ccea7 ("iio: make invensense timestamp module generic)
> > CC: stable@vger.kernel.org
> > Signed-off-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
>
> Whilst I don't fully follow the logic here, the new code is simpler
> and seems reasonable. Getting my head around this will probably take
> longer than it's worth :(
>
> Hence applied to the fixes-togreg branch of iio.git.
This made a bit of a mess wrt to some new part additions that went in
via the togreg tree.
Given timing I'm going to pull the fixes on top of that tree so this
will need a manual backport. Please take a look at iio.git togreg
to check I didn't mess anything up.
Jonathan
>
> Jonathan
>
> > ---
> > .../inv_sensors/inv_sensors_timestamp.c | 24 +++++++++----------
> > .../imu/inv_icm42600/inv_icm42600_buffer.c | 20 +++++++---------
> > drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c | 2 +-
> > .../linux/iio/common/inv_sensors_timestamp.h | 3 +--
> > 4 files changed, 21 insertions(+), 28 deletions(-)
> >
> > diff --git a/drivers/iio/common/inv_sensors/inv_sensors_timestamp.c b/drivers/iio/common/inv_sensors/inv_sensors_timestamp.c
> > index 3b0f9598a7c7..5f3ba77da740 100644
> > --- a/drivers/iio/common/inv_sensors/inv_sensors_timestamp.c
> > +++ b/drivers/iio/common/inv_sensors/inv_sensors_timestamp.c
> > @@ -70,13 +70,13 @@ int inv_sensors_timestamp_update_odr(struct inv_sensors_timestamp *ts,
> > }
> > EXPORT_SYMBOL_NS_GPL(inv_sensors_timestamp_update_odr, IIO_INV_SENSORS_TIMESTAMP);
> >
> > -static bool inv_validate_period(struct inv_sensors_timestamp *ts, uint32_t period, uint32_t mult)
> > +static bool inv_validate_period(struct inv_sensors_timestamp *ts, uint32_t period)
> > {
> > uint32_t period_min, period_max;
> >
> > /* check that period is acceptable */
> > - period_min = ts->min_period * mult;
> > - period_max = ts->max_period * mult;
> > + period_min = ts->min_period * ts->mult;
> > + period_max = ts->max_period * ts->mult;
> > if (period > period_min && period < period_max)
> > return true;
> > else
> > @@ -84,15 +84,15 @@ static bool inv_validate_period(struct inv_sensors_timestamp *ts, uint32_t perio
> > }
> >
> > static bool inv_update_chip_period(struct inv_sensors_timestamp *ts,
> > - uint32_t mult, uint32_t period)
> > + uint32_t period)
> > {
> > uint32_t new_chip_period;
> >
> > - if (!inv_validate_period(ts, period, mult))
> > + if (!inv_validate_period(ts, period))
> > return false;
> >
> > /* update chip internal period estimation */
> > - new_chip_period = period / mult;
> > + new_chip_period = period / ts->mult;
> > inv_update_acc(&ts->chip_period, new_chip_period);
> > ts->period = ts->mult * ts->chip_period.val;
> >
> > @@ -120,16 +120,14 @@ static void inv_align_timestamp_it(struct inv_sensors_timestamp *ts)
> > }
> >
> > void inv_sensors_timestamp_interrupt(struct inv_sensors_timestamp *ts,
> > - uint32_t fifo_period, size_t fifo_nb,
> > - size_t sensor_nb, int64_t timestamp)
> > + size_t sample_nb, int64_t timestamp)
> > {
> > struct inv_sensors_timestamp_interval *it;
> > int64_t delta, interval;
> > - const uint32_t fifo_mult = fifo_period / ts->chip.clock_period;
> > uint32_t period;
> > bool valid = false;
> >
> > - if (fifo_nb == 0)
> > + if (sample_nb == 0)
> > return;
> >
> > /* update interrupt timestamp and compute chip and sensor periods */
> > @@ -139,14 +137,14 @@ void inv_sensors_timestamp_interrupt(struct inv_sensors_timestamp *ts,
> > delta = it->up - it->lo;
> > if (it->lo != 0) {
> > /* compute period: delta time divided by number of samples */
> > - period = div_s64(delta, fifo_nb);
> > - valid = inv_update_chip_period(ts, fifo_mult, period);
> > + period = div_s64(delta, sample_nb);
> > + valid = inv_update_chip_period(ts, period);
> > }
> >
> > /* no previous data, compute theoritical value from interrupt */
> > if (ts->timestamp == 0) {
> > /* elapsed time: sensor period * sensor samples number */
> > - interval = (int64_t)ts->period * (int64_t)sensor_nb;
> > + interval = (int64_t)ts->period * (int64_t)sample_nb;
> > ts->timestamp = it->up - interval;
> > return;
> > }
> > diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_buffer.c b/drivers/iio/imu/inv_icm42600/inv_icm42600_buffer.c
> > index b52f328fd26c..9cde9a9337ad 100644
> > --- a/drivers/iio/imu/inv_icm42600/inv_icm42600_buffer.c
> > +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_buffer.c
> > @@ -509,20 +509,20 @@ int inv_icm42600_buffer_fifo_parse(struct inv_icm42600_state *st)
> > return 0;
> >
> > /* handle gyroscope timestamp and FIFO data parsing */
> > - ts = iio_priv(st->indio_gyro);
> > - inv_sensors_timestamp_interrupt(ts, st->fifo.period, st->fifo.nb.total,
> > - st->fifo.nb.gyro, st->timestamp.gyro);
> > if (st->fifo.nb.gyro > 0) {
> > + ts = iio_priv(st->indio_gyro);
> > + inv_sensors_timestamp_interrupt(ts, st->fifo.nb.gyro,
> > + st->timestamp.gyro);
> > ret = inv_icm42600_gyro_parse_fifo(st->indio_gyro);
> > if (ret)
> > return ret;
> > }
> >
> > /* handle accelerometer timestamp and FIFO data parsing */
> > - ts = iio_priv(st->indio_accel);
> > - inv_sensors_timestamp_interrupt(ts, st->fifo.period, st->fifo.nb.total,
> > - st->fifo.nb.accel, st->timestamp.accel);
> > if (st->fifo.nb.accel > 0) {
> > + ts = iio_priv(st->indio_accel);
> > + inv_sensors_timestamp_interrupt(ts, st->fifo.nb.accel,
> > + st->timestamp.accel);
> > ret = inv_icm42600_accel_parse_fifo(st->indio_accel);
> > if (ret)
> > return ret;
> > @@ -550,9 +550,7 @@ int inv_icm42600_buffer_hwfifo_flush(struct inv_icm42600_state *st,
> >
> > if (st->fifo.nb.gyro > 0) {
> > ts = iio_priv(st->indio_gyro);
> > - inv_sensors_timestamp_interrupt(ts, st->fifo.period,
> > - st->fifo.nb.total, st->fifo.nb.gyro,
> > - gyro_ts);
> > + inv_sensors_timestamp_interrupt(ts, st->fifo.nb.gyro, gyro_ts);
> > ret = inv_icm42600_gyro_parse_fifo(st->indio_gyro);
> > if (ret)
> > return ret;
> > @@ -560,9 +558,7 @@ int inv_icm42600_buffer_hwfifo_flush(struct inv_icm42600_state *st,
> >
> > if (st->fifo.nb.accel > 0) {
> > ts = iio_priv(st->indio_accel);
> > - inv_sensors_timestamp_interrupt(ts, st->fifo.period,
> > - st->fifo.nb.total, st->fifo.nb.accel,
> > - accel_ts);
> > + inv_sensors_timestamp_interrupt(ts, st->fifo.nb.accel, accel_ts);
> > ret = inv_icm42600_accel_parse_fifo(st->indio_accel);
> > if (ret)
> > return ret;
> > diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c
> > index 86465226f7e1..0dc0f22a5582 100644
> > --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c
> > +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c
> > @@ -100,7 +100,7 @@ irqreturn_t inv_mpu6050_read_fifo(int irq, void *p)
> > goto end_session;
> > /* Each FIFO data contains all sensors, so same number for FIFO and sensor data */
> > fifo_period = NSEC_PER_SEC / INV_MPU6050_DIVIDER_TO_FIFO_RATE(st->chip_config.divider);
> > - inv_sensors_timestamp_interrupt(&st->timestamp, fifo_period, nb, nb, pf->timestamp);
> > + inv_sensors_timestamp_interrupt(&st->timestamp, nb, pf->timestamp);
> > inv_sensors_timestamp_apply_odr(&st->timestamp, fifo_period, nb, 0);
> >
> > /* clear internal data buffer for avoiding kernel data leak */
> > diff --git a/include/linux/iio/common/inv_sensors_timestamp.h b/include/linux/iio/common/inv_sensors_timestamp.h
> > index a47d304d1ba7..8d506f1e9df2 100644
> > --- a/include/linux/iio/common/inv_sensors_timestamp.h
> > +++ b/include/linux/iio/common/inv_sensors_timestamp.h
> > @@ -71,8 +71,7 @@ int inv_sensors_timestamp_update_odr(struct inv_sensors_timestamp *ts,
> > uint32_t period, bool fifo);
> >
> > void inv_sensors_timestamp_interrupt(struct inv_sensors_timestamp *ts,
> > - uint32_t fifo_period, size_t fifo_nb,
> > - size_t sensor_nb, int64_t timestamp);
> > + size_t sample_nb, int64_t timestamp);
> >
> > static inline int64_t inv_sensors_timestamp_pop(struct inv_sensors_timestamp *ts)
> > {
> > --
> > 2.34.1
> >
>
>
next prev parent reply other threads:[~2024-05-01 7:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-26 9:48 [PATCH] iio: invensense: fix timestamp glitches when switching frequency inv.git-commit
2024-04-28 13:13 ` Jonathan Cameron
2024-05-01 7:37 ` Jonathan Cameron [this message]
2024-05-02 9:15 ` Jean-Baptiste Maneyrol
2024-05-03 7:04 ` Jean-Baptiste Maneyrol
2024-05-03 8:29 ` Jonathan Cameron
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=20240501083733.207c27a5@jic23-huawei \
--to=jic23@kernel.org \
--cc=inv.git-commit@tdk.com \
--cc=jean-baptiste.maneyrol@tdk.com \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--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