linux-kernel - Re: Internal timers in deep sleep

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAM8FrKLH5pRmuedp90B4rqHPbdduCmKYPnkN4Nz9ofc8YXq6mw@mail.gmail.com>
Date:	Wed, 15 Feb 2012 11:09:16 +0100
From:	Marcus Folkesson <marcus.folkesson@...il.com>
To:	Tony Lindgren <tony@...mide.com>
Cc:	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: Internal timers in deep sleep

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@...mide.com>:
> Hi Marcus,
>
> * Marcus Folkesson <marcus.folkesson@...il.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/