Lines Matching full:it
34 Usually, a device is put into a low-power state when it is underutilized or
35 completely inactive. However, when it is necessary to use the device once
36 again, it has to be put back into the "fully functional" state (full-power
53 to put the device that sent it into the full-power state. However, the PCI Bus
56 It is assumed that the platform firmware will perform this task and therefore,
57 even though a PCI device is set up to generate PMEs, it also may be necessary to
63 preparing the device to generate wakeup signals. In that case, however, it
75 introduced between the PCI 2.1 and PCI 2.2 Specifications. It defined a
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
92 programmed to go into it. The second one, D3cold, is the state that PCI devices
93 are in when the supply voltage (Vcc) is removed from them. It is not possible
99 time of this writing and therefore it is not covered by this document.
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
145 majority of x86-based systems, it is supposed to implement device power
180 3.0) control method defined for it has to be executed before _PSx. Power
183 _OFF control methods). If the current power state of the device is D3, it can
194 lowest power (highest number) state it can be put into is also determined by the
196 _SxW control method to obtain the number of that state. It also is supposed to
218 and event sources is recorded in the system's ACPI BIOS from where it can be
222 associated with it (if there is one) is triggered. The GPEs associated with PCI
228 A GPE may be triggered when the system is sleeping (i.e. when it is in one of
252 it was possible to introduce a mechanism by which a root port generates an
253 interrupt whenever it receives a PME message from one of the devices below it.
255 recorded in one of the root port's configuration registers from where it may be
262 systems along with the GPEs, but to use it the kernel has to ask the system's
265 and if it doesn't do that, the kernel must not modify their contents. Of course
276 number of ways. First of all, it provides an intermediate code layer between
344 the struct device embedded in it are updated accordingly and the generation of
361 devices. For this purpose it uses the general runtime power management
363 Namely, it provides subsystem-level callbacks::
369 that are executed by the core runtime PM routines. It also implements the
381 the device is prepared to generate wakeup signals and, finally, it is put into
385 state from which it can signal wakeup. The exact method of signaling wakeup is
388 device for signaling wakeup and put it into the selected low-power state, the
392 It is expected that the device driver's pm->runtime_suspend() callback will
393 not attempt to prepare the device for signaling wakeup or to put it into a
402 back into the full-power state, prevents it from signaling wakeup while in that
407 situations. First, it may be called at the request of the device's driver, for
408 example if there are some data for it to process. Second, it may be called
420 example, it is called right after the device has just been resumed), in which
421 cases it is expected to suspend the device if that makes sense. Usually,
423 suspended, so it lets the device's driver decide by running its
451 state with the help of pm_runtime_resume(). Then, it executes the device
461 pcibios_disable_device() to disable it, unless the device is a bridge (PCI
463 callback is executed, if defined, and its result is returned if it fails.
474 invoked while this routine is running. It first checks if the device's driver
481 executed, if present, and its result is returned if it fails. Next, if the
484 saves them, prepares the device to signal wakeup (if necessary) and puts it into
488 state from which it can signal wakeup while the system is in the target sleep
555 System hibernation is more complicated than system suspend, because it requires
575 The pci_pm_freeze() routine is quite similar to pci_pm_suspend(), but it runs
577 and it doesn't apply the suspend-related hardware quirks. It is executed
582 pci_pm_suspend_noirq(), but it calls the device driver's pm->freeze_noirq()
583 routine instead of pm->suspend_noirq(). It also doesn't attempt to prepare the
584 device for signaling wakeup and put it into a low-power state. Still, it saves
588 Once the image has been created, it has to be saved. However, at this point all
604 It puts the device into the full power state and restores its standard
605 configuration registers. It also executes the device driver's pm->thaw_noirq()
608 The pci_pm_thaw() routine is similar to pci_pm_resume(), but it runs the device
609 driver's pm->thaw() callback instead of pm->resume(). It is executed
642 boot kernel has loaded the image, it needs to replace its own code and data with
661 it must restore the devices' pre-hibernation functionality, which is done much
662 like waking up from the memory sleep state, although it involves different
698 drivers. Therefore it is not covered by this document (refer to the source code
699 to learn more about it).
701 It is recommended that all PCI device drivers define a struct dev_pm_ops object
728 preparing the device to be suspended, although it should not allocate memory
729 (if additional memory is required to suspend the device, it has to be
739 This callback is expected to quiesce the device and prepare it to be put into a
740 low-power state by the PCI subsystem. It is not required (in fact it even is
742 configuration registers of the device, prepare it for waking up the system, or
743 put it into a low-power state. All of these operations can very well be taken
746 However, in some rare case it is convenient to carry out these operations in
749 registers, to prepare it for system wakeup (if necessary), and to put it into a
787 or put it into a low-power state. Still, either it or freeze_noirq() should
793 The freeze_noirq() callback is hibernation-specific. It is executed during
797 freeze() callbacks have been executed for all devices. It is always executed
801 callback described above and it very rarely is necessary to define
810 The poweroff() callback is hibernation-specific. It is executed when the system
816 callbacks described above, although it does not need to save the contents of
820 pci_set_power_state() to prepare the device for system wakeup and to put it
821 into a low-power state, respectively, but it need not save the device's standard
827 The poweroff_noirq() callback is hibernation-specific. It is executed after
831 freeze_noirq() callbacks described above, but it does not need to save the
848 it should only be used for performing operations that would lead to race
859 device and bringing it back to the fully functional state. The device should be
865 The thaw_noirq() callback is hibernation-specific. It is executed after a
867 core, in the thaw_noirq phase of hibernation. It also may be executed if the
868 loading of a hibernation image fails during system restore (it is then executed
874 freeze() and freeze_noirq(), so in general it does not need to modify the
880 The thaw() callback is hibernation-specific. It is executed after thaw_noirq()
885 the device, so that it will work in a usual way after thaw() has returned.
890 The restore_noirq() callback is hibernation-specific. It is executed in the
895 This callback is analogous to resume_noirq() with the exception that it cannot
906 The restore() callback is hibernation-specific. It is executed after
929 It also may be executed if the loading of a hibernation image into memory fails
930 (in that case it is run after thaw() callbacks have been executed for all
933 This callback is entirely optional, although it may be necessary if the
940 (runtime PM). It is executed by the PM core's runtime PM framework when the
944 This callback is responsible for freezing the device and preparing it to be
945 put into a low-power state, but it must allow the PCI subsystem to perform all
951 The runtime_resume() callback is specific to device runtime PM. It is executed
957 device after it has been put into the full-power state by the PCI subsystem.
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
970 This callback is optional, but if it is not implemented or if it returns 0, the
978 subsections can be defined as a separate function, it often is convenient to
988 The UNIVERSAL_DEV_PM_OPS macro is similar to SIMPLE_DEV_PM_OPS, but it
1023 reasons for doing that. Also, it causes pci_pm_suspend_late/noirq() and
1027 pci_pm_restore_noirq(), its runtime PM status will be changed to "active" (as it
1048 The PCI device runtime PM is optional, but it is recommended that PCI device
1049 drivers implement it at least in the cases where there is a reliable way of
1054 runtime_suspend() and runtime_resume() callbacks. It also may need to implement
1061 device drivers do not need to enable it and should not attempt to do so.
1062 However, it is blocked by pci_pm_init() that runs the pm_runtime_forbid()
1068 runtime PM framework provided by the PM core and the PCI subsystem, it needs
1070 function. If it doesn't do that, the counter will always be different from
1071 zero for the device and it will never be runtime-suspended. The simplest
1073 wants to schedule an autosuspend right away, for example, it may call
1074 pm_runtime_put_autosuspend() instead for this purpose. Generally, it
1078 It is important to remember that the driver's runtime_suspend() callback
1084 The driver itself should not call pm_runtime_allow(), though. Instead, it
1086 do it via sysfs as stated above), but it must be prepared to handle the
1090 When the driver's remove callback runs, it has to balance the decrementation
1092 if it has decremented the counter in its probe callback, it must run
1101 devices, or to check if they are idle (in which cases it is reasonable to