Re: [Xenomai-core] Re: [PATCH] Shared interrupts (ready to merge)

[Philippe Gerum <rpm@xenomai.org>]

Anders Blomdell wrote:
> Jan Kiszka wrote:
> 
>> Philippe Gerum wrote:
>>
>>> Jan Kiszka wrote:
>>>
>>>> Dmitry Adamushko wrote:
>>>>
>>>>
>>>>> ...
>>>>> This said, I'm going to publish the shirq patch (after finalizing ISR
>>>>> return
>>>>> bits,
>>>>> where I still have some doubts) without enable/disable nesting 
>>>>> support.
>>>>> It can be supported at some point of time later, if it's really 
>>>>> needed.
>>>>>
>>>>
>>>>
>>>> Regarding enable/disable nesting and existing driver patterns: I
>>>> currently do the following on devices init via RTDM (and users may have
>>>> copied this):
>>>>
>>>> rtdm_irq_request(...);
>>>> <init_hardware, also clear pending IRQs of the device>
>>>> rtdm_irq_enable(...);
>>>>
>>>> But I do not disable the IRQ before rtdm_irq_free() again. Is this
>>>> unbalanced enabling still needed today? Is it even wrong these days?
>>>
>>>
>>> Looks unsafe, since nothing says that freeing the descriptor associated
>>> with some IRQ should disable this IRQ line at hw level. However, we
>>> would be correct to assume that no IRQ could happen after we have been
>>> asked to free its associated descriptor.
>>>
>>> Is
>>>
>>>> it arch-dependent?
>>>
>>>
>>> Nope. Both APIs are arch-agnostic anyway.
>>>
>>> I think the pattern dates back in RTAI times and was
>>>
>>>> needed for so far unused IRQs. Disabling them on device closure blocked
>>>> the line for later use under Linux.
>>>>
>>>
>>> We never had this problem with Xeno, since we always relied on the
>>> standard IRQ controllers defined by Linux for managing interrupt lines.
>>> IOW, Linux can undo what Xenomai did wrt IRQ line enabling/disabling.
>>>
>>
>>
>> So the enable is definitely needed and a disable on release should not
>> cause harm anymore? If that's the case, we could start re-introducing
>> rtdm_irq_disable before rtdm_irq_free again.
> 
> Except for interrupts shared between RT/non-RT, the don't need enable 
> (since they are enabled by Linux already), and probably doesn't fare 
> well with a final disable.
> 

That's the uncommon case by essence, for which a different set of rules already 
applies anyway.

>>
>>
>>>> I'm asking now in case we have to change the usage: we may better do it
>>>> early (e.g. with the introduction of Xenomai 2.1), so that the 
>>>> number of
>>>> surprises can be kept low when the underlying mechanisms get reworked
>>>> later.
>>>>


-- 

Philippe.