I'm observing a behavior when using rtcwake that appears to be the
result of a timing hazard in the design between the RTC Class framework
and the interfaces for entering system sleep states.
My understanding of the RTC Driver's expected behavior is that it should
generate an alarm at a programmed time and if the system is in a sleep
state at that time it should wake.
Rtcwake appears to program an RTC alarm using RTC IOCTLs and then
initiate the transition to a system sleep state. The timing hazard I am
observing is that the RTC driver may service an alarm expiration before
the RTC driver is informed that it is transitioning to a system sleep
state. In this case the system may enter the sleep state with no alarm set.
This happens when the alarm time is short and the suspend time is long.
For example, the command 'rtcwake -m off -s 1' may exhibit the problem.
The obvious work-around is to set the alarm further in the future to
allow more time for the system to enter the desired system sleep state.
However, I would welcome any advice on how this problem could/should be
solved in the general case.
For example, if there were a way to communicate to the driver that a
system sleep state transition is imminent, it could hold off servicing
the alarm until after it is directed to transition to the sleep state.
Of course, if the system sleep state transition gets aborted for some
other reason the driver may never get notified to enter the sleep state
and the alarm may never get serviced.
Any thoughts are appreciated,
Doug
