Re: IIO timestamp get skewed when suspending (st_lsm6dsx)

Re: IIO timestamp get skewed when suspending (st_lsm6dsx)

[Sean Nyekjaer]

Hi Thomas,

I have a question regarding CLOCK_REALTIME and CLOCK_BOOTTIME when 
resuming from suspend.

We have run into problems with 
drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c + the first patch from 
Lorenzo Bianconi in this thread.
The accelerometer have an internal FIFO that includes a timestamp. When 
we resume from suspend,
the driver resets the fifo ts counter and sets an internal reference to 
that time.
But to me it looks like both CLOCK_REALTIME and CLOCK_BOOTIME aren't 
ready when st_lsm6dsx_resume() is called.

If this is a limitation, can you point to other drivers that have been 
able to workaround it?
Or can we wait for a flag or similar?

Best regards,
Sean Nyekjaer

Re: IIO timestamp get skewed when suspending (st_lsm6dsx)

[Thomas Gleixner]

Sean,

Sean Nyekjaer <sean@geanix.com> writes:
> I have a question regarding CLOCK_REALTIME and CLOCK_BOOTTIME when 
> resuming from suspend.
>
> We have run into problems with
> drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c + the first patch from
> Lorenzo Bianconi in this thread.  The accelerometer have an internal
> FIFO that includes a timestamp. When we resume from suspend, the
> driver resets the fifo ts counter and sets an internal reference to
> that time.
>
> But to me it looks like both CLOCK_REALTIME and CLOCK_BOOTIME aren't 
> ready when st_lsm6dsx_resume() is called.

That depends on your system. Timekeeping is resumed way before drivers
are resumed, but the suspend time injection might happen late when there
is no early device to read from. In this case it happens when the RTC is
resumed.

If the IIO driver resumes before the RTC which injects the suspend time,
then the core time is still in the past. And RTC is using the default
resume mechanism, so depending on device/class registration order this
might be the case. Deferring to the PM & RTC wizards.

Thanks,

        tglx