Anders Blomdell wrote:
> While looking into how to implement sharing of interrupts between
> realtime and non-realtime domains (and applying Wolfgang Grandegger's
> patch [],
> which is necessary to make XN_ISR_ENABLE work at all on the PowerPC
> platform), I'm beginning to think that XN_ISR_CHAINED and XN_ISR_ENABLE
> are mutually exclusive, since if both are set, desc->handler->end will
> be called twice:
>   1. When the realtime isr handler returns
>   2. When the Linux domain calls it in __do_IRQ

Yes, those bits are semantically exclusive. Actually, I think passing
both bits could even cause deadlocks if the RT-IRQ is raised again
before the non-RT handler got a chance to clear the IRQ source in hardware.

> In the solution I have in mind at the moment, I will:
>   1. Add an extra iend handler argument to xnintr_init
>   2. If XN_ISR_ENABLE is returned from the isr handler,
>      replace desc->handler->end with the user supplied
>      iend handler.
> Hereby I hope to be able to handle interrupts shared between realtime
> and non-realtime domain, without having the realtime domain wait for all
> non-realtime interrupts to finish. This is the scenario I'm thinking of:
>   1. A non-RT interrupt occurs
>   2. The (RT) isr handler detects the non-RT interrupt,
>      disables further non-RT interrupts on that irq-vector, replaces

This remains vague to me. How precisely will you disable? I guess at
hardware level, i.e. in a (non-RT) device-specific way: switch off the
bit in some hardware register that says "this device can produce IRQs",

>      desc->handler->end with the user supplied iend handler,
>      returns XN_ISR_CHAINED | XN_ISR_ENABLE.
>   3. RT interrupts are serviced by the (RT) isr handler,
>      returns XN_ISR_ENABLE
>   4. The Linux domain get a chance to run the chained interrupt,
>      and eventually calls desc->handler->end (supplied iend handler)
>   5. The iend handler reenables non-RT interrupts.

Then this would switch on that bit again? Note that this may require to
synchronise the hardware access with parts of the non-RT driver.

Meanwhile I recalled that my hack to realise IRQ sharing between a RT
device and a non-RT eepro100 is filed on a public archive:

> Comments on the above are most welcome!


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to