On Sun, 26 Sep 2004, David Brownell wrote: > No, I'm saying your model has to be more flexible about the > way it accomodates policy constraints. STR is a system policy > transition, not a device power level. The current PM framework > has big problems because it doesn't even recognize the current > distinctions there (e.g. PM_SUSPEND_* vs PCI_D2 etc). > > One device might be completely "off" in STR. Another might > be significantly more active. Both can be fine, it's entirely up > to how that system has been built. You've been assuming > everything must be "off", precluding other types of system. > (Current PMcore may be making that assumption for you...) > > 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. 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). (Although perhaps we might want to reserve 0 to mean "unspecified" -- and we undoubtedly will want to use enumeration constants rather than integer values.) 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. 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. 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. 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. 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
