public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH] OMAP: timekeeping: time should not stop during suspend
@ 2009-09-24 23:35 Kevin Hilman
  2009-09-28  8:02 ` Jean Pihet
  2009-10-22  0:19 ` Kevin Hilman
  0 siblings, 2 replies; 4+ messages in thread
From: Kevin Hilman @ 2009-09-24 23:35 UTC (permalink / raw)
  To: linux-omap

During suspend, the kernel timekeeping subsystem is shut down.  Before
suspend and upon resume, it uses a weak function
read_persistent_clock() to determine the amount of time that elapsed
during suspend.

This function was not implemented on OMAP, so from the timekeeping
subsystem perspective (and thus userspace as well) it appeared that no
time elapsed during suspend.

This patch uses the 32k sync timer as a the persistent clock the 32k
sync timer value converted to seconds.

NOTE: This does *NOT* handle wrapping of the 32k sync timer, so
      wrapping of the 32k sync timer during suspend may cause
      problems.  Also, there are not interrupts when the 32k sync
      timer wraps, so something else has to be done.

Reported-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
---
Tested on OMAP3 using PM branch.
If no issues, I will queue for 2.6.32-rc fixes

 arch/arm/plat-omap/common.c |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index b3f70e6..3e4325b 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -178,6 +178,21 @@ unsigned long long sched_clock(void)
 	return ret;
 }
 
+/**
+ * read_persistent_clock -  Return time in seconds from the persistent clock.
+ */
+unsigned long read_persistent_clock(void)
+{
+	unsigned long long ret;
+	cycle_t cycles;
+
+	cycles = clocksource_32k.read(&clocksource_32k);
+	ret = (cycles * clocksource_32k.mult_orig) >> clocksource_32k.shift;
+	do_div(ret, NSEC_PER_SEC);
+
+	return (unsigned long)ret;
+}
+
 static int __init omap_init_clocksource_32k(void)
 {
 	static char err[] __initdata = KERN_ERR
-- 
1.6.4.3


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] OMAP: timekeeping: time should not stop during suspend
  2009-09-24 23:35 [PATCH] OMAP: timekeeping: time should not stop during suspend Kevin Hilman
@ 2009-09-28  8:02 ` Jean Pihet
  2009-10-20 16:33   ` Kevin Hilman
  2009-10-22  0:19 ` Kevin Hilman
  1 sibling, 1 reply; 4+ messages in thread
From: Jean Pihet @ 2009-09-28  8:02 UTC (permalink / raw)
  To: Kevin Hilman; +Cc: linux-omap

Kevin,

On Friday 25 September 2009 01:35:48 Kevin Hilman wrote:
> During suspend, the kernel timekeeping subsystem is shut down.  Before
> suspend and upon resume, it uses a weak function
> read_persistent_clock() to determine the amount of time that elapsed
> during suspend.
>
> This function was not implemented on OMAP, so from the timekeeping
> subsystem perspective (and thus userspace as well) it appeared that no
> time elapsed during suspend.
>
> This patch uses the 32k sync timer as a the persistent clock the 32k
> sync timer value converted to seconds.
>
> NOTE: This does *NOT* handle wrapping of the 32k sync timer, so
>       wrapping of the 32k sync timer during suspend may cause
>       problems.  Also, there are not interrupts when the 32k sync
>       timer wraps, so something else has to be done.
I think we should read the 32k timer value before entering the sleep and 
reading it again at resume time. Doing so up to one overflow could be 
handled, which means a maximum sleep period of 36.4 hours.

Now the time wrap problem imposes the system to wake-up before 36.4 hours. We 
have a few options:
1) always use the wake-up timer with a wake-up time < 36.4 hours
2) rely on the user space to set the wake-up timer correctly, depending on the 
applications needs.

I am for option 1.

Any thoughts?

Regards,
Jean

>
> Reported-by: Jon Hunter <jon-hunter@ti.com>
> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
> ---
> Tested on OMAP3 using PM branch.
> If no issues, I will queue for 2.6.32-rc fixes
>
>  arch/arm/plat-omap/common.c |   15 +++++++++++++++
>  1 files changed, 15 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
> index b3f70e6..3e4325b 100644
> --- a/arch/arm/plat-omap/common.c
> +++ b/arch/arm/plat-omap/common.c
> @@ -178,6 +178,21 @@ unsigned long long sched_clock(void)
>  	return ret;
>  }
>
> +/**
> + * read_persistent_clock -  Return time in seconds from the persistent
> clock. + */
> +unsigned long read_persistent_clock(void)
> +{
> +	unsigned long long ret;
> +	cycle_t cycles;
> +
> +	cycles = clocksource_32k.read(&clocksource_32k);
> +	ret = (cycles * clocksource_32k.mult_orig) >> clocksource_32k.shift;
> +	do_div(ret, NSEC_PER_SEC);
> +
> +	return (unsigned long)ret;
> +}
> +
>  static int __init omap_init_clocksource_32k(void)
>  {
>  	static char err[] __initdata = KERN_ERR



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] OMAP: timekeeping: time should not stop during suspend
  2009-09-28  8:02 ` Jean Pihet
