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 _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
