* [Xenomai-core] Cannot end interrupt from user space: add rt_intr_end call ? @ 2008-04-24 4:33 Tomas Kalibera 2008-04-24 8:45 ` Philippe Gerum 0 siblings, 1 reply; 6+ messages in thread From: Tomas Kalibera @ 2008-04-24 4:33 UTC (permalink / raw) To: xenomai-core 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. Cheers, Tomas ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-core] Cannot end interrupt from user space: add rt_intr_end call ? 2008-04-24 4:33 [Xenomai-core] Cannot end interrupt from user space: add rt_intr_end call ? Tomas Kalibera @ 2008-04-24 8:45 ` Philippe Gerum 2008-04-24 16:08 ` Tomas Kalibera 0 siblings, 1 reply; 6+ messages in thread From: Philippe Gerum @ 2008-04-24 8:45 UTC (permalink / raw) To: Tomas Kalibera; +Cc: xenomai-core [-- Attachment #1: Type: text/plain, Size: 1442 bytes --] 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. [-- Attachment #2: unconditionally-apply-irq-enable-disable-requests-to-pic.patch --] [-- Type: text/x-diff, Size: 1666 bytes --] Index: include/asm-x86/wrappers_32.h =================================================================== --- include/asm-x86/wrappers_32.h (revision 3708) +++ include/asm-x86/wrappers_32.h (working copy) @@ -163,8 +163,8 @@ #define rthal_irq_chip_end(irq) rthal_irq_chip_enable(irq) #else /* >= 2.6.19 */ -#define rthal_irq_chip_enable(irq) ({ rthal_irq_descp(irq)->chip->enable(irq); 0; }) -#define rthal_irq_chip_disable(irq) ({ rthal_irq_descp(irq)->chip->disable(irq); 0; }) +#define rthal_irq_chip_enable(irq) ({ rthal_irq_descp(irq)->chip->unmask(irq); 0; }) +#define rthal_irq_chip_disable(irq) ({ rthal_irq_descp(irq)->chip->mask(irq); 0; }) #define rthal_irq_chip_end(irq) ({ rthal_irq_descp(irq)->ipipe_end(irq, rthal_irq_descp(irq)); 0; }) typedef irq_handler_t rthal_irq_host_handler_t; Index: include/asm-x86/wrappers_64.h =================================================================== --- include/asm-x86/wrappers_64.h (revision 3708) +++ include/asm-x86/wrappers_64.h (working copy) @@ -31,8 +31,8 @@ #define rthal_irq_descp(irq) (irq_desc + irq) #define rthal_irq_desc_status(irq) (rthal_irq_descp(irq)->status) -#define rthal_irq_chip_enable(irq) ({ rthal_irq_descp(irq)->chip->enable(irq); 0; }) -#define rthal_irq_chip_disable(irq) ({ rthal_irq_descp(irq)->chip->disable(irq); 0; }) +#define rthal_irq_chip_enable(irq) ({ rthal_irq_descp(irq)->chip->unmask(irq); 0; }) +#define rthal_irq_chip_disable(irq) ({ rthal_irq_descp(irq)->chip->mask(irq); 0; }) #define rthal_irq_chip_end(irq) ({ rthal_irq_descp(irq)->ipipe_end(irq, rthal_irq_descp(irq)); 0; }) typedef irq_handler_t rthal_irq_host_handler_t; ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-core] Cannot end interrupt from user space: add rt_intr_end call ? 2008-04-24 8:45 ` Philippe Gerum @ 2008-04-24 16:08 ` Tomas Kalibera 2008-04-24 16:39 ` Philippe Gerum 0 siblings, 1 reply; 6+ messages in thread From: Tomas Kalibera @ 2008-04-24 16:08 UTC (permalink / raw) To: rpm; +Cc: xenomai-core 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 ? 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 >> >> > > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-core] Cannot end interrupt from user space: add rt_intr_end call ? 2008-04-24 16:08 ` Tomas Kalibera @ 2008-04-24 16:39 ` Philippe Gerum 2008-04-24 19:16 ` Tomas Kalibera 0 siblings, 1 reply; 6+ messages in thread From: Philippe Gerum @ 2008-04-24 16:39 UTC (permalink / raw) To: Tomas Kalibera; +Cc: xenomai-core 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-core] Cannot end interrupt from user space: add rt_intr_end call ? 2008-04-24 16:39 ` Philippe Gerum @ 2008-04-24 19:16 ` Tomas Kalibera 2008-04-25 7:12 ` Philippe Gerum 0 siblings, 1 reply; 6+ messages in thread From: Tomas Kalibera @ 2008-04-24 19:16 UTC (permalink / raw) To: rpm; +Cc: xenomai-core >> 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 >>>> >>>> >>>> >>> >>> >> > > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-core] Cannot end interrupt from user space: add rt_intr_end call ? 2008-04-24 19:16 ` Tomas Kalibera @ 2008-04-25 7:12 ` Philippe Gerum 0 siblings, 0 replies; 6+ messages in thread From: Philippe Gerum @ 2008-04-25 7:12 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2008-04-25 7:12 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-04-24 4:33 [Xenomai-core] Cannot end interrupt from user space: add rt_intr_end call ? Tomas Kalibera 2008-04-24 8:45 ` Philippe Gerum 2008-04-24 16:08 ` Tomas Kalibera 2008-04-24 16:39 ` Philippe Gerum 2008-04-24 19:16 ` Tomas Kalibera 2008-04-25 7:12 ` Philippe Gerum
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.