On Wed 2009-02-04 18:50:14, Arve Hj??nnev??g wrote: > Signed-off-by: Arve Hj??nnev??g <arve@xxxxxxxxxxx> > --- > Documentation/power/wakelocks.txt | 91 ++++++++++++++++++++++++++++++++++++ > include/linux/wakelock.h | 92 +++++++++++++++++++++++++++++++++++++ > 2 files changed, 183 insertions(+), 0 deletions(-) > create mode 100644 Documentation/power/wakelocks.txt > create mode 100755 include/linux/wakelock.h > > diff --git a/Documentation/power/wakelocks.txt b/Documentation/power/wakelocks.txt > new file mode 100644 > index 0000000..219bb11 > --- /dev/null > +++ b/Documentation/power/wakelocks.txt > @@ -0,0 +1,91 @@ > +Wakelocks > +========= > + > +A locked wakelock, depending on its type, prevents the system from entering > +suspend or other low-power states. When creating a wakelock, you can select > +if it prevents suspend or low-power idle states. If the type is > set to idle states are very different from suspend. Mixing them does not look like good idea... and IIRC we already have API somewhere to prevent deep idle states. Intel did it for their wireless cards IIRC. > +If the suspend operation has already started when locking a wakelock, it will > +abort the suspend operation as long it has not already reached the suspend_late > +stage. This means that locking a wakelock from an interrupt handler or a > +freezeable thread always works, but if you lock a wakelock from a suspend_late > +handler you must also return an error from that handler to abort suspend. > + > +Wakelocks can be used to allow user-space to decide which keys should wake the > +full system up and turn the screen on. Use set_irq_wake or a platform specific > +api to make sure the keypad interrupt wakes up the cpu. Once the keypad driver > +has resumed, the sequence of events can look like this: > +- The Keypad driver gets an interrupt. It then locks the keypad-scan wakelock > + 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 locks > + the input-event-queue wakelock. > +- The keypad-scan code detects that no keys are held and unlocks the > + keypad-scan wakelock. > +- The user-space input-event thread returns from select/poll, locks the > + process-input-events wakelock and then calls read in the input-event device. > +- The input-event driver dequeues the key-event and, since the queue is now > + empty, it unlocks the input-event-queue wakelock. > +- The user-space input-event thread returns from read. It determines that the > + key should not wake up the full system, releases the process-input-events > + wakelock and calls select or poll. > + > + Key pressed Key released > + | | > +keypad-scan ++++++++++++++++++ > +input-event-queue +++ +++ > +process-input-events +++ +++ > + I'm not sure if keyboard scanning example is good here. It is very t-mobile G1 specific. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
