On Fri, 28 May 2010, Alan Cox wrote:
> If I push the button we get an IRQ
> We come out of power save
> The app gets poked
> The app may be unimportant but the IRQ means we have a new timeout of
> some form to run down to idle
> The app marks itself important
> The app stays awake for 60 seconds rsyncing your email
> The app marks itself unimportant
> Time elapses
> We return to suspend
>
>
> If you are absolutely utterly paranoid about it you need the button
> driver to mark the task it wakes back as important rather than rely on
> time for response like everyone else. That specific bit is uggglly but
> worst case its just a google private patch to a few drivers. I understand
> why Android wants it. The narrower the gap between 'we are doing nothing,
> sit in lowest CPU on state' and 'we are off' the better the battery life
> and the more hittable the condition.
That "private patch to a few drivers" is almost exactly what suspend
blockers are. Given that much of this discussion has revolved around
whether suspend blockers are accptable in the kernel, I don't think you
should shrug them off quite so easily.
Also, you have forgotten about the case where there is no app waiting
to get poked:
The app is busy doing something else unimportant
We do into power save
Push a button, generate an IRQ
Come out of power save
No app to poke
* System goes back to sleep and eventually wakes up again
The app finishes what it was doing
The app sees there is a keystroke and marks itself important
...
The * step is where trouble can occur.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
