Documentation/power/pci.rst

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
65 native PCI PM mechanism, because the method provided by the platform depends on
74 The PCI Bus Power Management Interface Specification (PCI PM Spec) was
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
85 The PCI PM Spec defines 4 operating states for devices (D0-D3) and for buses
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
132 PCI devices supporting the PCI PM Spec can be programmed to generate PMEs
166 labeled as D0, D1, D2, and D3 that roughly correspond to the native PCI PM
277 the device power management core (PM core) and PCI device drivers.
302 These callbacks are executed by the PM core in various situations related to
314 	int		pm_cap;		/* PM capability offset in the
338 The first of these functions checks if the device supports native PCI PM
362 (runtime PM) framework described in Documentation/power/runtime_pm.rst.
369 that are executed by the core runtime PM routines.  It also implements the
390 PM capabilities, if supported.
419 Sometimes pci_pm_runtime_idle() is called automatically by the PM core (for
430 handled in a specific way and the PM core executes subsystem-level power
489 state.  Just like in the runtime PM case described above, the mechanism of
702 containing pointers to power management (PM) callbacks that will be executed by
703 the PCI subsystem's PM routines in various circumstances.  A pointer to the
705 its struct pci_driver object.  Once that has happened, the "legacy" PM callbacks
708 The PM callbacks in struct dev_pm_ops are not mandatory and if they are not
765 after device interrupts have been disabled by the PM core.
798 after device interrupts have been disabled by the PM core.
841 PM core has enabled the non-boot CPUs.  The driver's interrupt handler will not
856 device interrupts have been enabled by the PM core.
866 system image has been created and the non-boot CPUs have been enabled by the PM
882 interrupts have been enabled by the PM core.
893 PM core.
908 after the PM core has enabled device drivers' interrupt handlers to be invoked.
940 (runtime PM).  It is executed by the PM core's runtime PM framework when the
951 The runtime_resume() callback is specific to device runtime PM.  It is executed
952 by the PM core's runtime PM framework when the device is about to be resumed
964 The runtime_idle() callback is specific to device runtime PM.  It is executed
965 by the PM core's runtime PM framework whenever it may be desirable to suspend
966 the device according to the PM core's information.  In particular, it is
1000 The PM core allows device drivers to set flags that influence the handling of
1006 The DPM_FLAG_NO_DIRECT_COMPLETE flag prevents the PM core from using the
1026 pci_pm_restore_noirq(), its runtime PM status will be changed to "active" (as it
1032 taken into consideration by the PM core along with the power.may_skip_resume
1034 situations.  If the PM core determines that the driver's "noirq" and "early"
1044 are responsible for controlling the runtime power management (runtime PM) of
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
1062 helper function.  In addition to that, the runtime PM usage counter of
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
1068 to decrement the device's runtime PM usage counter in its probe callback
1075 from its probe routine to make runtime PM work for the device.
1080 unblocking the runtime PM of the device to run via sysfs, so the driver must
1086 runtime PM of the device correctly as soon as pm_runtime_allow() is called
1090 of the device's runtime PM usage counter at the probe time.  For this reason,
1094 before running the driver's remove callback, the runtime PM of the device
1096 runtime PM helper functions incrementing the device's usage counter are
1099 The runtime PM framework works by processing requests to suspend or resume
1104 queued by the PM core (for example, after processing a request to resume a
1105 device the PM core automatically queues a request to check if the device is
1107 requests for their devices.  For this purpose they should use the runtime PM
1108 helper functions provided by the PM core, discussed in
1113 drivers that use helper functions provided by the PM core for this purpose.
1115 For more information on the runtime PM of devices refer to