2010/6/2 Thomas Gleixner <tglx@xxxxxxxxxxxxx>: > On Tue, 1 Jun 2010, Arve Hjønnevåg wrote: >> 2010/6/1 Thomas Gleixner <tglx@xxxxxxxxxxxxx>: >> > On Mon, 31 May 2010, Arve Hjønnevåg wrote: >> > >> >> 2010/5/31 Rafael J. Wysocki <rjw@xxxxxxx>: >> >> > On Monday 31 May 2010, Arve Hjønnevåg wrote: >> >> >> 2010/5/30 Rafael J. Wysocki <rjw@xxxxxxx>: >> >> > ... >> >> >> >> >> >> I think it makes more sense to block suspend while wakeup events are >> >> >> pending than blocking it everywhere timers are used by code that could >> >> >> be called while handling wakeup events or other critical work. Also, >> >> >> even if you did block suspend everywhere timers where used you still >> >> >> have the race where a wakeup interrupt happens right after you decided >> >> >> to suspend. In other words, you still need to block suspend in all the >> >> >> same places as with the current opportunistic suspend code, so what is >> >> >> the benefit of delaying suspend until idle? >> >> > >> >> > Assume for a while that you don't use suspend blockers, OK? I realize you >> >> > think that anything else doesn't make sense, but evidently some other people >> >> > have that opinion about suspend blockers. >> >> > >> >> >> >> It sounded like you were suggesting that initiating suspend from idle >> >> would somehow avoid the race condition with wakeup events. All I'm >> >> saying is that you would need to block suspend in all the same places. >> >> If you don't care about ignoring wakeup events, then sure you can >> >> initiate suspend from idle. >> > >> > And why should you miss a wakeup there ? If you get an interrupt in >> > the transition, then you are not longer idle. >> > >> >> Because suspend itself causes you to not be idle you cannot abort >> suspend just because you are not idle anymore. > > You still are addicted to the current suspend mechanism. :) > No I want you to stop confusing low power idle modes with suspend. I know how to enter low power modes from idle if that low power mode is not too disruptive. > The whole point of doing it from idle in the form of a deep power > state is to avoid the massive sh*tload of work which is neccesary to > run the existing suspend code. But that needs runtime power management > and tweaks to avoid your timers waking you, etc. > > The mechanism you want to use is: suspend no matter what, like closing > the lid of the laptop, but with a few tweaks around it: > > 1) An interrupt on a wakeup source which comes in while the suspend > code runs, i.e before you transitioned into wakeup mode, must > abort / prevent suspend. > > 2) Prevent another attempt to suspend before the event has been > delivered and the apps have signaled that they have not longer > any work to do. > > As a side effect you confine crappy apps with that mechanism in > some way. > > In the laptop case we do not want the tweaks as not going into suspend > might set your backpack on fire. If that is the case you should also disable the wakeup events. > > If I understood you correctly then you can shutdown the CPU in idle > completelty already, but that's not enough due to: > > 1) crappy applications keeping the cpu away from idle > 2) timers firing > > Would solving those two issues be sufficient for you or am I missing > something ? Solving those two is enough for current android phones, but it may not be enough for other android devices. 1 is not solvable (meaning we cannot fix all apps), and 2 is difficult to fix since the periodic work is useful while the device is actually in use. One possible way to solve 2 is to allow timers on a not-idle clock. Unrelated to Android, I also want to use opportunistic suspend on my desktop. -- Arve Hjønnevåg -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
