Lines Matching refs:PCI
2 PCI Power Management
7 An overview of concepts and the Linux kernel's interfaces related to PCI power
11 This document only covers the aspects of power management specific to PCI
18 1. Hardware and Platform Support for PCI Power Management
19 2. PCI Subsystem and Device Power Management
20 3. PCI Device Drivers and Power Management
24 1. Hardware and Platform Support for PCI Power Management
41 PCI devices may be put into low-power states in two ways, by using the device
42 capabilities introduced by the PCI Bus Power Management Interface Specification,
44 approach, that is referred to as the native PCI power management (native PCI PM)
50 Devices supporting the native PCI PM usually can generate wakeup signals called
53 to put the device that sent it into the full-power state. However, the PCI Bus
57 even though a PCI device is set up to generate PMEs, it also may be necessary to
65 native PCI PM mechanism, because the method provided by the platform depends on
71 1.2. Native PCI Power Management
74 The PCI Bus Power Management Interface Specification (PCI PM Spec) was
75 introduced between the PCI 2.1 and PCI 2.2 Specifications. It defined a
79 The implementation of the PCI PM Spec is optional for conventional PCI devices,
80 but it is mandatory for PCI Express devices. If a device supports the PCI PM
81 Spec, it has an 8 byte power management capability field in its PCI
83 features related to the native PCI power management.
85 The PCI PM Spec defines 4 operating states for devices (D0-D3) and for buses
92 programmed to go into it. The second one, D3cold, is the state that PCI devices
94 to program a PCI device to go into D3cold, although there may be a programmable
98 PCI bus power management, however, is not supported by the Linux kernel at the
101 Note that every PCI device can be in the full-power state (D0) or in D3cold,
102 regardless of whether or not it implements the PCI PM Spec. In addition to
103 that, if the PCI PM Spec is implemented by the device, it must support D3hot
106 PCI devices supporting the PCI PM Spec can be programmed to go to any of the
109 (i.e. the device is required to respond to PCI configuration accesses), although
132 PCI devices supporting the PCI PM Spec can be programmed to generate PMEs
142 The platform firmware support for the power management of PCI devices is
166 labeled as D0, D1, D2, and D3 that roughly correspond to the native PCI PM
203 Wakeup signals generated by PCI devices, either as native PCI PMEs, or as
212 On ACPI-based systems wakeup signals sent by conventional PCI devices are
216 interesting events. In particular, a GPE may be associated with a PCI device
221 If a PCI device known to the system's ACPI BIOS signals wakeup, the GPE
222 associated with it (if there is one) is triggered. The GPEs associated with PCI
225 example, native PCI PMEs from devices unknown to the system's ACPI BIOS may be
239 a PCI device signaling wakeup). The GPEs used for notifying the kernel of
244 conventional PCI devices on systems that are not ACPI-based, but there is one
245 for PCI Express devices. Namely, the PCI Express Base Specification introduced
246 a native mechanism for converting native PCI PMEs into interrupts generated by
247 root ports. For conventional PCI devices native PMEs are out-of-band, so they
249 may be routed directly to the system's core logic), but for PCI Express devices
250 they are in-band messages that have to pass through the PCI Express hierarchy,
254 The PCI Express Requester ID of the device that sent the PME message is then
257 messages sent by PCI Express endpoints integrated with the Root Complex don't
261 In principle the native PCI Express PME signaling may also be used on ACPI-based
266 the native PCI Express PME signaling cannot be used by the kernel in that case.
269 2. PCI Subsystem and Device Power Management
275 The PCI Subsystem participates in the power management of PCI devices in a
277 the device power management core (PM core) and PCI device drivers.
278 Specifically, the pm field of the PCI subsystem's struct bus_type object,
304 provided by PCI device drivers. They also perform power management operations
305 involving some standard configuration registers of PCI devices that device
308 The structure representing a PCI device, struct pci_dev, contains several fields
333 The PCI subsystem's first task related to device power management is to
338 The first of these functions checks if the device supports native PCI PM
341 pci_dev object. Next, the function checks which PCI low-power states are
343 native PCI PMEs. The power management fields of the device's struct pci_dev and
360 The PCI subsystem plays a vital role in the runtime power management of PCI
370 entire mechanics necessary for handling runtime wakeup signals from PCI devices
372 PCI Express PME signaling and the ACPI GPE-based wakeup signaling described in
375 First, a PCI device is put into a low-power state, or suspended, with the help
376 of pm_schedule_suspend() or pm_runtime_suspend() which for PCI devices call
386 system-dependent and is determined by the PCI subsystem on the basis of the
389 PCI subsystem can use the platform firmware as well as the device's native PCI
394 low-power state. The driver ought to leave these tasks to the PCI subsystem
399 pci_pm_runtime_resume() for PCI devices. Again, this only works if the device's
404 callback need not worry about the PCI-specific aspects of the device resume.
412 a notification for the PCI subsystem after the source device has been
415 The pci_pm_runtime_idle() function, called for PCI devices by pm_runtime_idle()
422 however, the PCI subsystem doesn't really know if the device really can be
444 The following PCI bus type's callbacks, respectively, are used in these phases::
456 legacy PCI suspend routines (see Section 3), in which case the driver's legacy
461 pcibios_disable_device() to disable it, unless the device is a bridge (PCI
467 Note that the suspend phase is carried out asynchronously for PCI devices, so
468 the pci_pm_suspend() callback may be executed in parallel for any pair of PCI
475 implements legacy PCI suspends routines (Section 3), in which case the legacy
490 signaling wakeup is system-dependent and determined by the PCI subsystem, which
494 PCI device drivers (that don't implement legacy power management callbacks) are
500 then assumed to have used the helper functions provided by the PCI subsystem for
501 this purpose). PCI device drivers are not encouraged to do that, but in some
513 The following PCI bus type's callbacks, respectively, are executed in these
524 legacy PCI power management callbacks (this way all PCI devices are in the
528 by drivers whose devices are still suspended). If legacy PCI power management
538 device's driver implements legacy PCI power management callbacks (see
544 The resume phase is carried out asynchronously for PCI devices, like the
545 suspend phase described above, which means that if two PCI devices don't depend
566 that correspond to the PCI bus type's callbacks::
578 asynchronously for different PCI devices that don't depend on each other in a
595 using the following PCI bus type's callbacks::
610 asynchronously for different PCI devices that don't depend on each other in a
623 The PCI subsystem-level callbacks they correspond to::
668 described above, respectively, and correspond to the following PCI subsystem
682 3. PCI Device Drivers and Power Management
688 PCI device drivers participate in power management by providing callbacks to be
689 executed by the PCI subsystem's power management routines described above and by
693 callbacks for a PCI device driver, the recommended one, based on using a
701 It is recommended that all PCI device drivers define a struct dev_pm_ops object
703 the PCI subsystem's PM routines in various circumstances. A pointer to the
709 defined (i.e. the respective fields of struct dev_pm_ops are unset) the PCI
740 low-power state by the PCI subsystem. It is not required (in fact it even is
741 not recommended) that a PCI driver's suspend() callback save the standard
744 care of by the PCI subsystem, without the driver's participation.
747 a PCI driver. Then, pci_save_state(), pci_prepare_to_sleep(), and
751 the PCI subsystem will not execute either pci_prepare_to_sleep(), or
818 into a low-power state itself instead of allowing the PCI subsystem to do that,
845 Since the PCI subsystem unconditionally puts all devices into the full power
900 For the vast majority of PCI device drivers there is no difference between
914 For the vast majority of PCI device drivers there is no difference between
945 put into a low-power state, but it must allow the PCI subsystem to perform all
946 of the PCI-specific actions necessary for suspending the device.
957 device after it has been put into the full-power state by the PCI subsystem.
971 PCI subsystem will call pm_runtime_suspend() for the device, which in turn will
1002 including the PCI bus type. The flags should be set once at the driver probe
1012 The DPM_FLAG_SMART_PREPARE flag causes the PCI bus type to return a positive
1018 The DPM_FLAG_SMART_SUSPEND flag tells the PCI bus type that from the driver's
1021 to avoid resuming the device from runtime suspend unless there are PCI-specific
1043 In addition to providing device power management callbacks PCI device drivers
1047 The PCI device runtime PM is optional, but it is recommended that PCI device
1052 To support the PCI runtime PM the driver first needs to implement the
1059 The runtime PM of PCI devices is enabled by default by the PCI core. PCI
1063 each PCI device is incremented by local_pci_probe() before executing the
1066 If a PCI driver implements the runtime PM callbacks and intends to use the
1067 runtime PM framework provided by the PM core and the PCI subsystem, it needs
1122 PCI Local Bus Specification, Rev. 3.0
1124 PCI Bus Power Management Interface Specification, Rev. 1.2
1128 PCI Express Base Specification, Rev. 2.0