> > > On 03/06/2020 10.06, Lorenzo Bianconi wrote: > > > > > > > > > On 02/06/2020 15.39, Sean Nyekjaer wrote: > > > > > > are these values from the hw FIFO? can you please add > > > > > > sensor->ts_ref to the trace and > > > > > > a log into st_lsm6dsx_reset_hw_ts? > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > This certainly looks weird, > > > > > > > > > > https://gist.github.com/sknsean/b32bae140008cf446a8fea58e305da47 > > > > > > > > > > Seems like the ts_ref is updated and used but not read/used in > > > > > userspace... > > > > > > > > > > /Sean > > > > > > > > added to st_lsm6dsx_read_fifo : > > > > > > > > printk("ts_ref %lld, ts %lld, sample_time %lld\n", acc_sensor->ts_ref, > > > > ts, acc_sensor->ts_ref + ts); > > > > > > > > https://gist.github.com/sknsean/3ad1e9e05cb0e2ef811a3c83492a1980 > > > > > > > > Suspend again was 15sec > > > > > > > > /Sean > > > > > > Hi, > > > > > > Some more findings :) > > > https://gist.github.com/sknsean/d31e48b65515361309cd238dcf68600f > > > > > > To me it looks like ktime_get_real_ns() isn't ready or updated when we are > > > calling iio_get_time_ns(). > > > If we look in the trace ktime_get_real_ns() it's ready when we are getting > > > the first sample after suspend. > > > > > > Running with this patch: > > > https://gist.github.com/sknsean/415d1b9c34f20db4419a0c61a58eb188 > > > + > > > The first from this thread. > > > > > > /Sean > > > > Hi Sean, > > > > looking at the logs I guess we should not reset the sensor hw ts. Could you > > please try the below patch? > > > > Regards, > > Lorenzo > > > > diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c > > index 0b776cb91928..4f8a9bcee77b 100644 > > --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c > > +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c > > @@ -2445,6 +2445,8 @@ static int __maybe_unused st_lsm6dsx_resume(struct device *dev) > > if (!(hw->suspend_mask & BIT(sensor->id))) > > continue; > > + sensor->ts_ref = iio_get_time_ns(hw->iio_devs[i]); > > + > > if (sensor->id == ST_LSM6DSX_ID_EXT0 || > > sensor->id == ST_LSM6DSX_ID_EXT1 || > > sensor->id == ST_LSM6DSX_ID_EXT2) > > > > Hmm, suspend again for 15s. > > https://gist.github.com/sknsean/911ae4ae2e74ebe1e7eca1405c645ff1 > > [ 105.520634] PM: suspend exit > [ 105.540206] ts_ref 1591097307780181385, ts 2861700000, sample_time > 1591097310641881385 > > [ 105.548416] ktime_get_real_ns: 1591097322928175385 > > CLOCK_REALTIME isn't ready in the resume function. I think we need to link > it to CLOCK_BOOTTIME (Which ticking under suspend) instead. With latest patch it seems to me the time reported is now monotonic so it seems correct. What is the clocktype you set? you can check it in: /sys/bus/iio/devices/iio:device<x>/current_timestamp_clock Regards, Lorenzo > > /Sean
Attachment:
signature.asc
Description: PGP signature
