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

[Jan Kiszka <jan.kiszka@domain.hid>]

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

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.

>> 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.
>>
>> Jan
>>
> 
> 

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]