On Wed, 2005-03-09 at 17:24 +1100, Nigel Cunningham wrote: > Hi. > > > > > > 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). > > > > > > > > Each class could have its own policies, complete with timeout values. In > > > > sysfs, the user could select which policy should be used. (e.g. performance, > > > > normal, powersave). > > > > > > I like the per-instance idea better. If I have, for example, two > > > harddrives on the same bus, I might have very different usage patterns > > > for them. I might want one to spend most of it's time powered down, and > > > the other to be always on. > > > > I'm sorry I wasn't clear on this. I also want the settings to be > > per-instance, not per class. I think that power management policy is a > > class level issue, however. In other words, a class could provide an > > array of policies, and each device could individually be assigned one. > > Ah okay. So we have a combination of possible settings in the class, > masked by the capabilities of the driver and the policy settings for the > individual instance to determine what transitions occur for the > instance? Yeah, I had something like that in mind. > > > > > > > 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). > > > > > > > > Agreed. > > > > > > <heresy> I wonder if using sysfs is even the best method for doing > > > run-time PM. It will force your imaginary nice userspace interface to > > > include code to scan the whole directory tree looking for files of each > > > kind, perhaps sorting and collating and so on. Maybe a DBus interface > > > would be better? </heresy> > > > > So a request for suspending a device would be sent through the netlink > > socket? Could you provide a few more details on the alternative? > > I don't understand much about DBus yet - I'm just beginning to think > about learning it :>. That said, I'd imagine the answer to your question > would be yes. I wouldn't imagine all the transitions being notified > through it (CPU freq changes being a candidate for exclusion for > example), but I would imagine it being used to enumerate devices and > capabilites and set policies. [Which reminds me... I didn't get around > to replying in another thread where I talked about this last week]. So would it be mostly a control mechanism for devices, or would it provide attributes about the device too? Another thing that I have been wanting to do for a long time is to control which drivers are bound to which devices through userspace. (modprobe isn't enough, the actual device to driver binding is what is important) It seems to be difficult in sysfs. > > > > > Another concern I had is how to relate power states between devices. The > > > > most standard format seems to be D*, as it is used by PCI, ACPI, and others. > > > > It's not uncommon for a child device to require the parent to be in a > > > > given state for wake events etc. If the child isn't using the same names > > > > for power states, then how could this be possible? Also how could a class > > > > level policy interact with devices that use different state names? I may > > > > be in favor of only using D-states. > > > > > > > > Finally, I'm not sure if I like the current "*probe", "*remove", "*suspend", > > > > and "*resume" for runtime power management. I think it may be better to do > > > > something like the following: > > > > > > > > *attach - allocates data structures, creates sysfs entries, prepares driver > > > > to handle the hardware. > > > > > > > > *start - Sets up device resources and configures the hardware. > > > > (mostly physical) > > > > > > > > *open - engages the hardware, and allows the class to use it. > > > > (logical and physical) > > > > > > > > *close - disengages the hardware, and stops access > > > > (logical and physical) > > > > > > > > *stop - disables the hardware at a physical level > > > > (mostly physical) > > > > > > > > *detach - tears down the driver and releases it from the "struct device" > > > > > > > > *power - A function that saves and restores states and transitions power > > > > - It could take the current state and the new state as arguments. > > > > > > > > > > > > The idea here is that if a device could be put into a lower state in which > > > > it isn't operational, but still maintains configuration, then we could just > > > > use "close" and "open". For complete poweroffs we could do: A few more thoughts. We could do something like this at the class level: *attach - allocates data structures, creates sysfs entries, prepares driver to handle the hardware *start - start the logical class device, accept userspace interaction *stop - stop the logical class device, deny userspace interaction *detach - tear down the class driver's bindings with this class device . So the basic flow when the device is first bound would be like this: device->attach (class device is created here) class->attach device->start (a class device could also be created here if dynamic) device->open class->start and on suspend: class->stop device->close device->stop and on resume: device->start device->open class->start and for runtime power management with device configuration maintained: * class-level policy decides to put the device in a light sleep device->close device->power * power state is changed by bus level * activity counter is hit, request availability from physical level * power state is brought to D0 by bus level device->power device->open * and so it continues... * during this time the class device is never stopped and for runtime power management where device is turned off: * class-level policy decides to put the device in a light sleep device->close device->power * power state is changed by bus level * no activity, next timer expires, time for a lower state device->power * power state is brought down further by bus level device->stop * activity detected, bring back up * power state is changed by bus level device->power device->start device->open * and so it continues... * during this time the class device is never stopped I like this because there is greater separation between logical and physical concepts. It's a more layered design, and should allow for us to do more advanced things with power management without making each device driver extremely complex. > > > > > > I would argue that even for a complete poweroff, the device should > > > maintain it's configuration (in normal memory), assuming that here you > > > mean details like IRQ usage. > > > > The driver will be aware of the configuration from normal memory, but > > the values have to be set again in the hardware. For example, firmware > > for ipw2200 would have to be reloaded after a poweroff. Also, with more > > advanced resource management, assignments may change (rebalancing etc). > > The device doesn't retain anything the driver has told it before the > > poweroff. > > Yeah. I'm meaning (sorry for my lack of clarity) that the driver should > maintain those details, reload the firmware and so on. I would see > rebalancing as a separate issue, that takes place after we've done the > resume. I think the device's resources could be released while it's powered down, to make room for other devices. And then when it's powered up they can be reassigned. BIOS configured devices should probably keep their original configuration. Others can change after a resume. Thanks, Adam
