1151f4e2bSMauro Carvalho Chehab==================================== 2151f4e2bSMauro Carvalho ChehabSystem Suspend and Device Interrupts 3151f4e2bSMauro Carvalho Chehab==================================== 4151f4e2bSMauro Carvalho Chehab 5151f4e2bSMauro Carvalho ChehabCopyright (C) 2014 Intel Corp. 6151f4e2bSMauro Carvalho ChehabAuthor: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 7151f4e2bSMauro Carvalho Chehab 8151f4e2bSMauro Carvalho Chehab 9151f4e2bSMauro Carvalho ChehabSuspending and Resuming Device IRQs 10151f4e2bSMauro Carvalho Chehab----------------------------------- 11151f4e2bSMauro Carvalho Chehab 12151f4e2bSMauro Carvalho ChehabDevice interrupt request lines (IRQs) are generally disabled during system 13151f4e2bSMauro Carvalho Chehabsuspend after the "late" phase of suspending devices (that is, after all of the 14151f4e2bSMauro Carvalho Chehab->prepare, ->suspend and ->suspend_late callbacks have been executed for all 15151f4e2bSMauro Carvalho Chehabdevices). That is done by suspend_device_irqs(). 16151f4e2bSMauro Carvalho Chehab 17151f4e2bSMauro Carvalho ChehabThe rationale for doing so is that after the "late" phase of device suspend 18151f4e2bSMauro Carvalho Chehabthere is no legitimate reason why any interrupts from suspended devices should 19151f4e2bSMauro Carvalho Chehabtrigger and if any devices have not been suspended properly yet, it is better to 20151f4e2bSMauro Carvalho Chehabblock interrupts from them anyway. Also, in the past we had problems with 21151f4e2bSMauro Carvalho Chehabinterrupt handlers for shared IRQs that device drivers implementing them were 22151f4e2bSMauro Carvalho Chehabnot prepared for interrupts triggering after their devices had been suspended. 23151f4e2bSMauro Carvalho ChehabIn some cases they would attempt to access, for example, memory address spaces 24151f4e2bSMauro Carvalho Chehabof suspended devices and cause unpredictable behavior to ensue as a result. 25151f4e2bSMauro Carvalho ChehabUnfortunately, such problems are very difficult to debug and the introduction 26151f4e2bSMauro Carvalho Chehabof suspend_device_irqs(), along with the "noirq" phase of device suspend and 27151f4e2bSMauro Carvalho Chehabresume, was the only practical way to mitigate them. 28151f4e2bSMauro Carvalho Chehab 29151f4e2bSMauro Carvalho ChehabDevice IRQs are re-enabled during system resume, right before the "early" phase 30151f4e2bSMauro Carvalho Chehabof resuming devices (that is, before starting to execute ->resume_early 31151f4e2bSMauro Carvalho Chehabcallbacks for devices). The function doing that is resume_device_irqs(). 32151f4e2bSMauro Carvalho Chehab 33151f4e2bSMauro Carvalho Chehab 34151f4e2bSMauro Carvalho ChehabThe IRQF_NO_SUSPEND Flag 35151f4e2bSMauro Carvalho Chehab------------------------ 36151f4e2bSMauro Carvalho Chehab 37151f4e2bSMauro Carvalho ChehabThere are interrupts that can legitimately trigger during the entire system 38151f4e2bSMauro Carvalho Chehabsuspend-resume cycle, including the "noirq" phases of suspending and resuming 39151f4e2bSMauro Carvalho Chehabdevices as well as during the time when nonboot CPUs are taken offline and 40151f4e2bSMauro Carvalho Chehabbrought back online. That applies to timer interrupts in the first place, 41151f4e2bSMauro Carvalho Chehabbut also to IPIs and to some other special-purpose interrupts. 42151f4e2bSMauro Carvalho Chehab 43151f4e2bSMauro Carvalho ChehabThe IRQF_NO_SUSPEND flag is used to indicate that to the IRQ subsystem when 44151f4e2bSMauro Carvalho Chehabrequesting a special-purpose interrupt. It causes suspend_device_irqs() to 45151f4e2bSMauro Carvalho Chehableave the corresponding IRQ enabled so as to allow the interrupt to work as 46151f4e2bSMauro Carvalho Chehabexpected during the suspend-resume cycle, but does not guarantee that the 47151f4e2bSMauro Carvalho Chehabinterrupt will wake the system from a suspended state -- for such cases it is 48151f4e2bSMauro Carvalho Chehabnecessary to use enable_irq_wake(). 49151f4e2bSMauro Carvalho Chehab 50151f4e2bSMauro Carvalho ChehabNote that the IRQF_NO_SUSPEND flag affects the entire IRQ and not just one 51151f4e2bSMauro Carvalho Chehabuser of it. Thus, if the IRQ is shared, all of the interrupt handlers installed 52151f4e2bSMauro Carvalho Chehabfor it will be executed as usual after suspend_device_irqs(), even if the 53151f4e2bSMauro Carvalho ChehabIRQF_NO_SUSPEND flag was not passed to request_irq() (or equivalent) by some of 54151f4e2bSMauro Carvalho Chehabthe IRQ's users. For this reason, using IRQF_NO_SUSPEND and IRQF_SHARED at the 55151f4e2bSMauro Carvalho Chehabsame time should be avoided. 56151f4e2bSMauro Carvalho Chehab 57151f4e2bSMauro Carvalho Chehab 58151f4e2bSMauro Carvalho ChehabSystem Wakeup Interrupts, enable_irq_wake() and disable_irq_wake() 59151f4e2bSMauro Carvalho Chehab------------------------------------------------------------------ 60151f4e2bSMauro Carvalho Chehab 61151f4e2bSMauro Carvalho ChehabSystem wakeup interrupts generally need to be configured to wake up the system 62151f4e2bSMauro Carvalho Chehabfrom sleep states, especially if they are used for different purposes (e.g. as 63151f4e2bSMauro Carvalho ChehabI/O interrupts) in the working state. 64151f4e2bSMauro Carvalho Chehab 65151f4e2bSMauro Carvalho ChehabThat may involve turning on a special signal handling logic within the platform 66151f4e2bSMauro Carvalho Chehab(such as an SoC) so that signals from a given line are routed in a different way 67151f4e2bSMauro Carvalho Chehabduring system sleep so as to trigger a system wakeup when needed. For example, 68151f4e2bSMauro Carvalho Chehabthe platform may include a dedicated interrupt controller used specifically for 69151f4e2bSMauro Carvalho Chehabhandling system wakeup events. Then, if a given interrupt line is supposed to 70*71bc571cSRandy Dunlapwake up the system from sleep states, the corresponding input of that interrupt 71151f4e2bSMauro Carvalho Chehabcontroller needs to be enabled to receive signals from the line in question. 72151f4e2bSMauro Carvalho ChehabAfter wakeup, it generally is better to disable that input to prevent the 73151f4e2bSMauro Carvalho Chehabdedicated controller from triggering interrupts unnecessarily. 74151f4e2bSMauro Carvalho Chehab 75151f4e2bSMauro Carvalho ChehabThe IRQ subsystem provides two helper functions to be used by device drivers for 76151f4e2bSMauro Carvalho Chehabthose purposes. Namely, enable_irq_wake() turns on the platform's logic for 77151f4e2bSMauro Carvalho Chehabhandling the given IRQ as a system wakeup interrupt line and disable_irq_wake() 78151f4e2bSMauro Carvalho Chehabturns that logic off. 79151f4e2bSMauro Carvalho Chehab 80151f4e2bSMauro Carvalho ChehabCalling enable_irq_wake() causes suspend_device_irqs() to treat the given IRQ 81151f4e2bSMauro Carvalho Chehabin a special way. Namely, the IRQ remains enabled, by on the first interrupt 82151f4e2bSMauro Carvalho Chehabit will be disabled, marked as pending and "suspended" so that it will be 83151f4e2bSMauro Carvalho Chehabre-enabled by resume_device_irqs() during the subsequent system resume. Also 84151f4e2bSMauro Carvalho Chehabthe PM core is notified about the event which causes the system suspend in 85151f4e2bSMauro Carvalho Chehabprogress to be aborted (that doesn't have to happen immediately, but at one 86151f4e2bSMauro Carvalho Chehabof the points where the suspend thread looks for pending wakeup events). 87151f4e2bSMauro Carvalho Chehab 88151f4e2bSMauro Carvalho ChehabThis way every interrupt from a wakeup interrupt source will either cause the 89151f4e2bSMauro Carvalho Chehabsystem suspend currently in progress to be aborted or wake up the system if 90151f4e2bSMauro Carvalho Chehabalready suspended. However, after suspend_device_irqs() interrupt handlers are 91151f4e2bSMauro Carvalho Chehabnot executed for system wakeup IRQs. They are only executed for IRQF_NO_SUSPEND 92151f4e2bSMauro Carvalho ChehabIRQs at that time, but those IRQs should not be configured for system wakeup 93151f4e2bSMauro Carvalho Chehabusing enable_irq_wake(). 94151f4e2bSMauro Carvalho Chehab 95151f4e2bSMauro Carvalho Chehab 96151f4e2bSMauro Carvalho ChehabInterrupts and Suspend-to-Idle 97151f4e2bSMauro Carvalho Chehab------------------------------ 98151f4e2bSMauro Carvalho Chehab 99151f4e2bSMauro Carvalho ChehabSuspend-to-idle (also known as the "freeze" sleep state) is a relatively new 100151f4e2bSMauro Carvalho Chehabsystem sleep state that works by idling all of the processors and waiting for 101151f4e2bSMauro Carvalho Chehabinterrupts right after the "noirq" phase of suspending devices. 102151f4e2bSMauro Carvalho Chehab 103151f4e2bSMauro Carvalho ChehabOf course, this means that all of the interrupts with the IRQF_NO_SUSPEND flag 104151f4e2bSMauro Carvalho Chehabset will bring CPUs out of idle while in that state, but they will not cause the 105151f4e2bSMauro Carvalho ChehabIRQ subsystem to trigger a system wakeup. 106151f4e2bSMauro Carvalho Chehab 107151f4e2bSMauro Carvalho ChehabSystem wakeup interrupts, in turn, will trigger wakeup from suspend-to-idle in 108151f4e2bSMauro Carvalho Chehabanalogy with what they do in the full system suspend case. The only difference 109151f4e2bSMauro Carvalho Chehabis that the wakeup from suspend-to-idle is signaled using the usual working 110151f4e2bSMauro Carvalho Chehabstate interrupt delivery mechanisms and doesn't require the platform to use 111151f4e2bSMauro Carvalho Chehabany special interrupt handling logic for it to work. 112151f4e2bSMauro Carvalho Chehab 113151f4e2bSMauro Carvalho Chehab 114151f4e2bSMauro Carvalho ChehabIRQF_NO_SUSPEND and enable_irq_wake() 115151f4e2bSMauro Carvalho Chehab------------------------------------- 116151f4e2bSMauro Carvalho Chehab 117151f4e2bSMauro Carvalho ChehabThere are very few valid reasons to use both enable_irq_wake() and the 118151f4e2bSMauro Carvalho ChehabIRQF_NO_SUSPEND flag on the same IRQ, and it is never valid to use both for the 119151f4e2bSMauro Carvalho Chehabsame device. 120151f4e2bSMauro Carvalho Chehab 121151f4e2bSMauro Carvalho ChehabFirst of all, if the IRQ is not shared, the rules for handling IRQF_NO_SUSPEND 122151f4e2bSMauro Carvalho Chehabinterrupts (interrupt handlers are invoked after suspend_device_irqs()) are 123151f4e2bSMauro Carvalho Chehabdirectly at odds with the rules for handling system wakeup interrupts (interrupt 124151f4e2bSMauro Carvalho Chehabhandlers are not invoked after suspend_device_irqs()). 125151f4e2bSMauro Carvalho Chehab 126151f4e2bSMauro Carvalho ChehabSecond, both enable_irq_wake() and IRQF_NO_SUSPEND apply to entire IRQs and not 127151f4e2bSMauro Carvalho Chehabto individual interrupt handlers, so sharing an IRQ between a system wakeup 128151f4e2bSMauro Carvalho Chehabinterrupt source and an IRQF_NO_SUSPEND interrupt source does not generally 129151f4e2bSMauro Carvalho Chehabmake sense. 130151f4e2bSMauro Carvalho Chehab 131151f4e2bSMauro Carvalho ChehabIn rare cases an IRQ can be shared between a wakeup device driver and an 132151f4e2bSMauro Carvalho ChehabIRQF_NO_SUSPEND user. In order for this to be safe, the wakeup device driver 133151f4e2bSMauro Carvalho Chehabmust be able to discern spurious IRQs from genuine wakeup events (signalling 134151f4e2bSMauro Carvalho Chehabthe latter to the core with pm_system_wakeup()), must use enable_irq_wake() to 135151f4e2bSMauro Carvalho Chehabensure that the IRQ will function as a wakeup source, and must request the IRQ 136151f4e2bSMauro Carvalho Chehabwith IRQF_COND_SUSPEND to tell the core that it meets these requirements. If 137151f4e2bSMauro Carvalho Chehabthese requirements are not met, it is not valid to use IRQF_COND_SUSPEND. 138