On Sunday 08 February 2009, Arve Hjønnevåg wrote:
> On Sat, Feb 7, 2009 at 12:53 PM, Rafael J. Wysocki <rjw@xxxxxxx> 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
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
