> > 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. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev