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. > > 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? Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
