Dispatch interrupts asynchroneously
Compare changes
+ 22
− 19
@@ -14,31 +14,34 @@ Epicardium
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).
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 int
.
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.
Our buildsystem prevents implementing the task in epicardium/api
so I moved the interrupts API into an Epicardium module.
Update code-base to use new API.
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 ...