@ 2009-10-20 16:33   ` Kevin Hilman
  0 siblings, 0 replies; 4+ messages in thread
From: Kevin Hilman @ 2009-10-20 16:33 UTC (permalink / raw)
  To: Jean Pihet; +Cc: linux-omap

Jean Pihet <jpihet@mvista.com> writes:

> Kevin,
>
> On Friday 25 September 2009 01:35:48 Kevin Hilman wrote:
>> During suspend, the kernel timekeeping subsystem is shut down.  Before
>> suspend and upon resume, it uses a weak function
>> read_persistent_clock() to determine the amount of time that elapsed
>> during suspend.
>>
>> This function was not implemented on OMAP, so from the timekeeping
>> subsystem perspective (and thus userspace as well) it appeared that no
>> time elapsed during suspend.
>>
>> This patch uses the 32k sync timer as a the persistent clock the 32k
>> sync timer value converted to seconds.
>>
>> NOTE: This does *NOT* handle wrapping of the 32k sync timer, so
>>       wrapping of the 32k sync timer during suspend may cause
>>       problems.  Also, there are not interrupts when the 32k sync
>>       timer wraps, so something else has to be done.
> I think we should read the 32k timer value before entering the sleep and 
> reading it again at resume time. Doing so up to one overflow could be 
> handled, which means a maximum sleep period of 36.4 hours.
>
> Now the time wrap problem imposes the system to wake-up before 36.4 hours. We 
> have a few options:
> 1) always use the wake-up timer with a wake-up time < 36.4 hours
> 2) rely on the user space to set the wake-up timer correctly, depending on the 
> applications needs.
>
> I am for option 1.
>
> Any thoughts?

I agree with option 1.

Kevin

>>
>> Reported-by: Jon Hunter <jon-hunter@ti.com>
>> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
>> ---
>> Tested on OMAP3 using PM branch.
>> If no issues, I will queue for 2.6.32-rc fixes
>>
>>  arch/arm/plat-omap/common.c |   15 +++++++++++++++
>>  1 files changed, 15 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
>> index b3f70e6..3e4325b 100644
>> --- a/arch/arm/plat-omap/common.c
>> +++ b/arch/arm/plat-omap/common.c
>> @@ -178,6 +178,21 @@ unsigned long long sched_clock(void)
>>  	return ret;
>>  }
>>
>> +/**
>> + * read_persistent_clock -  Return time in seconds from the persistent
>> clock. + */
>> +unsigned long read_persistent_clock(void)
>> +{
>> +	unsigned long long ret;
>> +	cycle_t cycles;
>> +
>> +	cycles = clocksource_32k.read(&clocksource_32k);
>> +	ret = (cycles * clocksource_32k.mult_orig) >> clocksource_32k.shift;
>> +	do_div(ret, NSEC_PER_SEC);
>> +
>> +	return (unsigned long)ret;
>> +}
>> +
>>  static int __init omap_init_clocksource_32k(void)
>>  {
>>  	static char err[] __initdata = KERN_ERR

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] OMAP: timekeeping: time should not stop during suspend
  2009-09-24 23:35 [PATCH] OMAP: timekeeping: time should not stop during suspend Kevin Hilman
  2009-09-28  8:02 ` Jean Pihet
@ 2009-10-22  0:19 ` Kevin Hilman
  1 sibling, 0 replies; 4+ messages in thread
From: Kevin Hilman @ 2009-10-22  0:19 UTC (permalink / raw)
  To: linux-omap

Kevin Hilman <khilman@deeprootsystems.com> writes:

> During suspend, the kernel timekeeping subsystem is shut down.  Before
> suspend and upon resume, it uses a weak function
> read_persistent_clock() to determine the amount of time that elapsed
> during suspend.
>
> This function was not implemented on OMAP, so from the timekeeping
> subsystem perspective (and thus userspace as well) it appeared that no
> time elapsed during suspend.
>
> This patch uses the 32k sync timer as a the persistent clock the 32k
> sync timer value converted to seconds.
>
> NOTE: This does *NOT* handle wrapping of the 32k sync timer, so
>       wrapping of the 32k sync timer during suspend may cause
>       problems.  Also, there are not interrupts when the 32k sync
>       timer wraps, so something else has to be done.
>
> Reported-by: Jon Hunter <jon-hunter@ti.com>
> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
> ---
> Tested on OMAP3 using PM branch.
> If no issues, I will queue for 2.6.32-rc fixes

oops, forgot about this one.  Will queue in PM branch fixes.

Kevin

>  arch/arm/plat-omap/common.c |   15 +++++++++++++++
>  1 files changed, 15 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
> index b3f70e6..3e4325b 100644
> --- a/arch/arm/plat-omap/common.c
> +++ b/arch/arm/plat-omap/common.c
> @@ -178,6 +178,21 @@ unsigned long long sched_clock(void)
>  	return ret;
>  }
>  
> +/**
> + * read_persistent_clock -  Return time in seconds from the persistent clock.
> + */
> +unsigned long read_persistent_clock(void)
> +{
> +	unsigned long long ret;
> +	cycle_t cycles;
> +
> +	cycles = clocksource_32k.read(&clocksource_32k);
> +	ret = (cycles * clocksource_32k.mult_orig) >> clocksource_32k.shift;
> +	do_div(ret, NSEC_PER_SEC);
> +
> +	return (unsigned long)ret;
> +}
> +
>  static int __init omap_init_clocksource_32k(void)
>  {
>  	static char err[] __initdata = KERN_ERR
> -- 
> 1.6.4.3

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2009-10-22  0:19 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-09-24 23:35 [PATCH] OMAP: timekeeping: time should not stop during suspend Kevin Hilman
2009-09-28  8:02 ` Jean Pihet
2009-10-20 16:33   ` Kevin Hilman
2009-10-22  0:19 ` Kevin Hilman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox