2010/5/6 Tony Lindgren <tony@xxxxxxxxxxx>: > * Arve Hjønnevåg <arve@xxxxxxxxxxx> [100505 21:11]: >> On Wed, May 5, 2010 at 5:05 PM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: >> > * Brian Swetland <swetland@xxxxxxxxxx> [100505 16:51]: >> >> On Wed, May 5, 2010 at 4:47 PM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: >> >> > * 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. >> >> >> >> We actually are trying to suspend all the time -- that's our basic >> >> model -- suspend whenever we can when something doesn't prevent it. >> > >> > Maybe that state could be kept in some userspace suspend policy manager? >> > >> >> >> > 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? >> >> >> >> How often would we retry suspending? >> > >> > Well based on some timer, the same way the screen blanks? Or five >> > seconds of no audio play? So if the suspend fails, then reset whatever >> > userspace suspend policy timers. >> > >> >> If we fail to suspend, don't we have to resume all the drivers that >> >> suspended before the one that failed? (Maybe I'm mistaken here) >> > >> > Sure, but I guess that should be a rare event that only happens when >> > you try to suspend and something interrupts the suspend. >> > >> >> This is not a rare event. For example, the matrix keypad driver blocks >> suspend when a key is down so it can scan the matrix. > > Sure, but how many times per day are you suspending? > How many times we successfully suspend is irrelevant here. If the driver blocks suspend the number of suspend attempts depend on your poll frequency. >> >> With the suspend block model we know the moment we're capable of >> >> suspending and then can suspend at that moment. Continually trying to >> >> suspend seems like it'd be inefficient power-wise (we're going to be >> >> doing a lot more work as we try to suspend over and over, or we're >> >> going to retry after a timeout and spend extra time not suspended). >> >> >> >> We can often spend minutes (possibly many) at a time preventing >> >> suspend when the system is doing work that would be interrupted by a >> >> full suspend. >> > >> > Maybe you a userspace suspend policy manager would do the trick if >> > it knows when the screen is blanked and no audio has been played for >> > five seconds etc? >> > >> >> If user space has to initiate every suspend attempt, then you are >> forcing it to poll whenever a driver needs to block suspend. > > Hmm I don't follow you. If the userspace policy daemon timer times > out, the device suspends. If the device does not suspend because of > a blocking driver, then the timers get reset and you try again based > on some event such as when the screen blanks. > This retry is what I call polling. You have to keep retrying until you succeed. Also, using the screen blank timeout for this polling is not a good idea. You do not want to toggle the screen off and on with with every suspend attempt. -- Arve Hjønnevåg _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
