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

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Sunday 08 February 2009, Arve Hjønnevåg wrote:
> On Sat, Feb 7, 2009 at 12:53 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >> +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.
> >
> > I don't really understand this description, sorry.
> >
> > In particular, what values can be written to /sys/power/request_state, what
> > their meaning is and what's supposed to happen if someone writes one of these
> > values to this file?
> 
> Is it clearer if I change it to:
> 
> The early-suspend api allows drivers to get notified when user-space writes a
> sleep state, e.g. "mem", or "on" to /sys/power/request_state to indicate that
> the user visible sleep state should change. ...

So, how is it different from the "normal" suspend?  Do you want that to happen
before tasks are frozen?

> >
> >> +
> >> +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.
> >
> > What exactly is the meaning of "suspend" here?
> 
> early-suspend.

OK

How exactly are these levels going to be used?

> >> +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.
> >
> > How exactly is the notification supposed to happen?
> 
> Console switch or a blocking sysfs read.

Let's choose the console switch for example.  What would you like to happen
during early suspend on the EARLY_SUSPEND_LEVEL_STOP_DRAWING level?

> >> +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.
> >
> > This always happens during suspend-resume.  How is this different from the
> > usual suspend-resume behaviour?
> 
> It happens when user-space changes the state, before wakelocks are released.

Can you give an example, please?

> >> +struct early_suspend {
> >> +#ifdef CONFIG_HAS_EARLYSUSPEND
> >> +     struct list_head link;
> >> +     int level;
> >> +     void (*suspend)(struct early_suspend *h);
> >> +     void (*resume)(struct early_suspend *h);
> >> +#endif
> >> +};
> >
> > Does this mean addional suspend-resume callbacks for device drivers?
> 
> Yes.
> 
> > If so, how are they different from the "standard" suspend-resume callbacks?
> 
> They are called at a different time.

My question was about the functionality.  Are they supposed to be
_functionally_ different from the "standard" callbacks?

> > Also, what about bus types that carry out some suspend-resume operations
> > for their devices, like PCI?  Your early callbacks don't seem to take the
> > bus type part into account.
> 
> No, the driver will have to take care of this. It has to do the same
> work as it would do if it got and ioctl command to enter a low power
> state.

Many drivers have no such ioctls.  Moreover, during "normal" suspend the
drivers' ->suspend() callbacks are not called directly by the PM core, but they
are called via the appropriate bus type driver's ->suspend() callback, so the
bus type driver may perform additional operations before or after calling the
driver's callback.  The PCI bus type driver actually does it.

> > My understanding of the 'early suspend' idea is that it is a mechanism allowing
> > us to place some devices selectively into low power states before the actual
> > suspend happens.  However, this is exactly the same as runtime power
> > management on demand, with an interface allowing user space to put devices into
> > low power states.
> 
> The main point is to have a single entrypoint from user-space. We do
> not have a list of devices to suspend in user-space.

We don't need such a list.  The devices may be suspended automatically by the
kernel after a period of (device) inactivity, for example.

> > Now, in my opinion, runtime power management should be implemented on the
> > bus type level, since bus types differ from each other by power management
> > requirements, mechanisms that can be used and hardware interfaces.
> >
> > I have some prototype patches for PCI runtime PM in the works.  I didn't
> > intend to post them just yet, since I'm considering them as work in progress.
> > Still, I can do that if you think it would be useful.
> 
> We don't have a PCI bus, but a generic mechanism to put individual
> devices to sleep, from within the kernel or from user-space, would be
> useful.

The mechanism may not be 100% generic, because for different buses and
platforms there are different _hardware_ mechanisms for putting devices into
low power/full power states.  For example, PCI devices can generally be in
one of 4 different power states, while there are only 2 power states available
to USB devices.  Also, on PCI you can put an entire BUS segment into a low
power state, etc.

Thanks,
Rafael