On Tue, May 25, 2010 at 04:54:34PM -0700, Arve Hjønnevåg wrote: > 2010/5/25 Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>: > > On Tue, May 25, 2010 at 04:13:35PM -0700, Arve Hjønnevåg wrote: > >> > >> You are missing the point. There are no event pending. The kernel > >> reported the key down event, it was handled, but the keypad driver is > >> still scanning to see if the user presses another key, > > > > Employ reasonable timeout. > > Timeout for what? Stop trying to suspend altogether, stop scanning for > key changes, or a more "reasonable" poll interval? Stop trying to suspend for a fraction of a second to see if user wants to press another key. > > > > >> or releases the > >> currently held key. > >> > > > > Userspace consumer should wait for the key release and retract "busy" > > once event is received and handled. > > > > No it should not. User-space does not know if the key is coming from a > keypad driver that needs to actively scan the matrix while keys are > pressed. OTOH nor does kernel driver know whether system suspend should be blocked while it is scanning. What should happen in I press KEY_SUSPEND? Do we always want to wait till user releases it? > > >> > > >> > 2. Wait a tiny bit after last application notified you that it finished > >> > processing events. > >> > > >> > So basically the difference is that with in-kernel suspend blockers, > >> > there is a tiny window where we haven't started the suspend yet but are > >> > about to the driver has a chance to prevent entire system from starting > >> > sleep. > >> > >> No, the difference is that if a driver needs to prevent suspend for an > >> extended period of time, you don't have user space continuously > >> polling to see if it can suspend. > > > > Why would a driver, on its own, prevent suspend for extended periods of > > time? I think that the decision should originate from userspace, kernel > > is here just to serve the requests. > > > > A driver prevents suspend if suspend would prevent it from working. > For instance, the gpio keypad matrix code prevents suspend when a key > is help down, since it has to activly scan the keypad for changes. > Only no-keys-pressed versus one-or-more-keys-pressed can be detected > with an interrupt. > > >> > >> > > >> > Without the blocker we may start suspending and will stop midcycle. We > >> > may be even better off in the end since we could leave some devices > >> > still powered down after aborting system-wide suspend. > >> > > >> > >> That does not sound right. > > > > Why doesn't it? If a device implements runtime PM it may chose remain in > > powered-down mode even if system is awake. > > > > If the device implements runtime PM it should already be powered-down > if it is not in use. It could have been in use but userspace-initiated suspend accelerated it entering low power state. -- Dmitry _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
