Andy Green writes:
>>> They have a single wakelock to cover delayed work in there, however
>>> there are multiple delayed works possible to be queued, eg delayed
>>> disable and delayed detect actions, and although they wrap scheduling
>>> the delayed work to also lock the wakelock, they don't wr
On 07/07/2011 10:43 AM, Somebody in the thread at some point said:
Not certain you meant this by "handled immediately" but to be clear
cancel_delayed_work() deletes the timer that creates the delay, and
stops the work ever from being executed. In that case the wakelock
will be left locked with
On 07/07/2011 09:37 AM, Somebody in the thread at some point said:
Hi Kan-Ru -
They have a single wakelock to cover delayed work in there, however
there are multiple delayed works possible to be queued, eg delayed
disable and delayed detect actions, and although they wrap scheduling
the delayed
Hi Andy,
Andy Green writes:
> Hi -
>
> Yesterday I studied suspend status on 3.0 kernel for Panda, for mem
> suspend it's working pretty well in Ubuntu case, desktop is coming
> back up woken by USB keyboard action, WLAN is workable after
> reassociation.
>
> However in Android case, the same tr
Hi -
Yesterday I studied suspend status on 3.0 kernel for Panda, for mem
suspend it's working pretty well in Ubuntu case, desktop is coming back
up woken by USB keyboard action, WLAN is workable after reassociation.
However in Android case, the same tree merged with common-android-3.0 to
get
