Dmitry Adamushko wrote: > Hi Jan, > >> I have some code hanging around here which implements IRQ sharing at >> skin level for an experimental in-house development over Xenomai. The >> code is smart enough to register an IRQ sharing trampoline handler only >> in case sharing is actually practiced for a specific line. > > Could you be a bit more specific on what is meant by "...sharing is > actually practiced for a specific line"?
Ok, one have to remind that my existing code is built on top of the non-sharing xnintr_xxx API. This means that I had to define a trampoline ISR which does the loop over all registered end-user ISRs. And this intermediate handler is only involved when A) the IRQ is sharable and B) there is actually more than one ISR registered for it. This "smartness" becomes obsolete when we embed a doubly-linked list into xnintr_t and already iterate over it in xnintr_irq_handler(). > > To my knowledge, the matter is only about whether a certain device (driver) > permits the earlier obtained irq line to be shared with other devices. > i.e. a driver  may succeed with an irq registration request in case > another driver  already holds this line but both  and  have > specified a SA_SHIRQ flag. Yep. > > >> I think it would be possible to break this out and generate a mainline >> patch. Anyway, the question for me is where to put this best, at skin >> (RTDM?) or at nucleus level? Both is technically feasible, but which way >> is desired? (I would vote for the nucleus...) > > If we have a policy that all the drivers should be implemented on top of > RTDM, then, it can be done there. If no (and I guess so), this feature > should be common and I'd vote for the nucleus. Drivers should be built over RTDM, that's true. But there may still be driver-like applications, also in user space that attach directly to the IRQs via the various skin APIs. I think it would be good to let them live side-by-side with RTDM drivers or other IRQ-using applications. > It seems to me now, that some parts of the hal will be involved > (rthal_irq_request/release()) since the nucleus itself doesn't keep track > of registered irqs. That's true. And it also raises another question to me: why do we have those two different IRQ models? The HAL only one handler per IRQ which get called with the triggering IRQ number. That handler will call the nucleus with an attached cookie. And on the other side is the nucleus which works with a xnintr_t per IRQ. The xnintr_irq_handler() deals with things like re-enabling IRQs, rescheduling, etc. I'm asking as this abstraction adds one trampoline call (at HAL level), thus may lead to more I-cache misses. Isn't it worth considering some HAL mechanisms based on more #defines and static inlines in this regard? Jan
Description: OpenPGP digital signature