Messages in this thread | | | Date | Fri, 17 Feb 2006 22:56:52 -0800 (PST) | From | Patrick Mochel <> | Subject | Re: [PATCH 2/5] [pm] Add state field to pm_message_t (to hold actual state device is in) |
| |
On Fri, 17 Feb 2006, Andrew Morton wrote:
> Would it make sense to enumerate these low-power states, rather than a bare > u32?
The number, name, and meaning of the power states differ on a bus-by-bus basis. PCI has D0-D3, which are well defined by the PCI spec. ACPI defines states of the same name, but less rigidly defined, for various devices. I believe USB has only "on" and "off".
One generality in all buses that I've seen so far consider state '0' to be on and functioning. The low-power states increment from there - the higher the number, the less power is being consumed and the longer it takes to bring the device back to a functioning state. Even buses with 2 states fall into this category, since "on" maps to 0, and "off" maps to anything non-zero.
To answer your question: yes, it would make sense to enumerate the number, but only on a per-bus basis. Ideally, the bus would export the states that it supports, either directly to userspace or via the driver core and the per-device state file in sysfs.
But, we're not to that point yet. For now, the writer of the file needs to know what range of values the bus and/or device is expecting. It would be nice to have a silly little program that could make this easier on a user..
> How, from the above message, is the driver to know that it's being asked > for a low-power state rather than an `off' state? Via `state' I guess.
For PCI drivers at least, each driver's suspend function calls pci_choose_state() to let the PCI core decide what the actual PCI power state is that the device should enter. Before these patches, the PCI core would always return PCI_D3hot on a suspend request. Now, it looks at 'state' and uses that as a hint - if it's set and within range, then it's treated as a PCI D state; otherwise, the driver gets back PCI_D3hot.
> I can see that the kernel would have trouble asking a device to go into a > particular low-power state because of the variation in capabilities between > devices. Perhaps the kernel should send the driver some higher-level piece > of information informing it what's going on, let the driver choose an > appropriate power state?
The kernel only chooses the state on a system suspend transition, and that's exactly what happens - the driver maps a SUSPEND request, regardless of what .state will be to the lowest power state it supports.
However, these patches are for device power transitions initated from sysfs. With these, there is a user/utility/daemon on the other side that knows what power states the device supports and when a good time to enter them is. IOW, it's a policy decision that uses the sysfs interface (and this plumbing) as the mechanism for implementing it.
Pat - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |