Re: [Xenomai-core] Cannot end interrupt from user space: add rt_intr_end call ?

[Philippe Gerum <rpm@xenomai.org>]

Tomas Kalibera wrote:
> 
> Hi Philippe,
> 
> thank you for the patch !
> 
>> 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,
>>   
> If I read the sources correctly, for "edge" and "simple" interrupt,
> xnarch_end_irq() calls nothing, for "percpu" it calls ->eoi() . For
> "level", "fasteoi", and "demux", it calls ->unmask().
> 
> 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.

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