genirq / PM: describe IRQF_COND_SUSPEND
With certain restrictions it is possible for a wakeup device to share
an IRQ with an IRQF_NO_SUSPEND user, and the warnings introduced by
commit cab303be91
are spurious. The new
IRQF_COND_SUSPEND flag allows drivers to tell the core when these
restrictions are met, allowing spurious warnings to be silenced.
This patch documents how IRQF_COND_SUSPEND is expected to be used,
updating some of the text now made invalid by its addition.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
hifive-unleashed-5.1
parent
2c7af5ba65
commit
7438b633a6
|
@ -112,8 +112,9 @@ any special interrupt handling logic for it to work.
|
||||||
IRQF_NO_SUSPEND and enable_irq_wake()
|
IRQF_NO_SUSPEND and enable_irq_wake()
|
||||||
-------------------------------------
|
-------------------------------------
|
||||||
|
|
||||||
There are no valid reasons to use both enable_irq_wake() and the IRQF_NO_SUSPEND
|
There are very few valid reasons to use both enable_irq_wake() and the
|
||||||
flag on the same IRQ.
|
IRQF_NO_SUSPEND flag on the same IRQ, and it is never valid to use both for the
|
||||||
|
same device.
|
||||||
|
|
||||||
First of all, if the IRQ is not shared, the rules for handling IRQF_NO_SUSPEND
|
First of all, if the IRQ is not shared, the rules for handling IRQF_NO_SUSPEND
|
||||||
interrupts (interrupt handlers are invoked after suspend_device_irqs()) are
|
interrupts (interrupt handlers are invoked after suspend_device_irqs()) are
|
||||||
|
@ -122,4 +123,13 @@ handlers are not invoked after suspend_device_irqs()).
|
||||||
|
|
||||||
Second, both enable_irq_wake() and IRQF_NO_SUSPEND apply to entire IRQs and not
|
Second, both enable_irq_wake() and IRQF_NO_SUSPEND apply to entire IRQs and not
|
||||||
to individual interrupt handlers, so sharing an IRQ between a system wakeup
|
to individual interrupt handlers, so sharing an IRQ between a system wakeup
|
||||||
interrupt source and an IRQF_NO_SUSPEND interrupt source does not make sense.
|
interrupt source and an IRQF_NO_SUSPEND interrupt source does not generally
|
||||||
|
make sense.
|
||||||
|
|
||||||
|
In rare cases an IRQ can be shared between a wakeup device driver and an
|
||||||
|
IRQF_NO_SUSPEND user. In order for this to be safe, the wakeup device driver
|
||||||
|
must be able to discern spurious IRQs from genuine wakeup events (signalling
|
||||||
|
the latter to the core with pm_system_wakeup()), must use enable_irq_wake() to
|
||||||
|
ensure that the IRQ will function as a wakeup source, and must request the IRQ
|
||||||
|
with IRQF_COND_SUSPEND to tell the core that it meets these requirements. If
|
||||||
|
these requirements are not met, it is not valid to use IRQF_COND_SUSPEND.
|
||||||
|
|
Loading…
Reference in New Issue