Re: [Xenomai-core] [RFC] support for sharing IRQs

[Philippe Gerum <rpm@xenomai.org>]

Jan Kiszka wrote:
> 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 [1] may succeed with an irq registration request in case
>>another driver [2] already holds this line but both [1] and [2] 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?
> 

While we are at it, we could just move the HAL's trampoline part to the 
arch/system.h support. Two things to keep in mind: Adeos does not provide 
cookies (yeah, what a pity), but passes an IRQ number the xnarch level doesn't 
grok. Some low-level prototypes would have to be fixed and the cookie array 
moved, but basically, getting rid of the initial trampoline seems like a good 
idea since it brings nothing in the picture.

> Jan
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core


-- 

Philippe.