getnstimeofday() and suspend

getnstimeofday() and suspend

[Tero.Kristo]

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?

-Tero

Re: getnstimeofday() and suspend

[Tony Lindgren]

* Tero.Kristo@nokia.com <Tero.Kristo@nokia.com> [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

RE: getnstimeofday() and suspend

[Tero.Kristo]

>-----Original Message-----
>From: ext Tony Lindgren [mailto:tony@atomide.com] 
>Sent: 13 August, 2008 17:00
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: getnstimeofday() and suspend
>
>* Tero.Kristo@nokia.com <Tero.Kristo@nokia.com> [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

RE: getnstimeofday() and suspend

[Tero.Kristo]

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

Hi Tony,

This behavior of the getnstimeofday() is breaking pm-debug and the
serial console wakeup hack if we use suspend. Enabling RTC module seems
to fix some of the issues in some cases, but we are going to lose timer
accuracy (RTC accuracy is only 1 second.) Also, these functionalities
should not be dependant on RTC imo. Should I revert these patches to use
directly HW timer and ignore getnstimeofday() or what do you think? 

-Tero

RE: getnstimeofday() and suspend

[Igor Stoppa]

On Fri, 2008-08-15 at 12:32 +0300, ext Tero.Kristo@nokia.com wrote:

> This behavior of the getnstimeofday() is breaking pm-debug and the
> serial console wakeup hack if we use suspend. Enabling RTC module seems
> to fix some of the issues in some cases, but we are going to lose timer
> accuracy (RTC accuracy is only 1 second.)

What about using the RTC for getting the base time and the 32kHz for the
extended granularity?

So one would use the RTC as ususal and then calculate the (less than 1s)
offset.

-- 

Cheers, Igor

---

Igor Stoppa
Maemo Software - Nokia Devices R&D - Helsinki

Re: getnstimeofday() and suspend

[Högander Jouni]

"ext Igor Stoppa" <igor.stoppa@nokia.com> writes:

> On Fri, 2008-08-15 at 12:32 +0300, ext Tero.Kristo@nokia.com wrote:
>
>> This behavior of the getnstimeofday() is breaking pm-debug and the
>> serial console wakeup hack if we use suspend. Enabling RTC module seems
>> to fix some of the issues in some cases, but we are going to lose timer
>> accuracy (RTC accuracy is only 1 second.)
>
> What about using the RTC for getting the base time and the 32kHz for the
> extended granularity?
>
> So one would use the RTC as ususal and then calculate the (less than 1s)
> offset.

Are you talking about rtc resume generally here? If you are talking
about pm debug and serial console hack here, using 32kHz timer only,
would work as a solution even when there is no rtc driver loaded.

Using them both would also generate more complexity. What would be the
benefit in using them both?

-- 
Jouni Högander

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: getnstimeofday() and suspend

[Igor Stoppa]

On Fri, 2008-08-15 at 12:55 +0300, Högander Jouni wrote:

> Using them both would also generate more complexity. What would be the
> benefit in using them both?

The RTC should be used during suspend since it's supposed to keep track
of time regardless of how long the duration of the suspension is.

The 32kHz alone is not a good generic solution since it overflows after
a couple of days.

-- 

Cheers, Igor

---

Igor Stoppa
Maemo Software - Nokia Devices R&D - Helsinki
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: getnstimeofday() and suspend

[Tero.Kristo]

[-- Attachment #1: Type: text/plain, Size: 965 bytes --]

 

>-----Original Message-----
>From: Stoppa Igor (Nokia-D/Helsinki) 
>Sent: 15 August, 2008 13:11
>To: Hogander Jouni (Nokia-D/Tampere)
>Cc: Kristo Tero (Nokia-D/Tampere); tony@atomide.com; 
>linux-omap@vger.kernel.org
>Subject: Re: getnstimeofday() and suspend
>
>On Fri, 2008-08-15 at 12:55 +0300, Högander Jouni wrote:
>
>> Using them both would also generate more complexity. What 
>would be the 
>> benefit in using them both?
>
>The RTC should be used during suspend since it's supposed to 
>keep track of time regardless of how long the duration of the 
>suspension is.
>
>The 32kHz alone is not a good generic solution since it 
>overflows after a couple of days.

General problem seems to be that arch/arm has not defined read_persistent_clock() function. Attached patch tries to fix this problem by using a 32k counter hack. Probably something similar should be done which checks for overflows and uses RTC if available.

-Tero

[-- Attachment #2: 0001-Fixed-timekeeping-bug-during-suspend.patch --]
[-- Type: application/octet-stream, Size: 822 bytes --]

From 7afd5fad9b07b774a89da7352cb520a0e47a95b2 Mon Sep 17 00:00:00 2001
From: Tero Kristo <tero.kristo@nokia.com>
Date: Fri, 15 Aug 2008 15:25:51 +0300
Subject: [PATCH 1/1] Fixed timekeeping bug during suspend

Signed-off-by: Tero Kristo <tero.kristo@nokia.com>
---
 arch/arm/plat-omap/common.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 3a5f05e..a62fc97 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -210,6 +210,11 @@ static cycle_t omap_32k_read(void)
 	return omap_readl(TIMER_32K_SYNCHRONIZED);
 }
 
+unsigned long read_persistent_clock(void)
+{
+  return omap_32k_read() >> 15; 
+}
+
 static struct clocksource clocksource_32k = {
 	.name		= "32k_counter",
 	.rating		= 250,
-- 
1.5.4.3

Re: getnstimeofday() and suspend

[Högander Jouni]

Igor Stoppa <igor.stoppa@nokia.com> writes:

> On Fri, 2008-08-15 at 12:55 +0300, Högander Jouni wrote:
>
>> Using them both would also generate more complexity. What would be the
>> benefit in using them both?
>
> The RTC should be used during suspend since it's supposed to keep track
> of time regardless of how long the duration of the suspension is.
>
> The 32kHz alone is not a good generic solution since it overflows after
> a couple of days.

Yes you are right on that timer overflow. How generic this is, I'm not
sure. This is only for measuring time pwrdms spent in their states on
suspend. How about removing that time from pm debug interfaces? They
are meant for debugging dynamic sleep anyway.

-- 
Jouni Högander

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: getnstimeofday() and suspend

[Woodruff, Richard]

> owner@vger.kernel.org] On Behalf Of Igor Stoppa
> On Fri, 2008-08-15 at 12:55 +0300, Högander Jouni wrote:
>
> > Using them both would also generate more complexity. What would be the
> > benefit in using them both?
>
> The RTC should be used during suspend since it's supposed to keep track
> of time regardless of how long the duration of the suspension is.
>
> The 32kHz alone is not a good generic solution since it overflows after
> a couple of days.

Couple notes over time.

In some older suspend code, an overflow interrupt was programmed which woke and re-slept.  The code path never left the local suspend function.  This allowed ok time to be kept over a longer time.

Using the RTC if it is I2C can only happen a little later in the wake up flow.  Seems some pieces used to get confused if the notion of time was not updated a bit earlier.

If you do rapid suspend/resume when you don't have a good cpuidle some of these things become issues.

Main comment is overflow for suspend can work with out rtc.

Regards,
Richard W.

Re: getnstimeofday() and suspend

[David Brownell]

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

This is why you should configure an RTC to handle RTC_HCTOSYS duties.
Like updating the system time from the RTC after resume ...

- Dave