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@gna.org
>>>>> https://mail.gna.org/listinfo/xenomai-core
>>>>>
>>>>>             
>>>>         
>>>     
>>
>>
>>   
> 
> 


-- 
Philippe.

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to