Lines Matching refs:power

5 An overview of concepts and the Linux kernel's interfaces related to PCI power
9 This document only covers the aspects of power management specific to PCI
11 power management refer to Documentation/power/devices.txt and
12 Documentation/power/runtime_pm.txt.
27 In general, power management is a feature allowing one to save energy by putting
28 devices into states in which they draw less power (low-power states) at the
31 Usually, a device is put into a low-power state when it is underutilized or
33 again, it has to be put back into the "fully functional" state (full-power
38 PCI devices may be put into low-power states in two ways, by using the device
41 approach, that is referred to as the native PCI power management (native PCI PM)
42 in what follows, the device power state is changed as a result of writing a
45 used by the kernel to change the device's power state.
50 to put the device that sent it into the full-power state.  However, the PCI Bus
59 the power state of a device, usually the platform also provides a method for
65 Thus in many situations both the native and the platform-based power management
72 standard interface for performing various operations related to power
77 Spec, it has an 8 byte power management capability field in its PCI
79 features related to the native PCI power management.
82 (B0-B3).  The higher the number, the less power is drawn by the device or bus
84 the device or bus to return to the full-power state (D0 or B0, respectively).
94 PCI bus power management, however, is not supported by the Linux kernel at the
97 Note that every PCI device can be in the full-power state (D0) or in D3cold,
100 as well as D0.  The support for the D1 and D2 power states is optional.
103 supported low-power states (except for D3cold).  While in D1-D3hot the
108 forth between D0 and the supported low-power states (except for D3cold) and the
109 possible power state transitions the device can undergo are the following:
124 the device (i.e. power is restored).  In that case the device returns to D0 with
125 a full power-on reset sequence and the power-on defaults are restored to the
126 device by hardware just as at initial power up.
129 while in a low-power state (D1-D3), but they are not required to be capable
130 of generating PMEs from all supported low-power states.  In particular, the
137 The platform firmware support for the power management of PCI devices is
140 majority of x86-based systems, it is supposed to implement device power
145 putting a device into a low-power state.  These control methods are encoded
158 ACPI methods used for device power management fall into that category.
160 The ACPI specification assumes that devices can be in one of four power states
163 into account by ACPI).  Moreover, for each power state of a device there is a
164 set of power resources that have to be enabled for the device to be put into
165 that state.  These power resources are controlled (i.e. enabled or disabled)
169 To put a device into the ACPI power state Dx (where x is a number between 0 and
170 3 inclusive) the kernel is supposed to (1) enable the power resources required
173 is going to be put into a low-power state (D1-D3) and is supposed to generate
176 resources that are not required by the device in the target power state and are
178 _OFF control methods).  If the current power state of the device is D3, it can
181 However, quite often the power states of devices are changed during a
185 determines the highest power (lowest number) state the device can be put
189 lowest power (highest number) state it can be put into is also determined by the
192 use the device's _PRW control method to learn which power resources need to be
199 putting the device into a low-power state, have to be caught and handled as
202 put the devices generating them into the full-power state and take care of the
268 The PCI Subsystem participates in the power management of PCI devices in a
270 the device power management core (PM core) and PCI device drivers.
273 pointers to several device power management callbacks:
296 device power management and they, in turn, execute power management callbacks
297 provided by PCI device drivers.  They also perform power management operations
312 	unsigned int	d1_support:1;	/* Low power state D1 is supported */
313 	unsigned int	d2_support:1;	/* Low power state D2 is supported */
325 The PCI subsystem's first task related to device power management is to
326 prepare the device for power management and initialize the fields of struct
331 and if that's the case the offset of its power management capability structure
333 pci_dev object.  Next, the function checks which PCI low-power states are
334 supported by the device and from which low-power states the device can generate
335 native PCI PMEs.  The power management fields of the device's struct pci_dev and
345 At this point the device is ready for power management.  For driverless devices,
351 The PCI subsystem plays a vital role in the runtime power management of PCI
352 devices.  For this purpose it uses the general runtime power management
353 (runtime PM) framework described in Documentation/power/runtime_pm.txt.
362 in low-power states, which at the time of this writing works for both the native
366 First, a PCI device is put into a low-power state, or suspended, with the help
373 the target low-power state.
375 The low-power state to put the device into is the lowest-power (highest number)
379 device for signaling wakeup and put it into the selected low-power state, the
385 low-power state.  The driver ought to leave these tasks to the PCI subsystem
393 back into the full-power state, prevents it from signaling wakeup while in that
419 There are a few different types of system-wide power transitions, described in
420 Documentation/power/devices.txt.  Each of them requires devices to be handled
421 in a specific way and the PM core executes subsystem-level power management
475 a low-power state.
477 The low-power state to put the device into is the lowest-power (highest number)
484 PCI device drivers (that don't implement legacy power management callbacks) are
486 into low-power states.  However, if one of the driver's suspend callbacks
489 to signal wakeup and put into a low-power state by the driver (the driver is
509 The pci_pm_resume_noirq() routine first puts the device into the full-power
513 legacy PCI power management callbacks (this way all PCI devices are in the
514 full-power state and their standard configuration registers have been restored
517 by drivers whose devices are still suspended).  If legacy PCI power management
527 device's driver implements legacy PCI power management callbacks (see
572 device for signaling wakeup and put it into a low-power state.  Still, it saves
592 but it doesn't put the device into the full power state and doesn't attempt to
626 As described in Documentation/power/devices.txt, the hibernation image is loaded
674 PCI device drivers participate in power management by providing callbacks to be
675 executed by the PCI subsystem's power management routines described above and by
676 controlling the runtime power management of their devices.
678 At the time of this writing there are two ways to define power management
680 dev_pm_ops structure described in Documentation/power/devices.txt, and the
683 however, doesn't allow one to define runtime power management callbacks and is
688 containing pointers to power management (PM) callbacks that will be executed by
703 (when a hibernation image is about to be created), during power-off after
716 in Documentation/power/notifiers.txt).
724 low-power state by the PCI subsystem.  It is not required (in fact it even is
727 put it into a low-power state.  All of these operations can very well be taken
734 low-power state, respectively.  Moreover, if the driver calls pci_save_state(),
765 the driver takes the responsibility for putting the device into a low-power
769 or put it into a low-power state.  Still, either it or freeze_noirq() should
798 into a low-power state itself instead of allowing the PCI subsystem to do that,
801 into a low-power state, respectively, but it need not save the device's standard
823 Since the PCI subsystem unconditionally puts all devices into the full power
908 The runtime_suspend() callback is specific to device runtime power management
910 device is about to be suspended (i.e. quiesced and put into a low-power state)
914 put into a low-power state, but it must allow the PCI subsystem to perform all
921 (i.e. put into the full-power state and programmed to process I/O normally) at
925 device after it has been put into the full-power state by the PCI subsystem.
966 In addition to providing device power management callbacks PCI device drivers
967 are responsible for controlling the runtime power management (runtime PM) of
1000 by work items put into the power management workqueue, pm_wq.  Although there
1001 are a few situations in which power management requests are automatically
1004 idle), device drivers are generally responsible for queuing power management
1007 Documentation/power/runtime_pm.txt.
1014 Documentation/power/runtime_pm.txt.
1024 Documentation/power/devices.txt
1025 Documentation/power/runtime_pm.txt