From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <48118469.2040000@domain.hid> Date: Fri, 25 Apr 2008 09:12:41 +0200 From: Philippe Gerum MIME-Version: 1.0 References: <48100D81.9090109@domain.hid> <481048A0.7040101@domain.hid> <4810B072.6050603@domain.hid> <4810B7B4.9070309@domain.hid> <4810DC9E.9040004@domain.hid> In-Reply-To: <4810DC9E.9040004@domain.hid> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: Philippe Gerum Subject: Re: [Xenomai-core] Cannot end interrupt from user space: add rt_intr_end call ? Reply-To: rpm@xenomai.org List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Tomas Kalibera Cc: xenomai-core Tomas Kalibera wrote: > >>> So calling rt_intr_enable from user space would not always do the same >>> as xnarch_end_irq from the kernel, wouldn't it ? >>> >> >> No it would not, and this is what we want. The patch makes sure that >> calling >> rt_intr_enable/disable() will actually unmask/mask the interrupt at >> PIC level, >> regardless of how the normal ack/handle/end process works for that >> interrupt. >> >> > OK, and this is the problem why I started calling for rt_intr_end. In > order to use I_NOAUTOENA from user space correctly, I need to be able to > end the interrupt correctly from user space. And there is no function to > do this. > Call rt_intr_enable(), with the patch applied. This will work. > Tomas > > >>> Tomas >>> >>> >>> >>> Philippe Gerum wrote: >>> >>>> Tomas Kalibera wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> I think that when I handle interrupts from user space, I cannot >>>>> correctly use I_NOAUTOENA. The thing is that this flag in fact means >>>>> "do not call automatically xnarch_end_irq". The xnarch_end_irq call >>>>> usually maps to unmasking the interrupt, but not always - depending >>>>> on interrupt type (sometimes in eoi, sometimes is nop). >>>>> >>>>> I was thinking that it would be nice if I could call something like >>>>> "xnarch_end_irq" (i.e. rt_intr_end) from user space, so that I could >>>>> correctly use I_NOAUTOENA to control the flow of interrupts. >>>>> >>>>> >>>> What would this buy you? xnarch_irq_end() would still handle the >>>> unmasking logic >>>> depending on the interrupt type, because it knows how the interrupt was >>>> acknowledged in the first place -- in contrast, the application does >>>> not and >>>> should not. >>>> >>>> xnarch_end_irq() basically calls the ->unmask() method of the >>>> interrupt chip >>>> descriptor, which is the same as calling rt_intr_enable(). Before you >>>> do that, >>>> you may want to try the attached patch, which makes sure that >>>> rt_intr_enable/disable are eagerly routed to unmask/mask on x86 for >>>> post-2.6.18 >>>> kernels. That patch is expected to solve the "rt_intr_disable() not >>>> masking >>>> IO-APIC interrupt" issue we discussed earlier. >>>> >>>> >>>> >>>>> Cheers, >>>>> Tomas >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Xenomai-core mailing list >>>>> Xenomai-core@domain.hid >>>>> https://mail.gna.org/listinfo/xenomai-core >>>>> >>>>> >>>> >>> >> >> >> > > -- Philippe.