On Mon, 21 Mar 2005, Alan Stern wrote: > Here are a couple of issues I want to raise before the next IRC session. > > > Nested suspends: We know that the PM core tries to avoid increasing a > device's suspend level (i.e., FREEZE -> SUSPEND) as part of a system > sleep. However... The core won't have a very good idea of a device's > initial state, and a device may already be suspended when the system sleep > begins. We have decided that devices' power states are represented by > pointers to structures defined at the bus or device level; the PM core > won't know how to interpret them. So it won't know whether a device is > already suspended. I think the core should always call ->suspend() for a device, regardless of whether it thinks it's in a low power state, or inactive. This is specifically for the reason that a device could be a low-power runtime state when the system is suspended. To assist this, there should probably be only 1 list to hold the PM nodes, making the code a lot simpler. > There's also the possibility that as part of runtime power management, a > user might tell an already-suspended device to go to a different, but > still suspended, power state. The core can't filter out such requests > because it doesn't understand the states. It's not even clear that such > requests _should_ be filtered out. PM-aware PCI devices, for example, > have no trouble moving from D1 to D2. Agree. > Another way to handle this is to include a generic "low power" flag as a > standard part of the new power-state structures. That way the core would > at least know whether a device was at full power. (Maybe include a > "quiescent" flag too, since some devices can be operational while at low > power.) While this isn't a bad idea, I rather favor the other approach. > of course we can always do both. I don't think the core needs to know. It shouldn't care when traversing the lists what state a device is in. > Messages vs. states: At the moment the PM core seems to be pretty > confused over this distinction. Right in the definition of struct > dev_pm_info we have: > > pm_message_t power_state; > > Obviously a message isn't the same thing as a state. This looks like > something that will need to be changed in a lot of drivers when we > introduce the new notion of a power state. > > As a corollary we have the problem of what to include in the argument > passed to a suspend callback. It should be a message, clearly, and > part of the message should be an indication of which state to go to. The > question is, how is this state represented? For device power management > we will want to provide a genuine power state (i.e., pointer to bus- or > device-specific structure). For system power management we will want to > provide a generic code -- PMSG_ON, PMSG_FREEZE, or PMSG_SUSPEND -- which > the driver will map to a real power state. The system state transitions should be mediated through the bus driver. The bus should then translate it and call the driver, which will then map it back to a device-specific state (optionally using some bus helpers). We've talked about this before; I think David, Ben and I have all proposed something like this. Are you suggesting something different? For runtime states, I think the bus should be the one exporting PM control files through sysfs, not the driver core. It will handle the display and setting of power states, allowing it to show userspace states that actually mean something, rather than just arbitrary numbers that don't map to every bus. [ To show these states, the bus should use a per-device array of states that is filled in by the driver. This could easily include device-specific states that the driver includes in the array. ] Pat
