Re: [PATCH 02/13] PM: Add early suspend api.

[Uli Luckas <u.luckas@road.de>]

On Friday, 6. February 2009, mark gross wrote:
> On Wed, Feb 04, 2009 at 06:50:15PM -0800, Arve Hjønnevåg wrote:
> > Signed-off-by: Arve Hjønnevåg <arve@android.com>
> > ---
> >  Documentation/power/early-suspend.txt |   26 +++++++++++++++
> >  include/linux/earlysuspend.h          |   55
> > +++++++++++++++++++++++++++++++++ 2 files changed, 81 insertions(+), 0
> > deletions(-)
> >  create mode 100644 Documentation/power/early-suspend.txt
> >  create mode 100755 include/linux/earlysuspend.h
> >
> > diff --git a/Documentation/power/early-suspend.txt
> > b/Documentation/power/early-suspend.txt new file mode 100644
> > index 0000000..8286d3a
> > --- /dev/null
> > +++ b/Documentation/power/early-suspend.txt
> > @@ -0,0 +1,26 @@
> > +Early-suspend
> > +=============
> > +
> > +The early-suspend api allows drivers to get notified when user-space
> > writes to +/sys/power/request_state to indicate that the user visible
> > sleep state should +change. A level controls what order the handlers are
> > called in. Suspend +handlers are called in low to high level order,
> > resume handlers are called in +the opposite order.
> > +
> > +Four levels are defined:
> > +EARLY_SUSPEND_LEVEL_BLANK_SCREEN:
> > +  On suspend the screen should be turned off but the framebuffer must
> > still be +  accessible. On resume the screen can be turned back on.
> > +
> > +EARLY_SUSPEND_LEVEL_STOP_DRAWING:
> > +  On suspend this level notifies user-space that it should stop
> > accessing the +  framebuffer and it waits for it to complete. On resume
> > it notifies user-space +  that it should resume screen access.
> > +  Two methods are provided, console switch or a sysfs interface.
> > +
> > +EARLY_SUSPEND_LEVEL_DISABLE_FB:
> > +  Turn off the framebuffer on suspend and back on on resume.
> > +
> > +EARLY_SUSPEND_LEVEL_STOP_INPUT:
> > +  On suspend turn off input devices that are not capable of wakeup or
> > where +  wakeup is disabled. On resume turn the same devices back on.
>
> these levels names are domain and device profile centric.  How can we
> make these be applicable to more than the HTC dream?
>
> Why 4 levels?  4 seems like too many, but why stop at 4 why not 8?
>
The random number 4 comes from randomly pushing things from userspace to 
kernelspace.
The only thing that I can see the kernel really needs to do is inform user 
space when it comes back from suspend.
I never got a reply to why userspace should ever have to stop drawing to the 
frame buffer. If there is a valid reason for that, we might also need a 
blocking pre-suspend notifier, telling userspace that the device will suspend 
imediately.

Uli

-- 

------- ROAD ...the handyPC Company - - -  ) ) )

Uli Luckas
Head of Software Development

ROAD GmbH
Bennigsenstr. 14 | 12159 Berlin | Germany
fon: +49 (30) 230069 - 62 | fax: +49 (30) 230069 - 69
url: www.road.de

Amtsgericht Charlottenburg: HRB 96688 B
Managing director: Hans-Peter Constien