resume issue
Ben Dooks
with the first suspend going into an infinite suspend loop
which we now think is due to the init process failing to
echo "on" to /sys/power/state to ensure the main wakelock
is being held.
Is this a bug in kernel, android or a mis-configuration of
the system?
--
Ben Dooks <bjd...@googlemail.com> http://www.fluff.org/ben/
Robert Beckett
interpreted it was that this is as expected.
If you are resumed because of an RTC alarm (e.g. something wants to
check for updates at a given time), then it will want to go back in to
suspend asap after checking its updates. If you are woken through a
power button press, then your input driver handling the power button
should pass the button press in to the kernel input system. This is how
I handle this. In my keyboard driver's resume handler, if it detects
that we woke up due to power button press, it reports a KEY_POWER press
and release. Android then notices this key press and the power manager
holds its wake lock as usual after a key press.
It would be interesting to hear if this is the intended behaviour.
Regards.
Bob
Ben Dooks
> Im not sure what was intended in this situation, but the way I
> interpreted it was that this is as expected.
>
> If you are resumed because of an RTC alarm (e.g. something wants to
> check for updates at a given time), then it will want to go back in to
> suspend asap after checking its updates. If you are woken through a
> power button press, then your input driver handling the power button
> should pass the button press in to the kernel input system. This is how
> I handle this. In my keyboard driver's resume handler, if it detects
> that we woke up due to power button press, it reports a KEY_POWER press
> and release. Android then notices this key press and the power manager
> holds its wake lock as usual after a key press.
>
> It would be interesting to hear if this is the intended behaviour.
It is most definetly a bug, you press a button to wake the device
up and it just sits going through a tight suspend/resume cycle
until you give up and reset it.
There's nothing wrong in the driver path. It is user-space failing
to either run soon enough, or not running the correct action to send
"on" to /sys/power/state.
I currently have a call to set the power state to on after the resume
has run, and this is at-least getting a usable system. However I do
not think this is the correct action. init.rc has a line for echoing
"on" to /sys/power/state but this never seems to be run.
Robert Beckett
it up again.
Try putting a KEY_POWER press and release event in your keyboard driver
on a resume. This will then report the power key press that you actually
did to wake the device up. Android should then see that event and hold a
wake lock.
If your device is suspending before the userland gets chance to resume,
then that is a bug, and something needs to hold a wake lock, but I dont
see that on my build.
Perhaps a log with your console log level set to 7 or higher would
enable you to see how far the resume is getting before the next suspend
occurs.