Jan Kiszka wrote:
Anders Blomdell wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Dmitry Adamushko wrote:
this is the final set of patches against the SVN trunk of 2006-02-03.
It addresses mostly remarks concerning naming (XN_ISR_ISA ->
XN_ISR_EDGE), a few cleanups and updated comments.
Functionally, the support for shared interrupts (a few flags) to the
Not directly your fault: the increasing number of return flags for IRQ
handlers makes me worry that they are used correctly. I can figure out
what they mean (not yet that clearly from the docs), but does someone
else understand all this:
ISR says it has handled the IRQ, and does not want any propagation to
take place down the pipeline. IOW, the IRQ processing stops there.
This says that the interrupt will be ->end'ed at some later time
(perhaps in the interrupt handler task)
ISR says it wants the IRQ to be propagated down the pipeline. Nothing
is said about the fact that the last ISR did or did not handle the IRQ
locally; this is irrelevant.
This says that the interrupt will eventually be ->end'ed by some later
stage in the pipeline.
ISR requests the interrupt dispatcher to re-enable the IRQ line upon
return (cumulable with HANDLED/CHAINED).
This says that the interrupt will be ->end'ed when this interrupt
This new one comes from Dmitry's patch for shared IRQ support AFAICS.
It would mean to continue processing the chain of handlers because the
last ISR invoked was not concerned by the outstanding IRQ.
Sounds like RT_INTR_CHAINED, except that it's for the current pipeline
Now for the quiz question (powerpc arch):
1. Assume an edge triggered interrupt
2. The RT-handler returns RT_INTR_ENABLE | RT_INTR_ENABLE (i.e. shared
Kind of redundant. What did you really mean?
interrupt, but no problem since it's edge-triggered)
3. Interrupt gets ->end'ed right after RT-handler has returned
4. Linux interrupt eventually handler starts its ->end() handler:
if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS)))
// Next interrupt occurs here!
Wouldn't this lead to a lost interrupt? Or am I overly paranoid?
My distinct feeling is that the return value should be a scalar and not
That's a good idea: only provide valid and reasonable flag combinations
to the user!
I would vote for the (already scheduled?) extension to register an
optimised IRQ trampoline in case there is actually no sharing taking
place. This would also make the "if (irq == XNARCH_TIMER_IRQ)" path
I support that. Shared interrupts should be handled properly by Xeno
since such - I'd say "last resort" - configuration could be needed;
this said, we should not see this as the rule but rather as the
exception, since this is basically required to solve some underlying
hw limitations wrt interrupt management, and definitely has a
significant cost on processing each shared IRQ wrt determinism.
Incidentally, there is an interesting optimization on the project's
Is this todo list accessible anywhere?
I did not know of such interesting plans as well. Maybe we should start
using more of the feature GNA provide to us (task lists?)...
that would allow non-RT interrupts to be masked at IC level when
the Xenomai domain is active. We could do that on any arch with
civilized interrupt management, and that would prevent any
asynchronous diversion from the critical code when Xenomai is running
RT tasks (kernel or user-space). Think of this as some hw-controlled
interrupt shield. Since this feature requires to be able to
individually mask each interrupt source at IC level, there should be
no point in sharing fully vectored interrupts in such a configuration
anyway. This fact also pleads for having the shared IRQ support as a
This concept sound really thrilling. I already wondered if this is
possible after seeing how many non-RT IRQ stubs can hit between an RT
event and the RT task invocation: HD, network, keyboard, mouse, sound,
graphic card - and if you are "lucky", a lot of them chain up at the
same time. But I thought that such disabling is too costly for being
used at every domain switch. Is it not?
It all depends on the underlying arch. I started to think about this when
with the Blackfin, which provides an efficient and fine-grained control over the
interrupt system (hey, it's a DSP after all). Anders recently brought up the issue
too, waking up the sleeper. Of course, one would not want to try that with a 8259
chip over x86...
Xenomai-core mailing list