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


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to