On Tue, 2005-03-08 at 09:13 -0800, Patrick Mochel wrote: > This would be doing something like partial-tree suspends, but I'm not sure > if this is best done in the kernel or in userspace with a proper tool. Hrm... I think it's more complex than that. We need 2 way communication between parents & childs. For example, if a parent is informed when a child entered an idle-suspend state (local dynamic PM), it can enter itself into some kind of suspend state when all it's offspring is in such a state (like USB bus suspend when devices are idle, Apple does that afaik, or did that in MacOS 9). But that means child -> parent notifications Also, states tend to be bus specific (PCI D states, USB states, ...) The more I think about it, the more I want to go toward something that looks like what I described a while ago, taht is an array of states in drivers (which also enables us to have driver provide meaningful state names to sysfs, and to have user have something useful to write to "power" entries in sysfs to trigger state transitions). This array would contain the state name, and eventually things like a state enter function (unless we have a single change_state() callback ?) and various infos describing the dependency between local states and bus states (I'm still thinking about the simplest/cleanest way to describe those, probably just a few bitfields with bit numbers matching bus state numbers). A device with "rich" PM features could expose several private state that way, letting the user trigger them via sysfs. One thing to keep in mind is the wakeup condition. With system-wide suspend, it's a system-wide wakeup, while local suspend, it's a local event. In the case described above of the USB bus, it's the child activity that should trigger a resume request upward (and not downward) the tree (thus bi-directional communication in the tree). This is a bit difficult to set properly, but I'm convinced that if we manage to define the model properly and bite the bullet with the implementation issues (like locking), we can expose something that is simple for drivers to use (which is the MAIN issue, or nobody will get anything right). It's also very easy to provide a "default" table match the existing suspend/resume to have existing drivers be compatible "out of the box" with the new scheme. > > A common problem facing all drivers that do auto suspend is how to set > > the inactivity timeout. Two possible answers are: add an attribute > > file in the /sys/.../power directory (so different devices can have > > different timeouts), or add a driver module parameter (so all devices > > using the same driver will have the same timeout). > > It's trickier than that. You want a per-device parameter that can be > adjusted. You also want a per-state parameter so that a device can > gradually enter a deeper and deeper state over time. (You can do it with 1 > timer per device that is set to the timeout value of the next state when > one fires, but that's an implementation issue). We can easily provide "library" functions that do that automatic timer thing for devices. The state array could contain a timeout int for example which when non-0, would enable a timer doing automatic state transition on idle. Of course, it's up to the driver to regulary call a PM core function when it's doing something to reset the timer. I want to avoid having as many system timers as drivers around, this would impact system performances imho (we already have too many timers bcs of things like netfilter afaik). > So, it's bus-specific because it involves the name and number of physical > power states. And, it has a driver-specific component that is adjusted > when the driver is bound to the device. Plus, you also need to make sure, > in the drivers, that you adjust/modify the proper timer values when you > enter a specific device state. > > This is all screaming for a much more complete bus-specific interface to > power management. It seems like the driver core can provide some helpers > and some common interfaces, but since most of the work is bus-specific, it > should be happening in e.g. PCI and USB.. Yes. > > For user suspends (made through sysfs) the user may want to convey > > arbitrary information to a driver, things like which clocks to turn > > off, which power level to change to, and so on. This information > > will vary from driver to driver, and the PM core shouldn't even try to > > impose any sort of structure on it. I think the best approach will be > > to pass to the driver a character pointer giving the data written to > > /sys/.../power/state, so that users can send whatever they want just > > by writing it to the file. This means adding an additional field to > > pm_message_t. > > Uh, that would really suck. This would entail a string parser in every > driver, which is what we wanted to get away from with sysfs. A better way > would be to have a driver export a file with the specific features that it > supports encoded in a meaningful and efficient way (i.e. a fixed-length > string, character, or constant). > What aboout a new IRC meeting to discuss those things ? Ben.
