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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
