On Thu, May 27, 2010 at 08:03:13PM +0100, Alan Cox wrote: > > No, it's not. Forced suspend may be in response to hitting a key, but it > > You are the only person here talking about 'forced' suspends. The rest of > us are talking about idling down and ensuring we are always in a state we > un-idle correctly. Sigh. No. Forced suspend is a fact of life, and suspend blockers improve the ability to support it. It's orthogonal to more general runtime PM. > > may also be in response to a 30 minute timeout expiring. If I get a WoL > > packet in the 0.5 of a second between userspace deciding to suspend and > > actually doing so, the system shouldn't suspend. > > I don't think that argument holds water in the form you have it > > What about 5 nanoseconds before you suspend. Now you can't do that (laws > of physics and stuff). Drivers should enable wakeups before they disable interrupts. So either the packet hits the IRQ handler and the driver takes a suspend block (aborting suspend in the process) or it doesn't, the GPE goes high and the system resumes immediately after entering S3. > Set wake flags > Check if idle > If idle > Suspend > else > Clear wake flags > Unwind > > and the wake flags guarantee that an event at any point after the wake > flags are set until they are cleared will cause a suspend to be resumed, > possibly immediately after the suspend. Exactly. So the 5 nanosecond case is already handled. The interesting case is where userspace makes the decision to go to sleep and starts performing various housekeeping tasks before triggering the suspend. You need some way to abort that suspend. The hardware may be long idle by then, so you can't just look at the hardware state. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx -- 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
