Lines Matching refs:PCI

1 PCI Power Management
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
16 1. Hardware and Platform Support for PCI Power Management
17 2. PCI Subsystem and Device Power Management
18 3. PCI Device Drivers and Power Management
22 1. Hardware and Platform Support for PCI Power Management
38 PCI devices may be put into low-power states in two ways, by using the device
39 capabilities introduced by the PCI Bus Power Management Interface Specification,
41 approach, that is referred to as the native PCI power management (native PCI PM)
47 Devices supporting the native PCI PM usually can generate wakeup signals called
50 to put the device that sent it into the full-power state.  However, the PCI Bus
54 even though a PCI device is set up to generate PMEs, it also may be necessary to
62 native PCI PM mechanism, because the method provided by the platform depends on
68 1.2. Native PCI Power Management
70 The PCI Bus Power Management Interface Specification (PCI PM Spec) was
71 introduced between the PCI 2.1 and PCI 2.2 Specifications.  It defined a
75 The implementation of the PCI PM Spec is optional for conventional PCI devices,
76 but it is mandatory for PCI Express devices.  If a device supports the PCI PM
77 Spec, it has an 8 byte power management capability field in its PCI
79 features related to the native PCI power management.
81 The PCI PM Spec defines 4 operating states for devices (D0-D3) and for buses
88 programmed to go into it.  The second one, D3cold, is the state that PCI devices
90 to program a PCI device to go into D3cold, although there may be a programmable
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,
98 regardless of whether or not it implements the PCI PM Spec.  In addition to
99 that, if the PCI PM Spec is implemented by the device, it must support D3hot
102 PCI devices supporting the PCI PM Spec can be programmed to go to any of the
105 (i.e. the device is required to respond to PCI configuration accesses), although
128 PCI devices supporting the PCI PM Spec can be programmed to generate PMEs
137 The platform firmware support for the power management of PCI devices is
161 labeled as D0, D1, D2, and D3 that roughly correspond to the native PCI PM
197 Wakeup signals generated by PCI devices, either as native PCI PMEs, or as
206 On ACPI-based systems wakeup signals sent by conventional PCI devices are
210 interesting events.  In particular, a GPE may be associated with a PCI device
215 If a PCI device known to the system's ACPI BIOS signals wakeup, the GPE
216 associated with it (if there is one) is triggered.  The GPEs associated with PCI
219 example, native PCI PMEs from devices unknown to the system's ACPI BIOS may be
233 a PCI device signaling wakeup).  The GPEs used for notifying the kernel of
238 conventional PCI devices on systems that are not ACPI-based, but there is one
239 for PCI Express devices.  Namely, the PCI Express Base Specification introduced
240 a native mechanism for converting native PCI PMEs into interrupts generated by
241 root ports.  For conventional PCI devices native PMEs are out-of-band, so they
243 may be routed directly to the system's core logic), but for PCI Express devices
244 they are in-band messages that have to pass through the PCI Express hierarchy,
248 The PCI Express Requester ID of the device that sent the PME message is then
251 messages sent by PCI Express endpoints integrated with the Root Complex don't
255 In principle the native PCI Express PME signaling may also be used on ACPI-based
260 the native PCI Express PME signaling cannot be used by the kernel in that case.
263 2. PCI Subsystem and Device Power Management
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.
271 Specifically, the pm field of the PCI subsystem's struct bus_type object,
297 provided by PCI device drivers.  They also perform power management operations
298 involving some standard configuration registers of PCI devices that device
301 The structure representing a PCI device, struct pci_dev, contains several fields
325 The PCI subsystem's first task related to device power management is to
330 The first of these functions checks if the device supports native PCI PM
333 pci_dev object.  Next, the function checks which PCI low-power states are
335 native PCI PMEs.  The power management fields of the device's struct pci_dev and
351 The PCI subsystem plays a vital role in the runtime power management of PCI
361 entire mechanics necessary for handling runtime wakeup signals from PCI devices
363 PCI Express PME signaling and the ACPI GPE-based wakeup signaling described in
366 First, a PCI device is put into a low-power state, or suspended, with the help
367 of pm_schedule_suspend() or pm_runtime_suspend() which for PCI devices call
377 system-dependent and is determined by the PCI subsystem on the basis of the
380 PCI subsystem can use the platform firmware as well as the device's native PCI
385 low-power state.  The driver ought to leave these tasks to the PCI subsystem
390 pci_pm_runtime_resume() for PCI devices.  Again, this only works if the device's
395 callback need not worry about the PCI-specific aspects of the device resume.
403 a notification for the PCI subsystem after the source device has been
406 The pci_pm_runtime_idle() function, called for PCI devices by pm_runtime_idle()
413 however, the PCI subsystem doesn't really know if the device really can be
434 The following PCI bus type's callbacks, respectively, are used in these phases:
446 legacy PCI suspend routines (see Section 3), in which case the driver's legacy
451 pcibios_disable_device() to disable it, unless the device is a bridge (PCI
457 Note that the suspend phase is carried out asynchronously for PCI devices, so
458 the pci_pm_suspend() callback may be executed in parallel for any pair of PCI
465 implements legacy PCI suspends routines (Section 3), in which case the legacy
480 signaling wakeup is system-dependent and determined by the PCI subsystem, which
484 PCI device drivers (that don't implement legacy power management callbacks) are
490 then assumed to have used the helper functions provided by the PCI subsystem for
491 this purpose).  PCI device drivers are not encouraged to do that, but in some
502 The following PCI bus type's callbacks, respectively, are executed in these
513 legacy PCI power management callbacks (this way all PCI devices are in the
517 by drivers whose devices are still suspended).  If legacy PCI power management
527 device's driver implements legacy PCI power management callbacks (see
533 The resume phase is carried out asynchronously for PCI devices, like the
534 suspend phase described above, which means that if two PCI devices don't depend
554 that correspond to the PCI bus type's callbacks:
566 asynchronously for different PCI devices that don't depend on each other in a
583 using the following PCI bus type's callbacks:
598 asynchronously for different PCI devices that don't depend on each other in a
611 The PCI subsystem-level callbacks they correspond to
655 described above, respectively, and correspond to the following PCI subsystem
669 3. PCI Device Drivers and Power Management
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
679 callbacks for a PCI device driver, the recommended one, based on using a
687 It is recommended that all PCI device drivers define a struct dev_pm_ops object
689 the PCI subsystem's PM routines in various circumstances.  A pointer to the
695 defined (i.e. the respective fields of struct dev_pm_ops are unset) the PCI
724 low-power state by the PCI subsystem.  It is not required (in fact it even is
725 not recommended) that a PCI driver's suspend() callback save the standard
728 care of by the PCI subsystem, without the driver's participation.
731 a PCI driver.  Then, pci_save_state(), pci_prepare_to_sleep(), and
735 the PCI subsystem will not execute either pci_prepare_to_sleep(), or
798 into a low-power state itself instead of allowing the PCI subsystem to do that,
823 Since the PCI subsystem unconditionally puts all devices into the full power
874 For the vast majority of PCI device drivers there is no difference between
887 For the vast majority of PCI device drivers there is no difference between
914 put into a low-power state, but it must allow the PCI subsystem to perform all
915 of the PCI-specific actions necessary for suspending the device.
925 device after it has been put into the full-power state by the PCI subsystem.
938 PCI subsystem will call pm_runtime_suspend() for the device, which in turn will
966 In addition to providing device power management callbacks PCI device drivers
970 The PCI device runtime PM is optional, but it is recommended that PCI device
975 To support the PCI runtime PM the driver first needs to implement the
982 The runtime PM of PCI devices is enabled by default by the PCI core.  PCI
986 each PCI device is incremented by local_pci_probe() before executing the
989 If a PCI driver implements the runtime PM callbacks and intends to use the
990 runtime PM framework provided by the PM core and the PCI subsystem, it needs
1045 PCI Local Bus Specification, Rev. 3.0
1046 PCI Bus Power Management Interface Specification, Rev. 1.2
1048 PCI Express Base Specification, Rev. 2.0