Missing some interrupts

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.

do u have any suggestions to solve this problem? i want to make sure that i can receive 10 interrupts

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

_______________________________________________
Linuxppc-dev mailing list
[email protected]
https://lists.ozlabs.org/listinfo/linuxppc-dev

Quoted 17 lines · wael showair

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.

Quoted 2 lines

do u have any suggestions to solve this problem? i want to make sure that i can receive 10 interrupts

Don't do a printk() with interrupts disabled. A printk() takes 1.5ms on a mpc5200.

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.

Quoted 13 lines · wael showair

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?

Quoted 4 lines

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
[email protected]
https://lists.ozlabs.org/listinfo/linuxppc-dev

Quoted 4 lines

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

so who is responsible for acking the interrupt?

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?

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?

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?

Quoted 1 line

So you don't need to worry too much about racing with new incoming

messages inside the

Quoted 12 lines

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
[email protected]
https://lists.ozlabs.org/listinfo/linuxppc-dev

Quoted from:
http://www.nabble.com/Missing-some-interrupts-tp23901807p23906326.html

Quoted 7 lines

Quoted 4 lines

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

much work (or interrupts) have been sent and react accordingly regardless of how many actual IRQ triggers came in via the OpenPIC.

Quoted 1 line

so who is responsible for acking the interrupt?

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

Quoted 2 lines

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.

Quoted 4 lines

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.

Quoted 2 lines

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.

Quoted 16 lines

Quoted 1 line

So you don't need to worry too much about racing with new incoming

messages inside the

Quoted 12 lines

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
[email protected]
https://lists.ozlabs.org/listinfo/linuxppc-dev

Quoted from:
http://www.nabble.com/Missing-some-interrupts-tp23901807p23906326.html

Quoted 8 lines · wael showair

Quoted 7 lines

Quoted 4 lines

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

Quoted 3 lines

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.

what about using the RT-Preempt Patch? i can see that it will convert Linux ti an RTOS.

i have check the function of do_IRQ: there is no ack called b 4 calling the handler but actually it does the following:

1. it gets the irq number using :

       irq = ppc_md.get_irq();

2. then it calls the handler :

	if (irq != NO_IRQ && irq != NO_IRQ_IGNORE) {
			generic_handle_irq(irq);
	} else if (irq != NO_IRQ_IGNORE)
		/* That's not SMP safe ... but who cares ? */
		ppc_spurious_interrupts++;

i have checked the function of generic_handle_irq where it is defined linux/irq.h & it calls the handler

so from the previous code the processor or the pic does not ack but they call my ISR handler.

i have also read the specs of my OpenPIC & found that:

"the interrupt handler executing on the processor should then acknowledge the interrupt by explicitly reading the IACK register.

The PIC unit
interprets this read as an interrupt acknowledge (IACK) cycle; in response, the PIC unit returns the vector associated with the
interrupt source to the interrupt handler routine."

"At the end of the interrupt the End Of Interrupt (EOI) register must be set"

So the processor neither reads this iack register nor the handler set the EOI register.