Missing some interrupts

[wael showair]

Benjamin Herrenschmidt wrote:
> 
> 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 How can i achieve this? how can i ack the interrupt b 4 calling the
> handler?
> 
> 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.
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
> 
> 

-- 
View this message in context: http://www.nabble.com/Missing-some-interrupts-tp23901807p23906763.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.