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