On Thu, 27 May 2010 17:38:03 -0400 (EDT) Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > and power management does the rest. If an event wakes up the process > > before we get to suspend in kernel we will wake it back up. > > Okay, and the kernel never suspends. We _are_ talking about a kind of > forced suspend, right? No ? We are talking about just letting power management solve the whole problem for us. > > If the event > > gets in after pm decides to idle via suspend then it'll bounce through > > the kernel back to a kernel resume, > > No, it won't. That's the problem suspend blockers were meant to solve. > The event winds up sitting in a kernel queue, the PM core doesn't know > about it (that's what I meant above -- the PM core doesn't know as much > as you seem to think it does), and the suspend takes place regardless. No - because we are not forcing the suspend. The app must go idle. If you force the suspend of running processes then yes the entire thing goes castors up - which is why it's a bad idea to do so. > > or potentially through a full > > hardware/software suspend/resume bounce. > > It would be okay if that happened. But once the event gets into the > kernel and the hardware IRQ source has turned off, there's nothing to > cause the resume. Read the discussion about how the race is avoided at the hardware level. That race is I think not there and furthermore most drivers get it right already. There are several cases 1. IRQ during app layer (ie policy in user space) asking applications to go passive - The event occurs, we undo the app layer policy, easy (or app wakes process and we let it fall through) 2. IRQ after the app layer quiesces its clients - The task wakes, the app layer won't see it - the app layer allows suspend as an idle mode. Not a problem - the app is running the cpu policy manager will see this and not suspend until the app has been asleep for a bit. The app may well of course tell the UI layer 'hey I want you back on' and it take you back to the full on case. 3. IRQ after kernel suspend begins - The driver will refuse the suspend, we don't suspend, we unwind the resume so far, the app wakes, we propogate stuff back up to user space whose policy manager unwinds its position 4. IRQ after driver has done its final checks - Wake up lines are set - We suspend - We immediately get resumed - We follow the full resume path This is I believe robust (and has been implemented on some non x86 boxes). It depends on not forcing running tasks into suspend. That is the key. Alan -- 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
