Lines Matching refs:by
6 management. Based on previous work by Patrick Mochel <mochel@transmeta.com>
27 In general, power management is a feature allowing one to save energy by putting
36 be signaled by the device itself.
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,
45 used by the kernel to change the device's power state.
56 device (e.g. by generating interrupts).
58 In turn, if the methods provided by the platform firmware are used for changing
62 native PCI PM mechanism, because the method provided by the platform depends on
82 (B0-B3). The higher the number, the less power is drawn by the device or bus
86 There are two variants of the D3 state defined by the specification. The first
94 PCI bus power management, however, is not supported by the Linux kernel at the
95 time of this writing and therefore it is not covered by this document.
99 that, if the PCI PM Spec is implemented by the device, it must support D3hot
126 device by hardware just as at initial power up.
141 management interfaces defined by the ACPI standard.
144 methods" that may be executed by the kernel to perform specific tasks, such as
163 into account by ACPI). Moreover, for each power state of a device there is a
171 by the device in this state using their _ON control methods and (2) execute the
174 wakeup signals from that state, the _DSW (or _PSW, replaced with _DSW by ACPI
176 resources that are not required by the device in the target power state and are
177 not required any more by any other device should be disabled (by executing their
186 into and the kernel is supposed to obtain this information by executing the
189 lowest power (highest number) state it can be put into is also determined by the
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
213 read by the kernel.
223 the ACPI S1-S4 states), in which case system wakeup is started by its core logic
237 Unfortunately, there is no standard way of handling wakeup signals sent by
240 a native mechanism for converting native PCI PMEs into interrupts generated by
246 it was possible to introduce a mechanism by which a root port generates an
250 read by the interrupt handler allowing the device to be identified. [PME
251 messages sent by PCI Express endpoints integrated with the Root Complex don't
260 the native PCI Express PME signaling cannot be used by the kernel in that case.
295 These callbacks are executed by the PM core in various situations related to
297 provided by PCI device drivers. They also perform power management operations
334 supported by the device and from which low-power states the device can generate
337 PMEs by the device is disabled.
360 that are executed by the core runtime PM routines. It also implements the
370 run by pci_pm_runtime_suspend() as the first action. If the driver's callback
377 system-dependent and is determined by the PCI subsystem on the basis of the
406 The pci_pm_runtime_idle() function, called for PCI devices by pm_runtime_idle()
410 Sometimes pci_pm_runtime_idle() is called automatically by the PM core (for
414 suspended, so it lets the device's driver decide by running its
452 bridges are ignored by this routine). Next, the device driver's pm->suspend()
480 signaling wakeup is system-dependent and determined by the PCI subsystem, which
489 to signal wakeup and put into a low-power state by the driver (the driver is
490 then assumed to have used the helper functions provided by the PCI subsystem for
517 by drivers whose devices are still suspended). If legacy PCI power management
518 callbacks (see Section 3) are implemented by the device's driver, the legacy
573 the device's standard configuration registers if they haven't been saved by one
627 into memory by a fresh instance of the kernel, called the boot kernel, which in
628 turn is loaded and run by a boot loader in the usual way. After the boot kernel
636 phases described above. However, the devices affected by these phases are only
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
684 not really suitable for any new drivers. Therefore it is not covered by this
688 containing pointers to power management (PM) callbacks that will be executed by
724 low-power state by the PCI subsystem. It is not required (in fact it even is
728 care of by the PCI subsystem, without the driver's participation.
748 after device interrupts have been disabled by the PM core.
779 after device interrupts have been disabled by the PM core.
827 conditions if carried out by resume().
833 device interrupts have been enabled by the PM core.
842 system image has been created and the non-boot CPUs have been enabled by the PM
857 interrupts have been enabled by the PM core.
866 the image kernel and the non-boot CPUs have been enabled by the image kernel's
909 (runtime PM). It is executed by the PM core's runtime PM framework when the
920 by the PM core's runtime PM framework when the device is about to be resumed
925 device after it has been put into the full-power state by the PCI subsystem.
932 by the PM core's runtime PM framework whenever it may be desirable to suspend
949 suspend routine pointed to by the .suspend(), .freeze(), and .poweroff()
950 members and one resume routine pointed to by the .resume(), .thaw(), and
960 dev_pm_ops to indicate that one suspend routine is to be pointed to by the
962 be pointed to by the .resume(), .thaw(), and .restore() members.
982 The runtime PM of PCI devices is enabled by default by the PCI core. PCI
984 However, it is blocked by pci_pm_init() that runs the pm_runtime_forbid()
986 each PCI device is incremented by local_pci_probe() before executing the
987 probe callback provided by the device's driver.
990 runtime PM framework provided by the PM core and the PCI subsystem, it needs
994 way to do that is by calling pm_runtime_put_noidle(), but if the driver
1022 The runtime PM framework works by processing requests to suspend or resume
1025 by work items put into the power management workqueue, pm_wq. Although there
1027 queued by the PM core (for example, after processing a request to resume a
1031 helper functions provided by the PM core, discussed in
1035 request into pm_wq. In the majority of cases this also is done by their
1036 drivers that use helper functions provided by the PM core for this purpose.