Lines Matching +full:suspend +full:- +full:to +full:- +full:idle

2 System Suspend and Device Interrupts
10 -----------------------------------
13 suspend after the "late" phase of suspending devices (that is, after all of the
14 ->prepare, ->suspend and ->suspend_late callbacks have been executed for all
17 The rationale for doing so is that after the "late" phase of device suspend
19 trigger and if any devices have not been suspended properly yet, it is better to
23 In some cases they would attempt to access, for example, memory address spaces
24 of suspended devices and cause unpredictable behavior to ensue as a result.
25 Unfortunately, such problems are very difficult to debug and the introduction
26 of suspend_device_irqs(), along with the "noirq" phase of device suspend and
27 resume, was the only practical way to mitigate them.
29 Device IRQs are re-enabled during system resume, right before the "early" phase
30 of resuming devices (that is, before starting to execute ->resume_early
35 ------------------------
38 suspend-resume cycle, including the "noirq" phases of suspending and resuming
40 brought back online. That applies to timer interrupts in the first place,
41 but also to IPIs and to some other special-purpose interrupts.
43 The IRQF_NO_SUSPEND flag is used to indicate that to the IRQ subsystem when
44 requesting a special-purpose interrupt. It causes suspend_device_irqs() to
45 leave the corresponding IRQ enabled so as to allow the interrupt to work as
46 expected during the suspend-resume cycle, but does not guarantee that the
47 interrupt will wake the system from a suspended state -- for such cases it is
48 necessary to use enable_irq_wake().
53 IRQF_NO_SUSPEND flag was not passed to request_irq() (or equivalent) by some of
59 ------------------------------------------------------------------
61 System wakeup interrupts generally need to be configured to wake up the system
67 during system sleep so as to trigger a system wakeup when needed. For example,
69 handling system wakeup events. Then, if a given interrupt line is supposed to
71 controller needs to be enabled to receive signals from the line in question.
72 After wakeup, it generally is better to disable that input to prevent the
75 The IRQ subsystem provides two helper functions to be used by device drivers for
80 Calling enable_irq_wake() causes suspend_device_irqs() to treat the given IRQ
83 re-enabled by resume_device_irqs() during the subsequent system resume. Also
84 the PM core is notified about the event which causes the system suspend in
85 progress to be aborted (that doesn't have to happen immediately, but at one
86 of the points where the suspend thread looks for pending wakeup events).
89 system suspend currently in progress to be aborted or wake up the system if
96 Interrupts and Suspend-to-Idle
97 ------------------------------
99 Suspend-to-idle (also known as the "freeze" sleep state) is a relatively new
104 set will bring CPUs out of idle while in that state, but they will not cause the
105 IRQ subsystem to trigger a system wakeup.
107 System wakeup interrupts, in turn, will trigger wakeup from suspend-to-idle in
108 analogy with what they do in the full system suspend case. The only difference
109 is that the wakeup from suspend-to-idle is signaled using the usual working
110 state interrupt delivery mechanisms and doesn't require the platform to use
111 any special interrupt handling logic for it to work.
115 -------------------------------------
117 There are very few valid reasons to use both enable_irq_wake() and the
118 IRQF_NO_SUSPEND flag on the same IRQ, and it is never valid to use both for the
126 Second, both enable_irq_wake() and IRQF_NO_SUSPEND apply to entire IRQs and not
127 to individual interrupt handlers, so sharing an IRQ between a system wakeup
132 IRQF_NO_SUSPEND user. In order for this to be safe, the wakeup device driver
133 must be able to discern spurious IRQs from genuine wakeup events (signalling
134 the latter to the core with pm_system_wakeup()), must use enable_irq_wake() to
136 with IRQF_COND_SUSPEND to tell the core that it meets these requirements. If
137 these requirements are not met, it is not valid to use IRQF_COND_SUSPEND.