Suspend: RTC wakeup, sleep

[John Gilmore]

> > By design, autosuspends should not change the timing behavior of programs;
> > the idea is for the computer to act the same, but do so using less power.
> 
> Autosuspend and lid-close suspends are identical in function.  The only 
> difference is the allowed wakeup source.  The CPU is turned off.  All 
> timing save the RTC (and EC [1]) is stopped.  

These two suspends are only identical in function in the EC.  They 
need not be identical in the kernel.

> 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.

As "man 8 hwclock" says, "The control program can read or set this clock to a
whole second, but the control program can also detect the edges of the
1 second clock ticks, so the clock actually has virtually infinite
precision."  See also the discussion in the initial comments in
hwclock.c:

  http://www.sfr-fresh.com/linux/misc/hwclock-2.32.tgz:a/hwclock-2.32/hwclock.c

> and the timing precision of the EC is not suitable for 
> accuracy over longer periods or temperature changes. (its RC based)

If it's within 10% or 20%, the EC's resistor-capacitor based timing is
accurate enough for the kernel's purposes in doing short suspends of
the CPU invisibly.  It's unlikely that the kernel will decide to
suspend for more than an hour, say; probably some daemon or kernel
code will be scheduled to wake up before then.  (The invisible suspend
code can set an upper limit and force a wakeup every 10 minutes, for
example, if it thinks that's prudent.)  The kernel can initially err
on the side of waking early.  After each resume, it can accurately
measure the inaccuracy of the RC-based timer on that suspend.  Then it
can improve its estimates to let it the next suspend wake later and
thus waste less power.  Of course it will always need to keep waking
early enough that a temperature change that alters the timer's
inaccuracy won't make it miss a deadline, but for the expected short
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.

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, and then watch for an RTC clock tick.
When the RTC ticks, subtract the subsecond count from the CPU clock,
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 http://dev.laptop.org/ticket/6053#comment:7
and subsequent comments.

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

> 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.

When the CPU restarts after a suspend, the kernel can decide how to
treat sleeping processes.  In a suspend that's intended to be
invisible, the kernel already knows it asked to be powered down for a
shorter time than any pending userspace sleep() call or kernel timer
queue entry.  The kernel can figure out how long the suspend actually
was, to high precision, and can then awaken the user process or kernel
task at the proper time.

A lot of this is explored in http://dev.laptop.org/ticket/6053 (Clock
drift during suspend/resume), http://dev.laptop.org/ticket/4606 (XO
can't resume from suspend at a particular time set by software), and
http://dev.laptop.org/ticket/3359#comment:3 .  These are 3-year-old
bugs, so it's unsurprising if you've forgotten their contents, but
since I did a lot of the analysis of how we COULD do invisible
suspends, I remembered where to look for the details.

	John

PS:  Invisible suspends will work much better if you fix #9054 as well,
pulling 700ms out of the resume path and making it effective to suspend
the system even if it needs to reawaken a few seconds later.