On Sunday 26 September 2004 1:22 pm, Alan Stern wrote: > On Sun, 26 Sep 2004, David Brownell wrote: > > > At a driver level, STR vs STD shouldn't matter. The fact that it > > currently seems to matter is IMO a problem with the way the > > PM problem is currently factored ... should be fixed. > > I've decided that you're right. > > So how about this instead? We have a policy-oriented list of power > settings, pretty much the same as it is now. Things like Full-Power, > Standby, Suspend-to-RAM, Suspend-to-Disk, Power-Off, and > Selective-Suspend. The values are descriptive only; they don't indicate > anything about the actual power available to or power used by a device. > They only indicate the reason for making a power-level change. And they > are not stored in the dev_pm_info structure.
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. > In its place there is a i32 value which is opaque to the PM core but > meaningful to individual drivers. This does represent an actual power > level setting. For PCI devices it might range from 0 (= D0) to 4 (= > D3cold). For USB devices it might range from 0 (= powered) to 1 (= > suspended). I'd rather see a struct with a printable name (or even just the printable name) and drivers knowing which constant pointers to compare to. And have that name show up in sysfs. Abolish confusion about u32 values, and easily catch all the drivers (ab)using the old value. Not much code uses those PMcore APIs yet; good changes can be merged. Driver model state probably needs to grow to include the "idle" bit too ... letting drivers support "active-enough" modes that are also low power states (like suspending idle mice), and hardware wakeup. > Drivers for devices that bridge buses > having different power-level standards are responsible for making the > necessary translations. So for example, hcd-pci.c (which manages > PCI-based USB host controller drivers) would translate between PCI power > levels and USB levels. Makes sense to me, but again the power level isn't the most interesting bit to me. Certainly usbcore would be doing basic translations like going from "active" to "idle-with-wakeup" or "idle" states ... but those don't necessarily involve power transitions, if USB wakeup isn't involved. When it comes time to really reduce power consumption, usbcore shouldn't have anything left to do ... only bus/device glue like hcd-pci necessarily needs to be involved. > Since the power values are now device dependent, it becomes impossible for > the PM core to tell whether it is asking a device to go to a higher-power > state than its parent or a lower-power state than one of its children. > The driver will have to check for these errors and report them. > Conversely, for some devices it might not be an error to move e.g. from > Suspend to Standby, although presumably the core wouldn't try to do such a > thing. Right. Though in some cases "bus adapter" code (hcd-pci etc) can enforce the rules for a lot of devices. > When the PM core wants to initiate a power setting change, it makes two > passes through the subtree below the topmost device affected. The first > pass goes downward; the core warns drivers that a change is impending and > passes as arguments the new policy setting and the new i32 value of the > parent device. The driver returns either an error code or its own new > i32. Both the old and new values are stored in dev_pm_info. The second > pass is depth-first; devices are asked to adopt their new i32 power level. Parent info is implicit, don't bother passing it again! And again, i32 is too error prone for my taste. I'm trying to tie threads together here. How does this mesh with what you were saying about an idle state? Wouldn't that first pass better be viewed as "idle all drivers"? Otherwise you're making STR vs STD matter to drivers, which is what I thought you agreed should NOT matter. > That's how suspends work. Resumes aren't so hard; everything can be down > in a single topmost-device-down pass. > > With this scheme, questions like whether or not bus-suspend power is > available during suspend-to-RAM are decided by the driver, based on the > hardware and firmware resources available. The PM core doesn't need to > know or worry about them. The policy and the mechanism are separated. Those are ideas I hope everyone pretty much can agree on, yes. Details ... TBD. There aren't many quick fixes. We're almost ready to start flinging around patches, I suspect ... ;) - Dave ------------------------------------------------------- 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
