On Thu 2009-02-26 13:11:05, Arve Hj?nnev?g wrote: > On Thu, Feb 26, 2009 at 7:04 AM, Pavel Machek <pavel@xxxxxx> wrote: > > Hi! > > > >> > It is discouraging to hear comments like "we have been talking about for years something else" yet nothing exists or is in open development. Things can evolve in place. > >> > >> This is userlad-visible ABI. We can't evolve it in place - we need to > >> get it right before merging it, otherwise we need to carry on > >> maintaining code for an extended period of time in order to ensure that > >> there's no userland code that depends on it. > > > > Plus... sleepy patches showed that autosuspend can be done *without* > > new userland ABIs. > > As far as I can tell the sleepy patches tries to enter suspend if the > system is idle. If you plan to wake back up for the first timer, then > the end result of this is the same as what we get by entering the low > power state from arch_idle in the msm platform. Due to the frequent > wakeups, the power use is higher than our suspend state. If you don't > wake up on the first timer, you need something like the wakelock api > so apps specify that they need to run even if they were inactive for 3 > seconds. You understand it right... it wakes up on first event. So you eliminate all the timers that fire too often... and fix userspace if neccessary. Given that your 3rd party apps are written in java, you should have enough control over them. What in-kernel timers are causing problems for you? For how long can Android sleep? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
