On Mon, 27 Sep 2004, David Brownell wrote:
> Pavel says this is <linux/kernel.h> system_state, but I don't
> see the mapping. Used by "ide-disk.c", and little else.
> SYSTEM_BOOTING isn't a power level...
>
> I'd be interested in seeing system power policies be pluggable
> objects like cpufreq governors, i/o schedulers, and so forth.
>
> A sysadmin would choose from a list of policies. Some would
> take command like "suspend to disk" (on systems with disks),
> some architectures would add their own commands. If you
> suspend from a "max power savings" policy, you'd normally
> resume into that same policy, not go to full power.
Here's my updated conception.
The PM core defines several different system power states, each with its
own expectation about how things will work. People have mentioned these
several times, so a brief summary is:
Power-On: Everything at max power, ready for immediate use
Standby: Devices use reduced power, can return to Power-On
very quickly
Suspend-to-RAM: Everything turned off except RAM refresh, takes
several seconds to return to Power-On
Suspend-to-Disk: You get the idea...
etc.
User processes run only in the Power-On state. In other states devices
shouldn't issue IRQs (and interrupts may even be disabled) apart from
wakeup requests. Any wakeup request received in one of the other states
causes a transition to the Power-On state. I think this is pretty much
the way PM is set up right now.
The default policy is that in each system state, a device can use the
maximum power setting consistent with that state. If the device isn't
active but it supports wakeup, then wakeup is enabled.
Other policies define changes from the default, which means they indicate
conditions under which individual devices or entire subsystems might use
less power than the default allows or might disable wakeup. As an
example, a policy could state that during Power-On all USB mouse devices
should go into suspend mode with wakeup enabled after 5 seconds of
inactivity. Another policy could say that during Suspend-to-Disk,
Wake-on-LAN should be disabled.
I haven't got the faintest idea how policies might be represented or
implemented. Maybe largely as user programs. The only sort of policy I
can talk about is a local user-directed change, caused by the user writing
to a sysfs .../dev/power/* file.
For simplicity, we will want to retain the PCI core's approach of keeping
power-level and wakeup-status separate and independent. During changes of
system state, the PM core will insure that all the necessary transitions
can be carried out, by temporarily resuming parent devices when needed.
However, changes requested by a user through sysfs may fail because: the
device can't make the requested change without going to full-power first,
the device can't make the requested change unless its parent is at full
power, or the device doesn't support wakeup in the requested state.
One problem: Since the PM core doesn't understand device power states, it
won't know if a request coming through sysfs is for an increase or a
decrease. All it can do is pass the information to the appropriate
driver, together with an indication that this is a user request rather
than a system state change. Note that since all such requests can only
occur in the Power-On state, there's never a problem about trying to
change to a higher-power level than the state allows.
Alan Stern
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
