Skip to content
Commit 21e37c45 authored by James Morse's avatar James Morse
Browse files

UNTESTED firmware: arm_sdei: Add support for binding interrupts as SDE events



The SDEI API provides a way to bind an interrupt to an event number. This
causes firmware to take ownership of the interrupt, and deliver it as an
unmaskable SDE event.

This has certain side effects, all of which are the callers responsibility:
If your irq was level triggered, you are still responsible for notifying
the device the interrupt has been handled, otherwise you will repeatedly
receive the same event. Firmware doesn't how to do this. If you can't do
this from the NMI-like SDE context, disable the event from your handler.
You should then schedule some work to notify the device, then re-enable the
event.

You should not bind a shared interrupt.

You must call free_irq() before sdei_interrupt_bind() and re- request_irq()
after unregistering the event. synchronize_irq() ensures no CPU is handling
this interrupt before we bind it.

If you use sdei_event_routing_set() to manipulate the routing of the bound
interrupt you should register a CPU hotplug notifier and ensure the
interrupt is not routed to a CPU that is being powered off. The irqchip
code no longer does this for you and once you use sdei_event_routing_set()
firmware doesn't either.

Resume from hibernate would need to re-bind any bound interrupts, but
the allocated event number is not guaranteed to be the same, meaning
the caller could no-longer enable/disable/unregister the event. To avoid
this bound-interrupts become unregistered and released when we resume
from hibernate. Your should register pm notifiers to handle this.

Signed-off-by: James Morse's avatarJames Morse <james.morse@arm.com>
parent a4f02645
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment