From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4402B4D3.4050606@domain.hid> Date: Mon, 27 Feb 2006 09:14:11 +0100 From: Anders Blomdell MIME-Version: 1.0 Subject: Re: [Xenomai-core] Re: [PATCH] Shared interrupts (ready to merge) References: <43FAF94C.4080709@domain.hid> <43FAFE58.5060201@domain.hid> <43FB480E.9020808@domain.hid> <43FB529B.3040207@domain.hid> <43FB6102.1070004@domain.hid> <43FDA8E2.5010806@domain.hid> <4401F8B4.9090707@domain.hid> <4401FE4A.7010603@domain.hid> <4401FFA6.3010204@domain.hid> In-Reply-To: <4401FFA6.3010204@domain.hid> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: xenomai@xenomai.org 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(...); >>> >>>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. > > >>>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. >>> -- Anders