[Xenomai-help] Question about interrupt propagation to Linux

[Xenomai-help] Question about interrupt propagation to Linux

[Bernhard Walle]

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

Hello,

I have a question about interrupt propagation to Linux with the
XN_ISR_PROPAGATE return value in the real-time interrupt handler.

My question is: is the particular IRQ (not other IRQs) that is handled
by this ISR re-enabled after the *RT* ISR finished or is it re-enabled
after the *Linux* ISR has finished. In my understanding the interrupt
cannot be enabled after the RT-ISR because then the RT-ISR handler
would be called again and the Linux ISR would never have a chance to
run.

Thanks.


Regards,
  Bernhard
-- 
At least Microsoft offers updates to keep your selection of bugs fresh.
        -- Alan Shutko, hating Corel even more, in asr

[-- Attachment #2: Type: application/pgp-signature, Size: 307 bytes --]

Re: [Xenomai-help] Question about interrupt propagation to Linux

[Dmitry Adamushko]

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

Hello Bernhard,


I have a question about interrupt propagation to Linux with the
> XN_ISR_PROPAGATE return value in the real-time interrupt handler.
>
> My question is: is the particular IRQ (not other IRQs) that is handled
> by this ISR re-enabled after the *RT* ISR finished or is it re-enabled
> after the *Linux* ISR has finished. In my understanding the interrupt
> cannot be enabled after the RT-ISR because then the RT-ISR handler
> would be called again and the Linux ISR would never have a chance to
> run.


You are right. The IRQ line is not re-enabled upon getting XN_ISR_PROPAGATE.
It will be re-enabled by linux domain at some point later when the former
one eventually gets control (i.e. when there are no activities in the
primary domain).
That said, the interrupts from a device being controlled by the RT driver
(ISR in the primary domain) can't be seen in the mean time. Hence, there are
no more deterministic guarantees for RT device handling.

The alternative approach is as described here :

https://mail.gna.org/public/xenomai-core/2005-11/msg00012.html

It's possible to apply some optimisation :

1) speedo_suspend_interrupt() should return an indication whether it's
interested in this IRQ (i.e. whether it was rised by a dedicated device) ;

2) arti_irq_trampoline()  should set "shared" up only when one of the
suspend_handler() (like e.g. == speedo_suspend_interrupt() ) have denoted
its interest;

3) this way, the IRQ is not propagated down to the linux domain when nobody
there is interested.

The patch addresses RTAI and 2.4 kernel but it's easily applicable to recent
Xenomai.



Thanks.
>
>
> Regards,
>   Bernhard
> --
> At least Microsoft offers updates to keep your selection of bugs fresh.
>         -- Alan Shutko, hating Corel even more, in asr
>
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
>
>
>
>


-- 
Best regards,
Dmitry Adamushko

[-- Attachment #2: Type: text/html, Size: 2956 bytes --]