[PATCH 1/8] PM: Add suspend block api.
in [Kernel]
|
Prev: [PATCH 7/8] Input: Block suspend while event queue is not empty.
Next: [PATCH 3/8] PM: suspend_block: Abort task freezing if a suspend_blocker is active.
From: Alan Stern on 5 May 2010 11:50 On Tue, 4 May 2010, mark gross wrote: > Thanks, I think I'm starting to get it. From this it seems that the > system integrator needs to identify those wake up sources that need to > be able to block a suspend, and figure out a way of acknowledging from > user mode, that its now ok to allow a suspend to happen. The second part is easy. Userspace doesn't need to do anything special to acknowledge that a suspend is now okay; it just has to remove the conditions that led the driver to block suspends in the first place. For example, if suspends are blocked because some input event has been queued, emptying the input event queue should unblock suspends. > The rev-6 proposed way is for the integrator to implement overlapping > blocker sections from ISR up to user mode for selected wake up devices > (i.e. the modem) > > There *has* to be a better way. Why? What's wrong with overlapping blockers? It's a very common idiom. For example, the same sort of thing is used when locking subtrees of a tree: You lock the root node, and then use overlapping locks on the nodes leading down to the subtree you're interested in. > Can't we have some notification based thing that supports user mode > acks through a misc device or sysfs thing? Anything to avoid the > overlapping blocker sections. Userspace acks aren't the issue; the issue is how (and when) kernel drivers should initiate a blocker. Switching to notifications, misc devices, or sysfs won't help solve this issue. > True, you need an ack back from user mode for when its ok to allow > suspend to happen. This ack is device specific and needs to be custom > built per product to its wake up sources. No and no. Nothing special is needed. All userspace needs to do is remove the condition that led to the blocker being enabled initially -- which is exactly what userspace would do normally anyway. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: mark gross on 5 May 2010 16:10 On Wed, May 05, 2010 at 02:31:31PM +0100, Matthew Garrett wrote: > On Tue, May 04, 2010 at 06:50:50PM -0700, mark gross wrote: > > > In my sequence above I had the modem driver "magically" knowing to fail > > this suspend attempt. (that "magic" wasn't fully thought out though.) > > If the modem driver knows to "magically" fail a suspend attempt until it > knows that userspace has consumed the event, you have something that > looks awfully like suspend blockers. > > > There *has* to be a better way. > > But nobody has reasonably proposed one and demonstrated that it works. > We've had over a year to do so and failed, and I think it's pretty > unreasonable to ask Google to attempt to rearchitect based on a > hypothetical. > These are not new issues being raised. They've had over a year to address them, and all thats really happened was some sed script changes from wake_lock to suspend_blocker. Nothing is really different here. Rearchitecting out of tree code is as silly thing for you to expect from a community member. sigh, lets stop wasting time and just merge it then. I'm finished with this thread until I do some rearchecting and post something that looks better to me. I'll look for this stuff in 2.6.34 or 35. --mgross ps It think the name suspend blocker is worse than wake-lock. I'd change it back. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: mark gross on 5 May 2010 16:30 On Wed, May 05, 2010 at 11:44:39AM -0400, Alan Stern wrote: > On Tue, 4 May 2010, mark gross wrote: > > > Thanks, I think I'm starting to get it. From this it seems that the > > system integrator needs to identify those wake up sources that need to > > be able to block a suspend, and figure out a way of acknowledging from > > user mode, that its now ok to allow a suspend to happen. > > The second part is easy. Userspace doesn't need to do anything special > to acknowledge that a suspend is now okay; it just has to remove the > conditions that led the driver to block suspends in the first place. > > For example, if suspends are blocked because some input event has been > queued, emptying the input event queue should unblock suspends. > > > The rev-6 proposed way is for the integrator to implement overlapping > > blocker sections from ISR up to user mode for selected wake up devices > > (i.e. the modem) > > > > There *has* to be a better way. > > Why? What's wrong with overlapping blockers? It's a very common > idiom. For example, the same sort of thing is used when locking > subtrees of a tree: You lock the root node, and then use overlapping > locks on the nodes leading down to the subtree you're interested in. Because in the kenel there is only a partial ordering of calling sequences from IRQ to usermode. I see a lot of custom out of tree code being developed to deal with getting the overlapping blocker sections right, per device. > > Can't we have some notification based thing that supports user mode > > acks through a misc device or sysfs thing? Anything to avoid the > > overlapping blocker sections. > > Userspace acks aren't the issue; the issue is how (and when) kernel > drivers should initiate a blocker. Switching to notifications, misc > devices, or sysfs won't help solve this issue. communicating non-local knowledge back down to the blocking object to tell it that it can unblock is the issue > > True, you need an ack back from user mode for when its ok to allow > > suspend to happen. This ack is device specific and needs to be custom > > built per product to its wake up sources. > > No and no. Nothing special is needed. All userspace needs to do is > remove the condition that led to the blocker being enabled initially -- > which is exactly what userspace would do normally anyway. Oh, like tell the modem that user mode has handled the ring event and its ok to un-block? --mgross -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Garrett on 5 May 2010 16:30 On Wed, May 05, 2010 at 01:09:06PM -0700, mark gross wrote: > On Wed, May 05, 2010 at 02:31:31PM +0100, Matthew Garrett wrote: > > But nobody has reasonably proposed one and demonstrated that it works. > > We've had over a year to do so and failed, and I think it's pretty > > unreasonable to ask Google to attempt to rearchitect based on a > > hypothetical. > > > > These are not new issues being raised. They've had over a year to > address them, and all thats really happened was some sed script changes > from wake_lock to suspend_blocker. Nothing is really different > here. Our issues haven't been addressed because we've given no indication as to how they can be addressed. For better or worse, our runtime powermanagement story isn't sufficient to satisfy Google's usecases. That would be fine, if we could tell them what changes needed to be made to satisfy their usecases. The Android people have said that they don't see a cleaner way of doing this. Are we seriously saying that they should prove themselves wrong, and if they can't they don't get their code in the kernel? This seems... problematic. -- Matthew Garrett | mjg59(a)srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Stern on 5 May 2010 17:20
On Wed, 5 May 2010, mark gross wrote: > > > True, you need an ack back from user mode for when its ok to allow > > > suspend to happen. This ack is device specific and needs to be custom > > > built per product to its wake up sources. > > > > No and no. Nothing special is needed. All userspace needs to do is > > remove the condition that led to the blocker being enabled initially -- > > which is exactly what userspace would do normally anyway. > > Oh, like tell the modem that user mode has handled the ring event and > its ok to un-block? No, that's not how it works. It would go like this: The modem IRQ handler queues its event to the input subsystem. As it does so the input subsystem enables a suspend blocker, causing the system to stay awake after the IRQ is done. The user program enables its own suspend blocker before reading the input queue. When the queue is empty, the input subsystem releases its suspend blocker. When the user program finishes processing the event, it releases its suspend blocker. Now the system can go back to sleep. At no point does the user program have to communicate anything to the modem driver, and at no point does it have to do anything out of the ordinary except to enable and disable a suspend blocker. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |