From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <4810DC9E.9040004@domain.hid>
Date: Thu, 24 Apr 2008 15:16:46 -0400
From: Tomas Kalibera <kalibera@domain.hid>
MIME-Version: 1.0
References: <48100D81.9090109@domain.hid> <481048A0.7040101@domain.hid>
	<4810B072.6050603@domain.hid> <4810B7B4.9070309@domain.hid>
In-Reply-To: <4810B7B4.9070309@domain.hid>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Xenomai-core] Cannot end interrupt from user space:
 add	rt_intr_end call ?
List-Id: "Xenomai life and development \(bug reports, patches,
	discussions\)" <xenomai.xenomai.org>
List-Unsubscribe: <https://mail.gna.org/listinfo/xenomai-core>,
	<mailto:xenomai-core-request@domain.hid>
List-Archive: </public/xenomai-core>
List-Post: <mailto:xenomai@xenomai.org>
List-Help: <mailto:xenomai-core-request@domain.hid>
List-Subscribe: <https://mail.gna.org/listinfo/xenomai-core>,
	<mailto:xenomai-core-request@domain.hid>
To: rpm@xenomai.org
Cc: xenomai-core <xenomai@xenomai.org>


>> 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.

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
>>>>
>>>>     
>>>>         
>>>   
>>>       
>>     
>
>
>