#4606 NORM Never A: XO can't resume from suspend at a particular time set by software

[Zarro Boogs per Child]

#4606: XO can't resume from suspend at a particular time set by software
----------------------+-----------------------------------------------------
 Reporter:  gnu       |       Owner:  wad           
     Type:  defect    |      Status:  new           
 Priority:  normal    |   Milestone:  Never Assigned
Component:  hardware  |     Version:                
 Keywords:  power     |    Verified:  0             
----------------------+-----------------------------------------------------
 The XO hardware doesn't have a wakeup source with more than 1-second
 granularity or resolution.  If the CPU wishes to suspend for 0.568
 seconds, it can't.  Much worse is that it can't suspend for 3 seconds
 either; the only way it can resume is on exact 1-second boundaries in the
 realtime clock (not 1 second boundaries from "now").  It can't even read
 out sub-second times from the RTC to figure out when the RTC will tick
 over to the next second.

 There are tricks that we could play in the 5536 if we can reuse one or two
 pins to use a MFGPT to trigger a wakeup.   Probably the easiest
 circumvention is to ask the EC to wake us up after so many milliseconds;
 its meter is running all the time, even when we're in suspend.  Seems like
 a simple request, but as Jordan says, "nobody in x86 land has ever needed
 to do anything more drastic than" waking up on 1-second boundaries before.
 They probably thought their "alarm clock" was pretty cool for being able
 to wake up on any specified second, rather than just at an HH:MM time.

 This limits what we can do for automatic suspend, since we would have to
 wake up the CPU most of a second before it's needed -- perhaps more than a
 second early, if kernel code that uses better timers isn't keeping track
 of how much the RTC has drifted against the system clock.

 There's a possibly related bug #3359 (we lose up to a second in Unix's
 idea of what the time is, whenever we suspend).  The bug has a very
 misleading title about network time servers, but the real bug is that the
 clock shouldn't lose time when we suspend.

-- 
Ticket URL: <http://dev.laptop.org/ticket/4606>
One Laptop Per Child <http://dev.laptop.org>
OLPC bug tracking system