Re: Missing some interrupts

[wael showair <showair2003@yahoo.com>]

> > 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.
> 
> Yes, my system is a hard RT & i want to receive all the interrupts that
> have been generated exactly

No. Linux is not hard RT. You cannot rely on this in a reliable way,
if for any reason the kernel masks interrupt for too long, which can
happen, you'll see that sort of coalescing happening.

If you -really- can't do anything else, then use critical interrupts
but there is little if no support at all for them in linux. It's your
model that is wrong, you should be able to "poll" the device for how
much work (or interrupts) have been sent and react accordingly
regardless of how many actual IRQ triggers came in via the OpenPIC.

> so who is responsible for acking the interrupt? 

At the PIC level, they are acked by the core just before calling into
your handler.

> is there any API in the kernel should i call to do this ack? or 
> it is something Dependant on the device that generates the interrupt?

The PIC-level ack is done for you. I don't know what your DSP does.

> Actaully, the device in my case which is a DSP-core is toggles the
> outpin pin of its GPIO that is connected to the input pin of the
> OpenPIC, so how can 
> i ack this device? do u have any suggestions?

The Ack isn't your problem. Your model is wrong if you design assuming
you will receive all edge interrupts. Being careful about latencies
etc... (and making sure you toggle for long enough, btw, didn't think
about that one, check your MPIC specs) may improve how many of them you
actually receive, -but- you cannot guarantee that you'll get them all,
so even if you somewhat manager into most of your tests to get 100%,
you'll still have an unreliable system.

You must design your communication between the DSP and Linux such that
the interrupt is purely a wakeup call indicating there's work to do, and
some -other- mean for Linux to actually know how much work is to be
done, the actual number of interrupts is not a proper way to do so.

> So how can i achieve this step? how can i ack the interrupt b 4 i call
>  the handler? where can i do this in the kernel?

The kernel does it for you as I said. It's your communication model
that is flawed. Never -ever- rely on edge interrupts in ways that
require them not to be coalesced.

Cheers,
Ben.

> >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@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
> > 
> > 
> Quoted from: 
> http://www.nabble.com/Missing-some-interrupts-tp23901807p23906326.html


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