From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4401FE4A.7010603@domain.hid> Date: Sun, 26 Feb 2006 20:15:22 +0100 From: Philippe Gerum 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> In-Reply-To: <4401F8B4.9090707@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: > 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. > 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 > -- Philippe.