From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4656CFFA.1020001@domain.hid> Date: Fri, 25 May 2007 14:00:58 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4656C2D0.7000705@domain.hid> <4656C583.5040303@domain.hid> <1180094224.20410.39.camel@domain.hid> In-Reply-To: <1180094224.20410.39.camel@domain.hid> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig71854E91E2D1CE2CFC00095D" Sender: jan.kiszka@domain.hid Subject: Re: [Xenomai-help] Problem with interrupt enabling List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: rpm@xenomai.org Cc: Xenomai-help@domain.hid This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig71854E91E2D1CE2CFC00095D Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable 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=20 >>> interrupt. I use a rtdm_irq_request, followed by a rtdm_irq_enable. T= his=20 >> 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=20 >>> processed. >>> After adding an extra rtdm_irq_enable to the ISR the interrupts are=20 >>> processed. When I look at the other drivers I don't see this. Is this= =20 >>> needed, or is there a bug/feature in the interrupt handling on my pla= tform? >>> (I use a MVME3100 with a ppc8540 processor and openPIC interrupt=20 >>> 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 !=3D end IRQ), and indicates = that >> something else is broken, maybe in Xenomai. >> >=20 > Xenomai is not involved at this level, it's the I-pipe business here. A= s 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 stag= e > 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. >=20 > 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. >=20 > Next powerpc patches should not require this, thanks to the genirq laye= r > which helps differentiating interrupt flows in a much simpler way. >=20 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 --------------enig71854E91E2D1CE2CFC00095D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGVs/6niDOoMHTA+kRAlxDAJ9HNYRAfHVAv/bE6Doe4fZhS93IzgCeOWpe GAuzjsDSbLxyTrCZRaJPMx8= =rY4/ -----END PGP SIGNATURE----- --------------enig71854E91E2D1CE2CFC00095D--