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. -- 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
