Dispatch interrupts asynchroneously
This patch-set changes interrupt dispatching to happen asynchronously. This is a first step towards making API-calls interrupt safe. It also makes Epicardium more robust against a buggy payload as such a payload can no longer deadlock tasks which try to send interrupts (in such an instance, now they will be scheduled but never leave the IRQ queue).
chore(interrupts): Make api_interrupt_trigger() return void
api_interrupt_trigger() cannot fail except by a programmer error
(passing an invalid ID) in which case we should raise an assertion.
Thus, make it return
void instead of
fix(lifecycle): Don't trigger a reset during startup
This is a silent issue which I noticed during work in this patchset; we are sending a superfluous interrupt during boot. This patch changes this although it reduces readability of the code. I'd be ok with dropping it again if readability here is more important.
chore(interrupts): Move api into an epicardium module
Our buildsystem prevents implementing the task in
epicardium/api so I moved the interrupts API into an Epicardium module.
chore(interrupts): Fix all modules to use new api
Update code-base to use new API.
feat(interrupts): Dispatch interrupts asynchroneously
Instead of blocking the triggering task when core 1 is still busy handling the previous interrupt, offload interrupt dispatching into a separate task. This is the first step towards making API-calls interrupt safe.
Next to the async triggering, the synchroneous mechanism is retained for special cases where async does not work (e.g. because of spin-locks). Currently, there is only one such case when resetting core 1 (triggering EPIC_INT_RESET).
docs(interrupts): Document new interrupt dispatcher task