Clock offsets during suspend/resume
andy at openmoko.com
Fri Dec 12 16:17:55 CET 2008
-----BEGIN PGP SIGNED MESSAGE-----
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
|> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the openmoko-kernel