aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2015-03-06 13:36:09 -0500
committerLinus Torvalds <torvalds@linux-foundation.org>2015-03-06 13:36:09 -0500
commit39ed853a2447ce85cf29b3c0357998ff968beeb5 (patch)
tree332706b513ded8f33a80b87f08536fb895f68849 /Documentation
parent7c5bde7adeba317d266b09db8ea9c3857eda86f5 (diff)
parente178e7d6df38dab67f51df4282927c4c7392879f (diff)
Merge tag 'pm+acpi-4.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management and ACPI fixes from Rafael Wysocki: "These are fixes for recent regressions (ACPI resources management, suspend-to-idle), stable-candidate fixes (ACPI backlight), fixes related to the wakeup IRQ management changes made in v3.18, other fixes (suspend-to-idle, cpufreq ppc driver) and a couple of cleanups (suspend-to-idle, generic power domains, ACPI backlight). Specifics: - Fix ACPI resources management problems introduced by the recent rework of the code in question (Jiang Liu) and a build issue introduced by those changes (Joachim Nilsson). - Fix a recent suspend-to-idle regression on systems where entering idle states causes local timers to stop, prevent suspend-to-idle from crashing in restricted configurations (no cpuidle driver, cpuidle disabled etc.) and clean up the idle loop somewhat while at it (Rafael J Wysocki). - Fix build problem in the cpufreq ppc driver (Geert Uytterhoeven). - Allow the ACPI backlight driver module to be loaded if ACPI is disabled which helps the i915 driver in those configurations (stable-candidate) and change the code to help debug unusual use cases (Chris Wilson). - Wakeup IRQ management changes in v3.18 caused some drivers on the at91 platform to trigger a warning from the IRQ core related to an unexpected combination of interrupt action handler flags. However, on at91 a timer IRQ is shared with some other devices (including system wakeup ones) and that leads to the unusual combination of flags in question. To make it possible to avoid the warning introduce a new interrupt action handler flag (which can be used by drivers to indicate the special case to the core) and rework the problematic at91 drivers to use it and work as expected during system suspend/resume. From Boris Brezillon, Rafael J Wysocki and Mark Rutland. - Clean up the generic power domains subsystem's debugfs interface (Kevin Hilman)" * tag 'pm+acpi-4.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: genirq / PM: describe IRQF_COND_SUSPEND tty: serial: atmel: rework interrupt and wakeup handling watchdog: at91sam9: request the irq with IRQF_NO_SUSPEND cpuidle / sleep: Use broadcast timer for states that stop local timer clk: at91: implement suspend/resume for the PMC irqchip rtc: at91rm9200: rework wakeup and interrupt handling rtc: at91sam9: rework wakeup and interrupt handling PM / wakeup: export pm_system_wakeup symbol genirq / PM: Add flag for shared NO_SUSPEND interrupt lines ACPI / video: Propagate the error code for acpi_video_register ACPI / video: Load the module even if ACPI is disabled PM / Domains: cleanup: rename gpd -> genpd in debugfs interface cpufreq: ppc: Add missing #include <asm/smp.h> x86/PCI/ACPI: Relax ACPI resource descriptor checks to work around BIOS bugs x86/PCI/ACPI: Ignore resources consumed by host bridge itself cpuidle: Clean up fallback handling in cpuidle_idle_call() cpuidle / sleep: Do sanity checks in cpuidle_enter_freeze() too idle / sleep: Avoid excessive disabling and enabling interrupts PCI: versatile: Update for list_for_each_entry() API change genirq / PM: better describe IRQF_NO_SUSPEND semantics
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/power/suspend-and-interrupts.txt22
1 files changed, 17 insertions, 5 deletions
diff --git a/Documentation/power/suspend-and-interrupts.txt b/Documentation/power/suspend-and-interrupts.txt
index 2f9c5a5fcb25..8afb29a8604a 100644
--- a/Documentation/power/suspend-and-interrupts.txt
+++ b/Documentation/power/suspend-and-interrupts.txt
@@ -40,8 +40,10 @@ but also to IPIs and to some other special-purpose interrupts.
40 40
41The IRQF_NO_SUSPEND flag is used to indicate that to the IRQ subsystem when 41The IRQF_NO_SUSPEND flag is used to indicate that to the IRQ subsystem when
42requesting a special-purpose interrupt. It causes suspend_device_irqs() to 42requesting a special-purpose interrupt. It causes suspend_device_irqs() to
43leave the corresponding IRQ enabled so as to allow the interrupt to work all 43leave the corresponding IRQ enabled so as to allow the interrupt to work as
44the time as expected. 44expected during the suspend-resume cycle, but does not guarantee that the
45interrupt will wake the system from a suspended state -- for such cases it is
46necessary to use enable_irq_wake().
45 47
46Note that the IRQF_NO_SUSPEND flag affects the entire IRQ and not just one 48Note that the IRQF_NO_SUSPEND flag affects the entire IRQ and not just one
47user of it. Thus, if the IRQ is shared, all of the interrupt handlers installed 49user of it. Thus, if the IRQ is shared, all of the interrupt handlers installed
@@ -110,8 +112,9 @@ any special interrupt handling logic for it to work.
110IRQF_NO_SUSPEND and enable_irq_wake() 112IRQF_NO_SUSPEND and enable_irq_wake()
111------------------------------------- 113-------------------------------------
112 114
113There are no valid reasons to use both enable_irq_wake() and the IRQF_NO_SUSPEND 115There are very few valid reasons to use both enable_irq_wake() and the
114flag on the same IRQ. 116IRQF_NO_SUSPEND flag on the same IRQ, and it is never valid to use both for the
117same device.
115 118
116First of all, if the IRQ is not shared, the rules for handling IRQF_NO_SUSPEND 119First of all, if the IRQ is not shared, the rules for handling IRQF_NO_SUSPEND
117interrupts (interrupt handlers are invoked after suspend_device_irqs()) are 120interrupts (interrupt handlers are invoked after suspend_device_irqs()) are
@@ -120,4 +123,13 @@ handlers are not invoked after suspend_device_irqs()).
120 123
121Second, both enable_irq_wake() and IRQF_NO_SUSPEND apply to entire IRQs and not 124Second, both enable_irq_wake() and IRQF_NO_SUSPEND apply to entire IRQs and not
122to individual interrupt handlers, so sharing an IRQ between a system wakeup 125to individual interrupt handlers, so sharing an IRQ between a system wakeup
123interrupt source and an IRQF_NO_SUSPEND interrupt source does not make sense. 126interrupt source and an IRQF_NO_SUSPEND interrupt source does not generally
127make sense.
128
129In rare cases an IRQ can be shared between a wakeup device driver and an
130IRQF_NO_SUSPEND user. In order for this to be safe, the wakeup device driver
131must be able to discern spurious IRQs from genuine wakeup events (signalling
132the latter to the core with pm_system_wakeup()), must use enable_irq_wake() to
133ensure that the IRQ will function as a wakeup source, and must request the IRQ
134with IRQF_COND_SUSPEND to tell the core that it meets these requirements. If
135these requirements are not met, it is not valid to use IRQF_COND_SUSPEND.