Clock offsets during suspend/resume

Andy Green andy at openmoko.com
Fri Dec 12 16:48:22 CET 2008


-----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.

| 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.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAklCh8YACgkQOjLpvpq7dMpgWACfWCAbw29TDjkbf+n6kPT4pmKU
Y0kAn3aSqWXx3xIhc5XBupJeZWgiEzfF
=4ef/
-----END PGP SIGNATURE-----



More information about the openmoko-kernel mailing list