Suspend: RTC wakeup, sleep

[John Gilmore]

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

No need to wait; you can ask the RTC to interrupt you on ticks.  That
will get you very close to knowing the accurate RTC time (based on
your interrupt latency).  Then set up the kernel to awaken 0.9999
seconds from the previous tick, and when you're there, read the RTC
registers continuously until it actually changes.  Then you're within
a microsecond or better of knowing when it ticked, without creating
much delay.  Your estimate of the time will be OK on resume, get
better after the first tick, and be completely accurate at the second
tick.  And you can arrange your estimate so that as you improve it,
time never moves backwards, only forwards, to avoid strange effects.

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

Right.  But ideas that will, in theory, double your battery life --
and finally put to use all the incredible effort that went into making
hardware that would reliably suspend and resume, tickless kernels,
user mode programs that don't awaken unnecessarily, etc.

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

I'm sorry I don't have insight into those to offer :-/

	John