Re: Missing some interrupts

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Sat, 2009-06-06 at 06:17 -0700, wael showair wrote:
> Hi All,
> i have a freescale board, that contains MPC8555 processor & DSP-core
> there is a GPIO connecting the DSP-core into an input pin of the OpenPIC of
> the MPC8555 processor.
> 
> i test one interrupt from the DSP-core to the MPC8555 processor where i
> configure this interrupt line to be edge-triggered (falling edge) & i
> receive it successfully 
> but 
> when i generate this interrupt 10 successive times using for loop
> i just receive 2 interrupts?
> 
> why can't i receive the 8 other interrupts?
> i print the value of every irq number inside do_IRQ & i found that i receive
> the DSP-interrupt just only twice.

That sounds normal... It all depends what you are doing in the interrupt
handler. If you are doing something for too long, you will "miss" some
interrupts, but that isn't necessarily a problem.

You cannot really rely on getting the exact same number of edge
interrupts that were emitted. At least not unless you have a hard RT
system and can guarantee that you'll always dequeue them fast enough.

Basically, what happens is that in a PIC like the MPIC, if one edge
interrupt is latched, and another one arrives before that first one has
been acked, then the second one is "subsumed", ie, there's only one
input latch.

That should however not be a problem if your driver is written properly.
The idea is that when you get the interrupt, you need to check your
device for -all- the work to do, not only one "item". For example, if
the device fills a ring buffer, you need to check for more than one
entry in there.

The only guarantee you have is that the interrupt will have been acked
before your handler is called. So if another interrupt happens while
your handler is running, you -will- be called again. So you don't need
to worry too much about racing with new incoming messages inside the
interrupt handler itself. But you need to be prepared to pick up more
than one item of work... whatever that is.

Cheers,
Ben.