Suspend: RTC wakeup, sleep

Richard A. Smith richard at
Mon Aug 2 17:13:36 EDT 2010

On 07/29/2010 08:56 PM, John Gilmore wrote:

>> With the RTC you have a 1 second ambiguity
> There is no 1-second ambiguity in the RTC.  The CPU can only read out
> a value accurate to 1 second, but the CPU can tell precisely when the
> RTC "ticks" from one second to another, which gives it much higher
> precision if it's willing to wait.  Its precision is greater than its
> accuracy.

But now each resume can have up to 1 second of delay while you wait for 
the tick to occur.

> sleeps of under a minute, there isn't much time for the temperature
> to change while suspended, even if the laptop moves from sun to shade
> or vice verse during that minute.

That would indeed be possible.  The actual sync from the EC to the 
kernel would be tricky since the communication path from the EC to the 
kernel is variable.  You would have to use some sort of NTP type scheme.

> The kernel in XO-1 has at least two ways to accurately measure the
> duration of an EC timer based suspend.  One is to use the CPU clock to
> count subseconds since power-up,

You will also have to compensate for the time lost until your hardware 
and software are up enough to count sub-seconds.  It may be possible its 
going to take some effort.

> and you'll know exactly when the CPU resumed.  A second way is to
> leave an MFGPT timer running during suspend.
> There are one or two
> timers that can't wake the system, but which can count while suspended,
> and at high accuracy.  See
> and subsequent comments.

That seems more workable...

> I haven't examined the XO-1.5 timer situation.

There are similar timers in XO-1.5 GPT 3 looks like it can count while 
in suspend.

>> So with the system as it stands there is really no (good) way to
>> accomplish a zero timing impact suspend.
> There are clever ways to do it despite the limitations of the
> hardware.

Yes.  It seems possible but right now none of this is done and there is 
not currently any plan to make it happen.

OLPC is in the market for a dedicated (and local) kernel hacker to work 
on things like this but right now we don't have one.  Until we get one 
or until someone in the community works on it this will just be ideas.

We have also veered off thread...The original questions/responses were 
on what happens _now_, not what we should be doing.  I'd like to 
understand the existing issues first.

Richard A. Smith  <richard at>
One Laptop per Child

More information about the Devel mailing list