Internal timers in deep sleep

Internal timers in deep sleep

[Marcus Folkesson]

Hello there,

I am currently working with an embedded system based on a OMAP-L138.
We are developing a Software Defined Radio (SDR) which is sending and
recieveing data in a slot-based scheme.
Power management is a really important subject in our application,
therefore we want to put the CPU into deepsleep (suspend to RAM) as
much as we can.
In short, this deepsleep-mode stops all the PLLs and put the SDRAM
into self-refresh.

Since all the the PLLs is stopped in deepsleep-mode, we loose all time
perception. This is a problem since our rx/tx scheme is slot-based and
if we don't know the time then we don't know when we should
listen/transmit.
To solve this, we have implemented a timer in a FPGA that still ticks
when the CPU is sleeping. This timer also work as an alarm-clock, e.g.
we can set a time when it should wake us up from deepsleep.
When going into deepsleep, the driver that communicates with the FPGA
set a wake-up alarm and then it calls pm_suspend(PM_SUSPEND_MEM).

Our application is also time-critical so we want to go to/from
deepsleep as fast as possible.
For some quick measurements, we have seen that it takes about 70ms to
go up from deepsleep.


Now to the questions!
1a.
When we are going into deepsleep, all internal timers used by the
kernel itself and other applications will be frozen and delayed. Do
you think this disorder will cause any problem?
Of cause, this can be seen as a stupid question, it all depends on our
application, but if you have any personal experience about this, so
please feel free to mention how the reasoning went.

1b.
Should I  take care of the internal timers (make the FPGA to wake up
on those too)? Do you know any good functions that exposes a list with
all timers?
I guess there must be a function that gives you the timer that expires
next but I have not found it.
Is the timer_list and htimers handled the same way? I guess the
htimers is not jiffie-based?

1c.
Should I adjust some internal variables (e.g. jiffies) when waking up?

2.
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.
Of cause, those functions is not there for fun, but is some more
important than others...?

Thanks in advance

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

Internal timers in deep sleep

[Tony Lindgren]

Hi Marcus,

* Marcus Folkesson <marcus.folkesson@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

Internal timers in deep sleep

[Marcus Folkesson]

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@atomide.com>:
> Hi Marcus,
>
> * Marcus Folkesson <marcus.folkesson@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