Ticket #4606 (new enhancement)
XO can't resume from suspend at a particular time set by software
|Reported by:||gnu||Owned by:||rsmith|
|Keywords:||power||Cc:||cjb, JordanCrouse, jg, dsaxena, sascha_silbe|
|Deployments affected:||Blocked By:||#6053|
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.