Hi,
I have been debugging why our device will often abort a suspend.
I tracked it down to the following sequence :
1. Alarm type 3 (ELAPSED_REALTIME) is scheduled
2. The alarm is triggered
3. Shortly after, the system is going down for a suspend
4. The wakelock driver aborts the suspend with -EAGAIN
Looking at alarm-dev.c, I see that upon an alarm triggering, in
alarm_triggered() it holds the main alarm wake lock for 5 seconds (this
is in 2.6.36 kernel).
This seems incorrect to me.
Why does it need to hold the alarm wake lock for 5 seconds after
triggering a non-wakeup alarm? The alarm was not a RTC_WAKEUP of
ELAPSED_REALTIME_WAKEUP alarm, so it should not prevent the suspend
either directly or indirectly via the alarm-dev driver.
Would it not be better to have alarm-dev check the alarm type before
holding the wakelock? if it is a wakeup alarm, it could hold the wake
lock to allow the operation to complete, but if it is not, it should
allow it to schedule and complete either before or after the suspend,
whenever the system gets round to it?
Advice appreciated.
Bob
--
unsubscribe: android-kernel+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-kernel
