Lines Matching refs:in
28 devices into states in which they draw less power (low-power states) at the
38 PCI devices may be put into low-power states in two ways, by using the device
42 in what follows, the device power state is changed as a result of writing a
65 Thus in many situations both the native and the platform-based power management
77 Spec, it has an 8 byte power management capability field in its PCI
83 in that state. However, the higher the number, the longer the latency for
89 are in when the supply voltage (Vcc) is removed from them. It is not possible
91 interface for putting the bus the device is on into a state in which Vcc is
97 Note that every PCI device can be in the full-power state (D0) or in D3cold,
103 supported low-power states (except for D3cold). While in D1-D3hot the
129 while in a low-power state (D1-D3), but they are not required to be capable
138 system-specific. However, if the system in question is compliant with the
147 stored in the machine's BIOS. The kernel loads them from the BIOS and executes
149 computations and memory or I/O space accesses. This way, in theory, a BIOS
151 on the system design in a system-specific fashion.
156 the platform. This means, in particular, that ACPI device control methods can
157 only be used to handle devices that the BIOS writer knew about in advance. The
160 The ACPI specification assumes that devices can be in one of four power states
171 by the device in this state using their _ON control methods and (2) execute the
176 resources that are not required by the device in the target power state and are
200 appropriate. If they are sent while the system is in the working state
208 from the system core logic generated in response to various events that need to
212 and event sources is recorded in the system's ACPI BIOS from where it can be
217 bridges may also be triggered in response to a wakeup signal from one of the
222 A GPE may be triggered when the system is sleeping (i.e. when it is in one of
223 the ACPI S1-S4 states), in which case system wakeup is started by its core logic
225 may be identified later). The GPEs used in such situations are referred to as
228 Usually, however, GPEs are also triggered when the system is in the working
229 state (ACPI S0) and in that case the system's core logic generates a System
232 in turn, allows the kernel to identify the source of the event (that may be
234 events occurring while the system is in the working state are referred to as
242 are routed separately and they need not pass through bridges (in principle they
244 they are in-band messages that have to pass through the PCI Express hierarchy,
249 recorded in one of the root port's configuration registers from where it may be
260 the native PCI Express PME signaling cannot be used by the kernel in that case.
268 The PCI Subsystem participates in the power management of PCI devices in a
295 These callbacks are executed by the PM core in various situations related to
296 device power management and they, in turn, execute power management callbacks
307 int pm_cap; /* PM capability offset in the
316 unsigned int d3_delay; /* D3->D0 transition time in ms */
320 They also indirectly use some fields of the struct device that is embedded in
327 pci_dev used for this purpose. This happens in two functions defined in
332 in the configuration space is stored in the pm_cap field of the device's struct
336 the struct device embedded in it are updated accordingly and the generation of
341 the function updates the wakeup fields in struct device embedded in the
351 The PCI subsystem plays a vital role in the runtime power management of PCI
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
363 PCI Express PME signaling and the ACPI GPE-based wakeup signaling described in
393 back into the full-power state, prevents it from signaling wakeup while in that
397 Note that generally pci_pm_runtime_resume() may be called in two different
402 is handled in one of the ways described in Section 1 and finally converted into
411 example, it is called right after the device has just been resumed), in which
419 There are a few different types of system-wide power transitions, described in
421 in a specific way and the PM core executes subsystem-level power management
422 callbacks for this purpose. They are executed in phases such that each phase
429 When the system is going into a sleep state in which the contents of memory will
434 The following PCI bus type's callbacks, respectively, are used in these phases:
443 dev_pm_ops object is present and the prepare pointer in that object is valid).
446 legacy PCI suspend routines (see Section 3), in which case the driver's legacy
458 the pci_pm_suspend() callback may be executed in parallel for any pair of PCI
459 devices that don't depend on each other in a known way (i.e. none of the paths
460 in the device tree from the root bridge to a leaf device contains both of them).
465 implements legacy PCI suspends routines (Section 3), in which case the legacy
478 state from which it can signal wakeup while the system is in the target sleep
479 state. Just like in the runtime PM case described above, the mechanism of
491 this purpose). PCI device drivers are not encouraged to do that, but in some
492 rare cases doing that in the driver may be the optimum approach.
496 When the system is undergoing a transition from a sleep state in which the
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
525 only is necessary in the error path during a failing suspend). Next, resume
535 on each other in a known way, the pci_pm_resume() routine may be executed for
536 the both of them in parallel.
550 to be free) in the following three phases:
566 asynchronously for different PCI devices that don't depend on each other in a
569 The pci_pm_freeze_noirq() routine, in turn, is similar to
579 back to the fully functional state and this is done in the following phases:
598 asynchronously for different PCI devices that don't depend on each other in a
604 enter the target sleep state (ACPI S4 for ACPI-based systems). This is done in
616 work in analogy with pci_pm_suspend() and pci_pm_poweroff_noirq(), respectively,
626 As described in Documentation/power/devices.txt, the hibernation image is loaded
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
632 the image during hibernation, in the
637 those having drivers in the boot kernel; other devices will still be in whatever
643 drivers in the boot kernel), and then continue running normally.
661 These callbacks work in analogy with pci_pm_resume_noirq() and pci_pm_resume(),
665 The complete phase is carried out in exactly the same way as during system
674 PCI device drivers participate in power management by providing callbacks to be
680 dev_pm_ops structure described in Documentation/power/devices.txt, and the
681 "legacy" one, in which the .suspend(), .suspend_late(), .resume_early(), and
689 the PCI subsystem's PM routines in various circumstances. A pointer to the
690 driver's struct dev_pm_ops object has to be assigned to the driver.pm field in
692 in struct pci_driver are ignored (even if they are not NULL).
694 The PM callbacks in struct dev_pm_ops are not mandatory and if they are not
696 subsystem will handle the device in a simplified default manner. If they are
697 defined, though, they are expected to behave as described in the following
707 This callback is only necessary if the driver's device has children that in
715 preallocated earlier, for example in a suspend/hibernate notifier as described
716 in Documentation/power/notifiers.txt).
721 callbacks have been executed for all devices in the system.
724 low-power state by the PCI subsystem. It is not required (in fact it even is
730 However, in some rare case it is convenient to carry out these operations in
742 carried out in this callback.
747 suspend() callbacks have been executed for all devices in the system and
753 arise if they were performed in suspend().
757 The freeze() callback is hibernation-specific and is executed in two situations,
759 in preparation for the creation of a system image, and during restore,
764 described above. In fact, they only need to be different in the rare cases when
776 devices in preparation for the creation of a system image, and during restore,
807 poweroff() callbacks have been executed for all devices in the system.
824 state in the resume_noirq phase of system resume and restores their standard
832 resume_noirq() callbacks have been executed for all devices in the system and
837 able to process I/O in a usual way after resume() has returned.
843 core, in the thaw_noirq phase of hibernation. It also may be executed if the
850 freeze() and freeze_noirq(), so in general it does not need to modify the
856 callbacks have been executed for all devices in the system and after device
860 the device, so that it will work in a usual way after thaw() has returned.
864 The restore_noirq() callback is hibernation-specific. It is executed in the
880 restore_noirq() callbacks have been executed for all devices in the system and
892 The complete() callback is executed in the following situations:
900 (in that case it is run after thaw() callbacks have been executed for all
901 devices that have drivers in the boot kernel).
926 The device is expected to be able to process I/O in the usual way after
934 automatically executed right after runtime_resume() has returned in case the
938 PCI subsystem will call pm_runtime_suspend() for the device, which in turn will
943 Although in principle each of the callbacks described in the previous
951 .restore() members. The other function pointers in this struct dev_pm_ops are
971 drivers implement it at least in the cases where there is a reliable way of
993 pm_runtime_allow() to be called via sysfs before the driver is loaded, so in
998 devices, or to check if they are idle (in which cases it is reasonable to
1001 are a few situations in which power management requests are automatically
1006 helper functions provided by the PM core, discussed in