Clock offsets during suspend/resume

Andy Green andy at
Fri Dec 12 16:17:55 CET 2008

Hash: SHA1

Somebody in the thread at some point said:
| On Fri, 2008-12-12 at 15:02 +0000, Andy Green wrote:
|> | If we can't fix the system clock, could we restore it from the hw clock
|> | during resume?
|> Userspace should also be able to do it with
|> hwclock --hctosys
|> afterwards.
|> I guess what is going on is the rtc driver is restoring the clock, but
|> there is no "time" passing until resume completes.  If it is true, then
|> hwclock can be a reasonable solution.
| According to the kernel log timestamps, some time is passing during
| resume, just very little... Could this be some side effect of the full
| cpu utilization? In any case, if we can't keep time correctly during
| resume, the restore from hw clock should happen at the end of resuming.

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?

| Of course it would be possible to work around it in userspace but that
| still feels wrong. ;)

Balaji, how do you feel about a delayed work in rtc driver that takes
care of this?  If it isn't all down to Glamo then it can be a generic
issue for this driver.

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the openmoko-kernel mailing list