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.


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to