Clock offsets during suspend/resume

[Balaji Rao]

On Fri, Dec 12, 2008 at 03:48:22PM +0000, Andy Green wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Somebody in the thread at some point said:
>
> |> I would guess the effect could be mainly caused by sitting there
> |> scrolling the Glamo framebuffer, if you try it without console=tty0 on
> |> cmdline does it impact it?
> |
> | Using 'echo 0 0 0 0 > /proc/sys/kernel/printk' it suspends and resumes a
> | lot faster and doesn't pick up any delay. Even after several cycles, the
> | sum is still below 1 second.
>
> Hm well the default state with Qi going on is going to be no noncritical
> syslog on the LCM.
>

But whatever it is, the time should ideally not get affected - we are
not a virtual machine!

> | The weird thing is that even now, it still has an offset of 51 seconds
> | between system and hw clock. So it does not seem to restore from the hw
> | clock accessible via 'hwclock'... or does it remember the offset during
> | suspend?
>
> Seems that the rtc class stuff does indeed take care of that
> (drivers/rtc/class.c) ...
>
> 	/* restore wall clock using delta against this RTC;
> 	 * adjust again for avg 1/2 second RTC sampling error
> 	 */
> 	set_normalized_timespec(&time,
> 				newtime + delta.tv_sec,
> 				(NSEC_PER_SEC >> 1) + delta.tv_nsec);
>
> ... I guess it is for maintaining timezone offset from a UTC hw rtc.

Yes, it saves the delta during suspend and restores it on resume..

	- Balaji