On Fri, 2010-05-07 at 14:35 -0700, Arve Hjønnevåg wrote: > On Fri, May 7, 2010 at 2:30 PM, Daniel Walker <dwalker@xxxxxxxxxx> wrote: > > On Fri, 2010-05-07 at 22:03 +0100, Matthew Garrett wrote: > > > >> Here's a different example. A process is waiting for a keypress, but > >> because it's badly written it's also drawing to the screen at 60 frames > >> per second and preventing the system from every going to idle. How do > >> you quiesce the system while still ensuring that the keypress will be > >> delivered to the application? > > > > To me it's somewhat of a negative for suspend blockers. Since to solve > > the problem you give above you would have to use a suspend blocker in an > > asynchronous way (locked in an interrupt, released in a thread too) > > assuming I understand your example. I've had my share of semaphore > > nightmares, and I'm not too excited to see a protection scheme (i.e. a > > lock) which allows asynchronous usage like suspend blockers. > > > > Why do you think this? The example in the documentation describe how > we handle key events. +- The Keypad driver gets an interrupt. It then calls suspend_block on the + keypad-scan suspend_blocker and starts scanning the keypad matrix. +- The keypad-scan code detects a key change and reports it to the input-event + driver. +- The input-event driver sees the key change, enqueues an event, and calls + suspend_block on the input-event-queue suspend_blocker. +- The keypad-scan code detects that no keys are held and calls suspend_unblock + on the keypad-scan suspend_blocker. +- The user-space input-event thread returns from select/poll, calls + suspend_block on the process-input-events suspend_blocker and then calls read + on the input-event device. +- The input-event driver dequeues the key-event and, since the queue is now + empty, it calls suspend_unblock on the input-event-queue suspend_blocker. +- The user-space input-event thread returns from read. If it determines that + the key should leave the screen off, it calls suspend_unblock on the + process_input_events suspend_blocker and then calls select or poll. The + system will automatically suspend again, since now no suspend blockers are + active. This? Isn't this asynchronous on the input-event-queue since it's taken in the interrupt , and release in the userspace thread? Daniel _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
