Documentation/power/suspend-and-interrupts.rst

10 -----------------------------------
12 Device interrupt request lines (IRQs) are generally disabled during system
14 ->prepare, ->suspend and ->suspend_late callbacks have been executed for all
21 interrupt handlers for shared IRQs that device drivers implementing them were
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
41 but also to IPIs and to some other special-purpose interrupts.
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
51 user of it.  Thus, if the IRQ is shared, all of the interrupt handlers installed
58 System Wakeup Interrupts, enable_irq_wake() and disable_irq_wake()
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,
68 the platform may include a dedicated interrupt controller used specifically for
69 handling system wakeup events.  Then, if a given interrupt line is supposed to
70 wake up the system from sleep states, the corresponding input of that interrupt
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
73 dedicated controller from triggering interrupts unnecessarily.
77 handling the given IRQ as a system wakeup interrupt line and disable_irq_wake()
81 in a special way.  Namely, the IRQ remains enabled, by on the first interrupt
83 re-enabled by resume_device_irqs() during the subsequent system resume.  Also
86 of the points where the suspend thread looks for pending wakeup events).
88 This way every interrupt from a wakeup interrupt source will either cause the
90 already suspended.  However, after suspend_device_irqs() interrupt handlers are
91 not executed for system wakeup IRQs.  They are only executed for IRQF_NO_SUSPEND
92 IRQs at that time, but those IRQs should not be configured for system wakeup
96 Interrupts and Suspend-to-Idle
97 ------------------------------
99 Suspend-to-idle (also known as the "freeze" sleep state) is a relatively new
105 IRQ subsystem to trigger a system wakeup.
107 System wakeup interrupts, in turn, will trigger wakeup from suspend-to-idle in
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 -------------------------------------
122 interrupts (interrupt handlers are invoked after suspend_device_irqs()) are
123 directly at odds with the rules for handling system wakeup interrupts (interrupt
127 to individual interrupt handlers, so sharing an IRQ between a system wakeup
128 interrupt source and an IRQF_NO_SUSPEND interrupt source does not generally
131 In rare cases an IRQ can be shared between a wakeup device driver and an
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
135 ensure that the IRQ will function as a wakeup source, and must request the IRQ