>-----Original Message----- >From: ext Tony Lindgren [mailto:tony@xxxxxxxxxxx] >Sent: 13 August, 2008 17:00 >To: Kristo Tero (Nokia-D/Tampere) >Cc: linux-omap@xxxxxxxxxxxxxxx >Subject: Re: getnstimeofday() and suspend > >* Tero.Kristo@xxxxxxxxx <Tero.Kristo@xxxxxxxxx> [080813 15:59]: >> Hi, >> >> I noticed an interesting feature in the getnstimeofday() >function when >> used with suspend. System clock is effectively reset to the value it >> was just before suspend. You can see this behavior e.g. with this >> command >> line: >> >> date && echo mem > /sys/power/state && date >> >> With approx. 2 minutes in suspend state the output for me was this: >> >> / # date && echo mem > sys/power/state && date Thu Jan 1 >00:13:40 UTC >> 1970PM: Syncing filesystems ... >> done. >> Freezing user space processes ... (elapsed 0.00 seconds) done. >> Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. >> Suspending console(s) >> Successfully put all powerdomains to target state Restarting >tasks ... >> done. >> Thu Jan 1 00:13:42 UTC 1970 >> >> I.e., the calendar clock was only advanced 2 seconds. The time you >> spend in suspend does not matter, the end result is the >same, it will >> reset the time to the value it was before suspend. >> >> Is this behavior intended? > >Hmm, well it should get the value straight from the 32KiHZ sync timer. >Does that get stopped somehow during suspend? > >Tony > Timer is not stopped, because immediately after suspend I get correct value from it (called from wakeup interrupt), but after this it is reprogrammed by something, or either time management code gets confused somehow. -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
