Re: [Xenomai-core] Are XN_ISR_CHAINED and XN_ISR_ENABLE mutually exclusive?

[Anders Blomdell <anders.blomdell@domain.hid>]

Anders Blomdell wrote:
> Jan Kiszka wrote:
> 
>> Anders Blomdell wrote:
>>
>>> While looking into how to implement sharing of interrupts between
>>> realtime and non-realtime domains (and applying Wolfgang Grandegger's
>>> patch [https://mail.gna.org/public/xenomai-core/2006-01/msg00233.html],
>>> 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.
> 
> My impression as well, but it's nowhere documented, nor enforced in the 
> code.
> 
>>
>>
>>> 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",
>> right?
> 
> Yes.
> 
>>
>>
>>>     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.
> 
> If the non-RT driver sets that bit in its ISR routine, yes. I have the 
> (overly optimistic?) view that the non-RT ISR only does whatever is 
> necessary to clear the interrupt and leaves the enable/disable bits 
> untouched.
Or perhaps the whole conceptis of no interest to others, and I should put this 
arbitration in the platform specific part (arch/ppc/platform/prpmc800.c) and 
consider the harrier chip as a cascaded interrupt controller, and handle it as such?

-- 

Anders Blomdell