[Xenomai-core] Re: Move rtdm_irq_enable close to rtdm_irq_request

[Jan Kiszka <jan.kiszka@domain.hid>]

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

Dmitry Adamushko wrote:
> Sharing itself is no problem: if your request an IRQ with XN_ISR_SHARED
>> set but the nucleus is not able to actually assign it to more than one
>> driver, the second request will simply fail. I see no need to deny the
>> first request or even break the driver build.
>>
> Problematic is only the handling of edge-triggered shared IRQs with the
>>
> level-triggered handler (can cause lost IRQs). Probably a runtime check
>> is best as we cannot control the configuration of, e.g., external RTDM
>> drivers. What about the attached patch?
> 
> 
> It's ok with me.
> 
> I just thought maybe it's better to break a build and alert a user earlier
> (although, it's kind of inderect alert indeed) when the host environment
> (Xeno) doesn't support a requested mode (e.g. SHARED_EDGE).
> 
> If such a driver (that requires EDGE_SHARED) is a part of the mainline,
> then
> we may use Kconfig features either (1) to make it "selectable" only when
> XENO_OPT_SHIRQ_EDGE is on or (2) select XENO_OPT_SHIRQ_EDGE automatically
> when the driver has been choosen.
> 

Let's do both, the runtime check + some Kconfig magic for mainline drivers.

For the latter we should reorganise the config options slightly.
XENO_OPT_SHIRQ_* may better depend on a new switch XENO_OPT_SHIRQ. Thus,
when the user enables IRQ sharing and some in-tree driver requires
edge-triggering support, XENO_OPT_SHIRQ_EDGE will be selected by the
driver's Kconfig: select XENO_OPT_SHIRQ_EDGE if XENO_OPT_SHIRQ. With the
current layout it would look like this: select XENO_OPT_SHIRQ_EDGE if
XENO_OPT_SHIRQ_LEVEL. That may appear illogical to the user.

Jan


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