On Mon, 27 Sep 2004, David Brownell wrote: > 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.
Couldn't a lot of this be done from userspace, like Oliver suggested? In fact, couldn't you just run swsusp and tell it what the new policy should be? The PM core would then have little to do besides informing drivers about the policy change. > 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. Sounds good to me. The strings could be writable in sysfs as well as readable (to do selective suspend/resume). > 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. The "idle" states I described earlier had nothing to do with power levels. I included them only as a way of communicating to drivers that they should prepare for a memory snapshot. Given some other way to do that, there's no reason to keep an "idle" bit. > > 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. You should call them "suspend-with-wakeup" and "suspend". Don't confuse it with "idle". (Unless I'm the one who's confused and you mean something totally different...) > 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. The way I envision it working is that the user tells the PM core to go to Standby mode, for example. The PM core works its way down the device tree, telling drivers about the change. When it reaches a PCI USB host controller driver, the code in hcd-pci decides what the new PCI state should be (D3hot -- this may already have been decided by higher-level PCI drivers) and what the new USB state should be (suspended-with-wakeup). Continuing down the tree, the usb_generic suspend handler sees that the parent is moving to suspended-with-wakeup so it does the same thing. On the second pass back up through the tree, the usb_generic handler enables remote wakeup and calls usb_suspend_device() (which will only have to suspend a single device at a time). The only thing that needs checking is whether the device does support remote wakeup. Oh yes, and special handling in case the device is already suspended with wakeup disabled. > > 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. Yes; the same goes for "generic bus" code. Individual drivers shouldn't have much work to do. > 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. If I understand you correctly then no, the first pass has nothing to do with "idle". To implement STD, the PM core would first do a PM_SNAPSHOT double-pass, then create the memory image, then maybe do a resume pass so that the image can be stored, and finally do a PM_SUSPEND_DISK double-pass. The difference between STR and STD _does_ matter to drivers (although maybe only to "bus adapter" code), since it is the drivers who have to decide what device-specific power level is appropriate for STR or STD. That is, the "bus adapter" code gets the new policy (STR or STD or whatever) and decides what the corresponding physical power level and wakeup setting should be. That information is accessible to the children's drivers, so they can ignore the policy value, not make any decisions, and simply implement the physical power level/wakeup setting. > 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 ... ;) I think so too. 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
