Clock offsets during suspend/resume

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


-----BEGIN PGP SIGNED MESSAGE-----
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAklCgKIACgkQOjLpvpq7dMqh3gCfSi7YZvJZM751Dn688wNklrE3
gBsAniBzucwNg3iWrAHoAIBWI9m+beEc
=pdgh
-----END PGP SIGNATURE-----



More information about the openmoko-kernel mailing list