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

[Jan Kiszka <kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 1995 bytes --]

Philippe Gerum 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"?
>>
>> 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.
>>
>>
>>  > 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.
> 
> Actually, now that we have a decent driver model built in, I will
> enforce the rule that all Xenomai mainline drivers must be based on
> RTDM, because we do need such a common platform to prevent braindamage
> calling interfaces hysteria. This will be a good opportunity to see how
> flexible the thing is when confronted to the needs of various hw and
> semantics.
> 

So far the rtdm_irq_xxx API consists of pure static inlines. If we
decide to move IRQ sharing support only into that layer, it would
materialise into real code and another trampoline. So, I still vote for
a generic support at nucleus level. :)

Jan




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]