aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/bin
diff options
context:
space:
mode:
Diffstat (limited to 'tools/perf/scripts/python/bin')
0 files changed, 0 insertions, 0 deletions
devices after invoking * subsystem-level @resume_noirq() for all of them. * * @resume_early: Prepare to execute @resume(). For a number of devices * @resume_early() may point to the same callback routine as the runtime * resume callback. * * @freeze: Hibernation-specific, executed before creating a hibernation image. * Analogous to @suspend(), but it should not enable the device to signal * wakeup events or change its power state. The majority of subsystems * (with the notable exception of the PCI bus type) expect the driver-level * @freeze() to save the device settings in memory to be used by @restore() * during the subsequent resume from hibernation. * Subsystem-level @freeze() is executed for all devices after invoking * subsystem-level @prepare() for all of them. * * @freeze_late: Continue operations started by @freeze(). Analogous to * @suspend_late(), but it should not enable the device to signal wakeup * events or change its power state. * * @thaw: Hibernation-specific, executed after creating a hibernation image OR * if the creation of an image has failed. Also executed after a failing * attempt to restore the contents of main memory from such an image. * Undo the changes made by the preceding @freeze(), so the device can be * operated in the same way as immediately before the call to @freeze(). * Subsystem-level @thaw() is executed for all devices after invoking * subsystem-level @thaw_noirq() for all of them. It also may be executed * directly after @freeze() in case of a transition error. * * @thaw_early: Prepare to execute @thaw(). Undo the changes made by the * preceding @freeze_late(). * * @poweroff: Hibernation-specific, executed after saving a hibernation image. * Analogous to @suspend(), but it need not save the device's settings in * memory. * Subsystem-level @poweroff() is executed for all devices after invoking * subsystem-level @prepare() for all of them. * * @poweroff_late: Continue operations started by @poweroff(). Analogous to * @suspend_late(), but it need not save the device's settings in memory. * * @restore: Hibernation-specific, executed after restoring the contents of main * memory from a hibernation image, analogous to @resume(). * * @restore_early: Prepare to execute @restore(), analogous to @resume_early(). * * @suspend_noirq: Complete the actions started by @suspend(). Carry out any * additional operations required for suspending the device that might be * racing with its driver's interrupt handler, which is guaranteed not to * run while @suspend_noirq() is being executed. * It generally is expected that the device will be in a low-power state * (appropriate for the target system sleep state) after subsystem-level * @suspend_noirq() has returned successfully. If the device can generate * system wakeup signals and is enabled to wake up the system, it should be * configured to do so at that time. However, depending on the platform * and device's subsystem, @suspend() or @suspend_late() may be allowed to * put the device into the low-power state and configure it to generate * wakeup signals, in which case it generally is not necessary to define * @suspend_noirq(). * * @resume_noirq: Prepare for the execution of @resume() by carrying out any * operations required for resuming the device that might be racing with * its driver's interrupt handler, which is guaranteed not to run while * @resume_noirq() is being executed. * * @freeze_noirq: Complete the actions started by @freeze(). Carry out any * additional operations required for freezing the device that might be * racing with its driver's interrupt handler, which is guaranteed not to * run while @freeze_noirq() is being executed. * The power state of the device should not be changed by either @freeze(), * or @freeze_late(), or @freeze_noirq() and it should not be configured to * signal system wakeup by any of these callbacks. * * @thaw_noirq: Prepare for the execution of @thaw() by carrying out any * operations required for thawing the device that might be racing with its * driver's interrupt handler, which is guaranteed not to run while * @thaw_noirq() is being executed. * * @poweroff_noirq: Complete the actions started by @poweroff(). Analogous to * @suspend_noirq(), but it need not save the device's settings in memory. * * @restore_noirq: Prepare for the execution of @restore() by carrying out any * operations required for thawing the device that might be racing with its * driver's interrupt handler, which is guaranteed not to run while * @restore_noirq() is being executed. Analogous to @resume_noirq(). * * @runtime_suspend: Prepare the device for a condition in which it won't be * able to communicate with the CPU(s) and RAM due to power management. * This need not mean that the device should be put into a low-power state. * For example, if the device is behind a link which is about to be turned * off, the device may remain at full power. If the device does go to low * power and is capable of generating runtime wakeup events, remote wakeup * (i.e., a hardware mechanism allowing the device to request a change of * its power state via an interrupt) should be enabled for it. * * @runtime_resume: Put the device into the fully active state in response to a * wakeup event generated by hardware or at the request of software. If * necessary, put the device into the full-power state and restore its * registers, so that it is fully operational. * * @runtime_idle: Device appears to be inactive and it might be put into a * low-power state if all of the necessary conditions are satisfied. * Check these conditions, and return 0 if it's appropriate to let the PM * core queue a suspend request for the device. * * Several device power sta