disabling "double-calling" of level-driven interrupts

disabling "double-calling" of level-driven interrupts

[Luke Kenneth Casson Leighton]

hi, please respond cc direct, thank you.

a kind response from alan alerted me to investigate some issues
that we are having with the skyminder (arm 720 cirrus logic
"maverick" EDB7134 whatever).

something he said made me go "twitch" - the infrastructure involving
interrupts in the 2.6 kernel - that they can be called TWICE.

well, that's exactly what i am seeing happen - even when the
relevant INTSR1 bit is clear.

at the top of the interrupt service routine, i double-check the
bit of INTSR1 that caused the interrupt.

i find it to be clear.

doing an immediate return IRQ_HANDLED results in working code,
whereas before, the behaviour of our LCD was utterly unreliable.

[we have a communications protocol to a PIC, over the 8-bit port,
indicating where and what the PIC is to blop onto the LCD screen.
the protocol is variable-length-encoded: if it gets screwed,
for example by a double-interrupt adding in an extra character...]

so.

i have some questions.

1) _why_ am i getting double-interrupts, even under circumstances
   where i double-check the relevant INTSR1 bit and ONLY drop out
   of the interrupt service routine once that bit is cleared?

2) is there something i am supposed to do, some function i
   am supposed to call, which stops the interrupt handler from
   being double-called?

3) could i have got something wrong, is there some interrupt
   function i am supposed to write, which is _supposed_ to check
   for this condition?

4) could there be something missing from the CLPS711x irq.c which
   is supposed to be there?

5) other

many thanks for any assistance.

l.

-- 
--
<a href="http://lkcl.net">http://lkcl.net</a>
--

Re: disabling "double-calling" of level-driven interrupts

[Grant Coady]

On Sat, 7 May 2005 21:32:12 +0100, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:

>something he said made me go "twitch" - the infrastructure involving
>interrupts in the 2.6 kernel - that they can be called TWICE.
>
>well, that's exactly what i am seeing happen - even when the
>relevant INTSR1 bit is clear.
>
>at the top of the interrupt service routine, i double-check the
>bit of INTSR1 that caused the interrupt.
>
>i find it to be clear.
>
>doing an immediate return IRQ_HANDLED results in working code,
>whereas before, the behaviour of our LCD was utterly unreliable.

Isn't that the whole idea of level triggered interrupts?  Your 
device may not be the one asserting IRQ, if the IRQ is not yours, 
let it go and something else will check to see if the IRQ is theirs.

--Grant.