Re: [PATCH 1/3] irq / PM: New driver interface for wakeup interruptsn
From: Thomas Gleixner
Date: Fri Aug 01 2014 - 09:43:34 EST
On Fri, 1 Aug 2014, Rafael J. Wysocki wrote:
> OK, I guess "IRQ_HANDLED from a wakeup interrupt" may be interpreted as
> IRQ_HANDLED_PMWAKE. On the other hand, if that's going to be handled in
> handle_irq_event_percpu(), then using a special return code would save us
> a brach for IRQ_HANDLED interrupts. We could convert it to IRQ_HANDLED
> immediately then.
We can handle it at the end of the function by calling
note_interrupt() unconditionally do the following there:
if (suspended) {
if (ret == IRQ_NONE) {
if (shared)
yell_and_abort_or_resume();
} else {
abort_or_resume();
}
}
if (noirqdebug)
return;
> OK, I'll take a stab at the IRQF_SHARED thing if you don't mind.
Definitely not :)
> Here's my current understanding of what can be done for IRQF_NO_SUSPEND.
>
> In suspend_device_irqs():
>
> (1) If all actions in the list have the same setting (eg. IRQF_NO_SUSPEND unset),
> keep the current behavior.
> (2) If the actions have different settings:
> - Actions with IRQF_NO_SUSPEND set are not modified.
> - Actions with IRQF_NO_SUSPEND unset are switched over to a stub handler.
> - IRQS_SUSPEND_MODE (new flag) is set for the IRQ.
Can we please do that in setup_irq() and let the shared ones always
run through the stub? That keeps suspend/resume_device_irqs() simple.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/