Lines Matching refs:it

31 Usually, a device is put into a low-power state when it is underutilized or
32 completely inactive.  However, when it is necessary to use the device once
33 again, it has to be put back into the "fully functional" state (full-power
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
60 preparing the device to generate wakeup signals.  In that case, however, it
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
88 programmed to go into it.  The second one, D3cold, is the state that PCI devices
95 time of this writing and therefore it is not covered by this document.
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
140 majority of x86-based systems, it is supposed to implement device power
175 3.0) control method defined for it has to be executed before _PSx.  Power
178 _OFF control methods).  If the current power state of the device is D3, it can
189 lowest power (highest number) state it can be put into is also determined by the
212 and event sources is recorded in the system's ACPI BIOS from where it can be
216 associated with it (if there is one) is triggered.  The GPEs associated with PCI
222 A GPE may be triggered when the system is sleeping (i.e. when it is in one of
246 it was possible to introduce a mechanism by which a root port generates an
247 interrupt whenever it receives a PME message from one of the devices below it.
249 recorded in one of the root port's configuration registers from where it may be
256 systems along with the GPEs, but to use it the kernel has to ask the system's
259 and if it doesn't do that, the kernel must not modify their contents.  Of course
269 number of ways.  First of all, it provides an intermediate code layer between
336 the struct device embedded in it are updated accordingly and the generation of
352 devices.  For this purpose it uses the general runtime power management
354 Namely, it provides subsystem-level callbacks:
372 the device is prepared to generate wakeup signals and, finally, it is put into
376 state from which it can signal wakeup.  The exact method of signaling wakeup is
379 device for signaling wakeup and put it into the selected low-power state, the
384 not attempt to prepare the device for signaling wakeup or to put it into a
393 back into the full-power state, prevents it from signaling wakeup while in that
398 situations.  First, it may be called at the request of the device's driver, for
399 example if there are some data for it to process.  Second, it may be called
411 example, it is called right after the device has just been resumed), in which
412 cases it is expected to suspend the device if that makes sense.  Usually,
414 suspended, so it lets the device's driver decide by running its
441 state with the help of pm_runtime_resume().  Then, it executes the device
451 pcibios_disable_device() to disable it, unless the device is a bridge (PCI
453 callback is executed, if defined, and its result is returned if it fails.
471 executed, if present, and its result is returned if it fails.  Next, if the
474 saves them, prepares the device to signal wakeup (if necessary) and puts it into
478 state from which it can signal wakeup while the system is in the target sleep
543 System hibernation is more complicated than system suspend, because it requires
563 The pci_pm_freeze() routine is quite similar to pci_pm_suspend(), but it runs
565 and it doesn't apply the suspend-related hardware quirks.  It is executed
570 pci_pm_suspend_noirq(), but it calls the device driver's pm->freeze_noirq()
572 device for signaling wakeup and put it into a low-power state.  Still, it saves
576 Once the image has been created, it has to be saved.  However, at this point all
592 but it doesn't put the device into the full power state and doesn't attempt to
596 The pci_pm_thaw() routine is similar to pci_pm_resume(), but it runs the device
601 The complete phase it the same as for system resume.
629 has loaded the image, it needs to replace its own code and data with the code
648 it must restore the devices' pre-hibernation functionality, which is done much
649 like waking up from the memory sleep state, although it involves different
684 not really suitable for any new drivers.  Therefore it is not covered by this
685 document (refer to the source code to learn more about it).
713 preparing the device to be suspended, although it should not allocate memory
714 (if additional memory is required to suspend the device, it has to be
723 This callback is expected to quiesce the device and prepare it to be put into a
724 low-power state by the PCI subsystem.  It is not required (in fact it even is
726 configuration registers of the device, prepare it for waking up the system, or
727 put it into a low-power state.  All of these operations can very well be taken
730 However, in some rare case it is convenient to carry out these operations in
733 registers, to prepare it for system wakeup (if necessary), and to put it into a
769 or put it into a low-power state.  Still, either it or freeze_noirq() should
782 callback described above and it very rarely is necessary to define
796 callbacks described above, although it does not need to save the contents of
800 pci_set_power_state() to prepare the device for system wakeup and to put it
801 into a low-power state, respectively, but it need not save the device's standard
810 freeze_noirq() callbacks described above, but it does not need to save the
826 it should only be used for performing operations that would lead to race
836 device and bringing it back to the fully functional state.  The device should be
844 loading of a hibernation image fails during system restore (it is then executed
850 freeze() and freeze_noirq(), so in general it does not need to modify the
860 the device, so that it will work in a usual way after thaw() has returned.
869 This callback is analogous to resume_noirq() with the exception that it cannot
900 (in that case it is run after thaw() callbacks have been executed for all
903 This callback is entirely optional, although it may be necessary if the
913 This callback is responsible for freezing the device and preparing it to be
914 put into a low-power state, but it must allow the PCI subsystem to perform all
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
933 the device according to the PM core's information.  In particular, it is
937 This callback is optional, but if it is not implemented or if it returns 0, the
944 subsections can be defined as a separate function, it often is convenient to
954 The UNIVERSAL_DEV_PM_OPS macro is similar to SIMPLE_DEV_PM_OPS, but it
970 The PCI device runtime PM is optional, but it is recommended that PCI device
971 drivers implement it at least in the cases where there is a reliable way of
985 framework provided by the PM core and the PCI subsystem, it should enable this
988 the runtime PM of the device.  Instead, it should allow user space or some
989 platform-specific code to do that (user space can do it via sysfs), although
990 once it has called pm_runtime_enable(), it must be prepared to handle the
995 soon as it calls pm_runtime_enable().]
998 devices, or to check if they are idle (in which cases it is reasonable to