Re: [Xenomai-help] Problem with interrupt enabling

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2578 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]