* Brian Swetland <swetland@xxxxxxxxxx> [100505 14:34]: > On Wed, May 5, 2010 at 2:12 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > >> > >> 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. How about instead the modem driver fails to suspend until it's done? Each driver could have a suspend_policy sysfs entry with options such as [ forced | safe ]. The default would be forced. Forced would be the current behaviour, while safe would refuse suspend until the driver is done processing. > > 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. And also the input layer could refuse to suspend until it's done. > > When the user program finishes processing the event, it > > releases its suspend blocker. Now the system can go back to > > sleep. And here the user space just tries to suspend again when it's done? It's not like you're trying to suspend all the time, so it should be OK to retry a few times. > > 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. > > Exactly -- and you can use the same style of overlapping suspend > blockers with other drivers than input, if the input interface is not > suitable for the particular interaction. Would the suspend blockers still be needed somewhere in the example above? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
