^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) ====================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) System Suspend and Device Interrupts
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) ====================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) Copyright (C) 2014 Intel Corp.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6) Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) Suspending and Resuming Device IRQs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) -----------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) Device interrupt request lines (IRQs) are generally disabled during system
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) suspend after the "late" phase of suspending devices (that is, after all of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) ->prepare, ->suspend and ->suspend_late callbacks have been executed for all
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) devices). That is done by suspend_device_irqs().
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) The rationale for doing so is that after the "late" phase of device suspend
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) there is no legitimate reason why any interrupts from suspended devices should
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) trigger and if any devices have not been suspended properly yet, it is better to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) block interrupts from them anyway. Also, in the past we had problems with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) interrupt handlers for shared IRQs that device drivers implementing them were
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) not prepared for interrupts triggering after their devices had been suspended.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) In some cases they would attempt to access, for example, memory address spaces
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) of suspended devices and cause unpredictable behavior to ensue as a result.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) Unfortunately, such problems are very difficult to debug and the introduction
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) of suspend_device_irqs(), along with the "noirq" phase of device suspend and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) resume, was the only practical way to mitigate them.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) Device IRQs are re-enabled during system resume, right before the "early" phase
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) of resuming devices (that is, before starting to execute ->resume_early
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) callbacks for devices). The function doing that is resume_device_irqs().
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) The IRQF_NO_SUSPEND Flag
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) ------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) There are interrupts that can legitimately trigger during the entire system
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) suspend-resume cycle, including the "noirq" phases of suspending and resuming
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) devices as well as during the time when nonboot CPUs are taken offline and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) brought back online. That applies to timer interrupts in the first place,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) but also to IPIs and to some other special-purpose interrupts.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) The IRQF_NO_SUSPEND flag is used to indicate that to the IRQ subsystem when
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) requesting a special-purpose interrupt. It causes suspend_device_irqs() to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) leave the corresponding IRQ enabled so as to allow the interrupt to work as
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) expected during the suspend-resume cycle, but does not guarantee that the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) interrupt will wake the system from a suspended state -- for such cases it is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) necessary to use enable_irq_wake().
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) Note that the IRQF_NO_SUSPEND flag affects the entire IRQ and not just one
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) user of it. Thus, if the IRQ is shared, all of the interrupt handlers installed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) for it will be executed as usual after suspend_device_irqs(), even if the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) IRQF_NO_SUSPEND flag was not passed to request_irq() (or equivalent) by some of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) the IRQ's users. For this reason, using IRQF_NO_SUSPEND and IRQF_SHARED at the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) same time should be avoided.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) System Wakeup Interrupts, enable_irq_wake() and disable_irq_wake()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) ------------------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) System wakeup interrupts generally need to be configured to wake up the system
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) from sleep states, especially if they are used for different purposes (e.g. as
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) I/O interrupts) in the working state.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) That may involve turning on a special signal handling logic within the platform
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) (such as an SoC) so that signals from a given line are routed in a different way
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) during system sleep so as to trigger a system wakeup when needed. For example,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) the platform may include a dedicated interrupt controller used specifically for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) handling system wakeup events. Then, if a given interrupt line is supposed to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) wake up the system from sleep sates, the corresponding input of that interrupt
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) controller needs to be enabled to receive signals from the line in question.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) After wakeup, it generally is better to disable that input to prevent the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) dedicated controller from triggering interrupts unnecessarily.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) The IRQ subsystem provides two helper functions to be used by device drivers for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) those purposes. Namely, enable_irq_wake() turns on the platform's logic for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) handling the given IRQ as a system wakeup interrupt line and disable_irq_wake()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) turns that logic off.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) Calling enable_irq_wake() causes suspend_device_irqs() to treat the given IRQ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) in a special way. Namely, the IRQ remains enabled, by on the first interrupt
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) it will be disabled, marked as pending and "suspended" so that it will be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) re-enabled by resume_device_irqs() during the subsequent system resume. Also
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) the PM core is notified about the event which causes the system suspend in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) progress to be aborted (that doesn't have to happen immediately, but at one
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) of the points where the suspend thread looks for pending wakeup events).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) This way every interrupt from a wakeup interrupt source will either cause the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) system suspend currently in progress to be aborted or wake up the system if
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) already suspended. However, after suspend_device_irqs() interrupt handlers are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) not executed for system wakeup IRQs. They are only executed for IRQF_NO_SUSPEND
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) IRQs at that time, but those IRQs should not be configured for system wakeup
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) using enable_irq_wake().
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) Interrupts and Suspend-to-Idle
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) ------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) Suspend-to-idle (also known as the "freeze" sleep state) is a relatively new
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) system sleep state that works by idling all of the processors and waiting for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) interrupts right after the "noirq" phase of suspending devices.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) Of course, this means that all of the interrupts with the IRQF_NO_SUSPEND flag
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) set will bring CPUs out of idle while in that state, but they will not cause the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) IRQ subsystem to trigger a system wakeup.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) System wakeup interrupts, in turn, will trigger wakeup from suspend-to-idle in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) analogy with what they do in the full system suspend case. The only difference
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) is that the wakeup from suspend-to-idle is signaled using the usual working
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) state interrupt delivery mechanisms and doesn't require the platform to use
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) any special interrupt handling logic for it to work.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) IRQF_NO_SUSPEND and enable_irq_wake()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) -------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) There are very few valid reasons to use both enable_irq_wake() and the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) IRQF_NO_SUSPEND flag on the same IRQ, and it is never valid to use both for the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) same device.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) First of all, if the IRQ is not shared, the rules for handling IRQF_NO_SUSPEND
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) interrupts (interrupt handlers are invoked after suspend_device_irqs()) are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) directly at odds with the rules for handling system wakeup interrupts (interrupt
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) handlers are not invoked after suspend_device_irqs()).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) Second, both enable_irq_wake() and IRQF_NO_SUSPEND apply to entire IRQs and not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) to individual interrupt handlers, so sharing an IRQ between a system wakeup
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) interrupt source and an IRQF_NO_SUSPEND interrupt source does not generally
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) make sense.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) In rare cases an IRQ can be shared between a wakeup device driver and an
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) IRQF_NO_SUSPEND user. In order for this to be safe, the wakeup device driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) must be able to discern spurious IRQs from genuine wakeup events (signalling
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) the latter to the core with pm_system_wakeup()), must use enable_irq_wake() to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) ensure that the IRQ will function as a wakeup source, and must request the IRQ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) with IRQF_COND_SUSPEND to tell the core that it meets these requirements. If
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) these requirements are not met, it is not valid to use IRQF_COND_SUSPEND.
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags