On Fri, 2007-05-25 at 15:05 +0200, Jan Kiszka wrote: > Philippe Gerum wrote: > > On Fri, 2007-05-25 at 14:00 +0200, Jan Kiszka wrote: > >> Philippe Gerum wrote: > >>> On Fri, 2007-05-25 at 13:16 +0200, Jan Kiszka wrote: > >>>> Johan Borkhuis wrote: > >>>>> Hello, > >>>>> > >>>>> I am trying to create an RTDM interrupt handler for an external > >>>>> interrupt. I use a rtdm_irq_request, followed by a rtdm_irq_enable. > >>>>> This > >>>> The rtdm_irq_enable is no longer required with RTDM revision 6 and > >>>> higher. But that's trunk, it's rev. 5 which still comes with Xenomai > >>>> 2.3.x. And the enable will also cause no harm with rev. 6. > >>>> > >>>>> caused one interrupt to be processed, but subsequent interrupts were > >>>>> not > >>>>> processed. > >>>>> After adding an extra rtdm_irq_enable to the ISR the interrupts are > >>>>> processed. When I look at the other drivers I don't see this. Is this > >>>>> needed, or is there a bug/feature in the interrupt handling on my > >>>>> platform? > >>>>> (I use a MVME3100 with a ppc8540 processor and openPIC interrupt > >>>>> controller). > >>>> What do you return with your IRQ handler? RTDM_IRQ_HANDLED? > >>>> > >>>> That explicit rtdm_irq_enable is not required by design, would rather be > >>>> a bug on certain platforms (where enable != end IRQ), and indicates that > >>>> something else is broken, maybe in Xenomai. > >>>> > >>> Xenomai is not involved at this level, it's the I-pipe business here. As > >> I would be careful with this judgement when reading further on... > >> > >>> a matter of fact, the current I-pipe/ppc implementation forces the slow > >>> ack path, i.e. disables the source and send EOI in the openpic code, > >>> because we don't want another IRQ from the same source before some stage > >>> has processed the current one. This is due to the deferred-by-design > >>> nature of IRQ handling introduced by the interrupt pipeline, which has > >>> raised some issues (namely interrupt storm) for level-triggered IRQs on > >>> some ppc hw, IIRC. > >>> > >>> Calling enable/end is thus needed to reactivate the IRQ source at some > >>> point, even if it's not required by any vanilla kernel configuration > >>> which may instead use the fast ack mode (i.e. send EOI only for > >>> level-triggered interrupts, no masking). > >> The RTDM API just like the nucleus interrupt layer is precisely about > >> removing this need from the driver/application developer. Thus, if you > >> say we need ending here because I-pipe can't help on this arch, we would > >> see a clear Xenomai bug. > > > > If you reread my post in the intended context, you should understand it > > as "the I-pipe is the only one responsible for handling the incoming > > interrupts", and the all time approach has been to mask them until they > > get processed (save the special exception if IRQ0 on x86 due to ISA bus > > sluggishness). In that context, it's a I-pipe issue (the masking), not a > > Xenomai one. > > > > Said differently, Xenomai has always assumed that the I-pipe did mask > > the incoming IRQ source while processing it, leaving the decision to > > unmask it to the driver's ISR, depending on its return value to the > > primary ISR handler in the nucleus. > > > >>> Next powerpc patches should not require this, thanks to the genirq layer > >>> which helps differentiating interrupt flows in a much simpler way. > >>> > >> But until then we need a fix. Can we patch rthal_irq_end() on PPC to > >> address this depending on the I-pipe version? > >> > > > > Looking at the code from rthal_irq_end() in v2.3.1, the presence of a > > ->end() handler would indeed cause it to be invoked first (before > > attempting ->enable() as a fallback option), which would end up in > > openpic_end_irq() from arch/ppc/syslib/open_pic.c. What I suspect now is > > that no regular action handler has been defined for this IRQ (i.e. no > > request_irq() on this source from the Linux world), and therefore this > > code would lead to a nop. > > > > In which case, it would be an I-pipe bug, since there is no reason to > > prevent the real-time domain from using an IRQ Linux does not care of. > > OK, if Xenomai or I-pipe -- we agree it's a bug, not a temporary > shortcoming. :)
Clearly, yes. > > Jan > -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
