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>
--
On Sat, 7 May 2005 21:32:12 +0100, Luke Kenneth Casson Leighton <[email protected]> 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.