Internal timers in deep sleep

Marcus Folkesson marcus.folkesson at gmail.com
Wed Feb 15 05:09:16 EST 2012


Hi Tony,

Thanks for your answer.

The CPU goes down to Idle- or Wait For Interrupt-state but never to
any deeper state.
OMAP-L138 has only two possibilities to wake up from deep-sleep;
either from an RTC alarm or from an external wakeup-source.

The RTC has too low resolution (1s) for our application, so we need to
us the external interrupt as wakeup-source.

I have printed out the expire time for the next timer in queue (in
kernel/time/tick-sched.c:tick_nohz_stop_sched_tick()) and it is about
~10-200ms to next tick. (HZ=100). With this tight interval its not
possible to goto deepsleep with the latancies we have seen.


Med vänliga hälsningar / Best regards
Marcus Folkesson



2012/2/13 Tony Lindgren <tony at atomide.com>:
> Hi Marcus,
>
> * Marcus Folkesson <marcus.folkesson at gmail.com> [120211 03:37]:
>> Is it possible to speed up the time it takes to go to/from deepsleep?
>> The pm_suspend() does a lot of things, eg. freeze processes, suspend
>> drivers and so on.
>
> Depending on the omap, you can already do suspend while idle or off
> while idle. This means the RAM is in self-refresh and the omap is
> either suspended or powered off in the idle loop. This is typically
> done with a combination of constantly running 32 KiHz clocksource and
> wake-up capable GPT1 clockevent timer.
>
> If you have similar timers on your hardware, this may be the way to go.
> In this case there's no need to freeze processes, so the latency is
> quite minimal.
>
> Regards,
>
> Tony



More information about the linux-arm-kernel mailing list