Anders Blomdell wrote: > Philippe Gerum wrote: >> Jan Kiszka wrote: >> >>> Wolfgang Grandegger wrote: >>> >>>> Hello, >>>> >>>> Dmitry Adamushko wrote: >>>> >>>>> Hi, >>>>> >>>>> 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: >>> >>> - RT_INTR_HANDLED >> >> >> 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) > >>> - RT_INTR_CHAINED >> >> >> 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. > >>> - RT_INTR_ENABLE >> >> >> 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 > handler returns. > >> >>> - RT_INTR_NOINT >>> >> >> 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 > stage? > > 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: > local_irq_save_hw(flags); > if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) > ipipe_irq_unlock(irq); > // Next interrupt occurs here! > __ipipe_std_irq_dtype[irq].end(irq); > local_irq_restore_hw(flags); > > > 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 > a set! 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 >>> obsolete. >> >> >> 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 >> todo list > 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 >> build-time option. > 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? Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
