RFC: PCI Power Management Documentation
I've rewritten the PCI Power Management documentation that I was going to submit to Linus. I figured I would submit it here to get some proactive feedback on it. My thought was to create a Documentation/power/ directory with various documents describing the way that the kernel implements power management, as well as the interfaces for implementing it at both a system-wide and driver level. Comments gladly welcomed. -pat PCI Power Management An overview of the concepts and the related functions in the Linux kernel Patrick Mochel <[EMAIL PROTECTED]> --- 1. Overview 2. How the PCI Subsystem Does Power Management 3. PCI Utility Functions 4. PCI Device Drivers 5. Resources 1. Overview ~~~ The PCI Power Management Specification was introduced between the PCI 2.1 and PCI 2.2 Specifications. It a standard interface for controlling various power management operations. Implementation of the PCI PM Spec is optional, as are several sub-components of it. If a device supports the PCI PM Spec, the device will have an 8 byte capability field in its PCI configuration space. This field is used to describe and control the standard PCI power management features. The PCI PM spec defines 4 operating states for devices (D0 - D3) and for buses (B0 - B3). The higher the number, the less power the device consumes. However, the higher the number, the longer the latency is for the device to return to an operational state (D0). Bus power management is not covered in this version of this document. Note that all PCI devices support D0 and D3 by default, regardless of whether or not they implement any of the PCI PM spec. The possible state transitions that a device can undergo are: +---+ | Current State | New State | +---+ | D0| D1, D2, D3| +---+ | D1| D2, D3| +---+ | D2| D3| +---+ | D1, D2, D3| D0| +---+ Note that when the system is entering a global suspend state, all devices will be placed into D3 and when resuming, all devices will be placed into D0. However, when the system is running, other state transitions are possible. 2. How The PCI Subsystem Handles Power Management ~ The PCI suspend/resume functionality is accessed indirectly via the Power Management subsystem. At boot, the PCI driver registers a power management callback with that layer. Upon entering a suspend state, the PM layer iterates through all of its registered callbacks. This currently takes place only during APM state transitions. Upon going to sleep, the PCI subsystem walks its device tree twice. Both times, it does a depth first walk of the device tree. The first walk saves each of the device's state and checks for devices that will prevent the system from entering a global power state. The next walk then places the devices in a low power state. The first walk allows a graceful recovery in the event of a failure, since none of the devices have actually been powered down. In both walks, in particular the second, all children of a bridge are touched before the actual bridge itself. This allows the bridge to retain power while its children are being accessed. Upon resuming from sleep, just the opposite must be true: all bridges must be powered on and restored before their children are powered on. This is easily accomplished with a breadth-first walk of the PCI device tree. 3. PCI Utility Functions These are helper functions designed to be called by individual device drivers. Assuming that a device behaves as advertised, these should be applicable in most cases. However, results may vary. Note that these functions are never implicitly called for the driver. The driver is always responsible for deciding when and if to call these. pci_save_state -- Usage: pci_save_state(dev, buffer); Description: Save first 64 bytes of PCI config space. Buffer must be allocated by caller. pci_restore_state - Usage: pci_restore_state(dev,buffer); Description: Restore previously saved config space. (First 64 bytes only); If buffer is NULL, then restore what information we know about the device from bootup: BARs and interrupt line. pci_set_power_state --- Usage: pci_set_power_state(dev,state); Description: Transition device to low power state using PCI PM Capabilities registers. Will fail under one of the following conditions: - If state is less than current state, but not D0 (illegal transition) - Device doesn't support PM Capabilities - Device does not support requested state pci_enable_wake ---
RFC: PCI Power Management Documentation
I've rewritten the PCI Power Management documentation that I was going to submit to Linus. I figured I would submit it here to get some proactive feedback on it. My thought was to create a Documentation/power/ directory with various documents describing the way that the kernel implements power management, as well as the interfaces for implementing it at both a system-wide and driver level. Comments gladly welcomed. -pat PCI Power Management An overview of the concepts and the related functions in the Linux kernel Patrick Mochel [EMAIL PROTECTED] --- 1. Overview 2. How the PCI Subsystem Does Power Management 3. PCI Utility Functions 4. PCI Device Drivers 5. Resources 1. Overview ~~~ The PCI Power Management Specification was introduced between the PCI 2.1 and PCI 2.2 Specifications. It a standard interface for controlling various power management operations. Implementation of the PCI PM Spec is optional, as are several sub-components of it. If a device supports the PCI PM Spec, the device will have an 8 byte capability field in its PCI configuration space. This field is used to describe and control the standard PCI power management features. The PCI PM spec defines 4 operating states for devices (D0 - D3) and for buses (B0 - B3). The higher the number, the less power the device consumes. However, the higher the number, the longer the latency is for the device to return to an operational state (D0). Bus power management is not covered in this version of this document. Note that all PCI devices support D0 and D3 by default, regardless of whether or not they implement any of the PCI PM spec. The possible state transitions that a device can undergo are: +---+ | Current State | New State | +---+ | D0| D1, D2, D3| +---+ | D1| D2, D3| +---+ | D2| D3| +---+ | D1, D2, D3| D0| +---+ Note that when the system is entering a global suspend state, all devices will be placed into D3 and when resuming, all devices will be placed into D0. However, when the system is running, other state transitions are possible. 2. How The PCI Subsystem Handles Power Management ~ The PCI suspend/resume functionality is accessed indirectly via the Power Management subsystem. At boot, the PCI driver registers a power management callback with that layer. Upon entering a suspend state, the PM layer iterates through all of its registered callbacks. This currently takes place only during APM state transitions. Upon going to sleep, the PCI subsystem walks its device tree twice. Both times, it does a depth first walk of the device tree. The first walk saves each of the device's state and checks for devices that will prevent the system from entering a global power state. The next walk then places the devices in a low power state. The first walk allows a graceful recovery in the event of a failure, since none of the devices have actually been powered down. In both walks, in particular the second, all children of a bridge are touched before the actual bridge itself. This allows the bridge to retain power while its children are being accessed. Upon resuming from sleep, just the opposite must be true: all bridges must be powered on and restored before their children are powered on. This is easily accomplished with a breadth-first walk of the PCI device tree. 3. PCI Utility Functions These are helper functions designed to be called by individual device drivers. Assuming that a device behaves as advertised, these should be applicable in most cases. However, results may vary. Note that these functions are never implicitly called for the driver. The driver is always responsible for deciding when and if to call these. pci_save_state -- Usage: pci_save_state(dev, buffer); Description: Save first 64 bytes of PCI config space. Buffer must be allocated by caller. pci_restore_state - Usage: pci_restore_state(dev,buffer); Description: Restore previously saved config space. (First 64 bytes only); If buffer is NULL, then restore what information we know about the device from bootup: BARs and interrupt line. pci_set_power_state --- Usage: pci_set_power_state(dev,state); Description: Transition device to low power state using PCI PM Capabilities registers. Will fail under one of the following conditions: - If state is less than current state, but not D0 (illegal transition) - Device doesn't support PM Capabilities - Device does not support requested state pci_enable_wake ---
