[PATCH] fix-lis302dl-isr-lock.patch

Andy Green andy at openmoko.com
Mon Mar 31 19:22:51 CEST 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| Am Mo  31. März 2008 schrieb Andy Green:
|> - gpg control packet
|> Somebody in the thread at some point said:
|>
|> | Isn't this common best practice for ISRs to lock the own interrupt (and
|>
|> I'm a bit wary of doing this with the edge-triggered interrupts on this
|> platform.  Some months ago one or another of the drivers I worked on
|> (maybe this one in its original form) had this edge-triggered stuff and
|> used that specific interrupt disable code.  It didn't work well and
|> under load an edge would missed if it came during the disabled period.
|> The result was a permanently stuck low interrupt line that never got
|> acknowledged.
|
| Ok, i have to look at the hw-details of GTA02 gmeters as well as CPU
specs to
| talk about it better than just nonsense. What i can say now: edge
triggered
| IRQs of different devices on same IRQ-line usually are evil. There's
no such
| thing as a singular edge, it's always followed/leaded by a level period
| that's possibly swallowing another edge (that is as long as IRQs are not
| synchronized by some common clock). I always would prefer level
trigger, and
| IRQ latched in requesting device and reset by "poll" of all devices on
this
| line while ISR.

No doubt it is true but we don't have that problem though... INT1 and
INT2 on the GTA02 A5 accels are logically driven by the same source.
And the two accells do not share an interrupt (they share an SPI bus tho
:-O ).

I suspect we have some other problem where edges can get missed by the
CPU if the interrupt source is disabled, but I didn't pin it down.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEUEARECAAYFAkfxHesACgkQOjLpvpq7dMq9RwCXXnddVtcjQf+Bccd8BvwrefsC
WACeK6mzKsbfmEAlY/80xi3fF6ge6rE=
=VvFR
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list