Handling MSI interrupts

[Matti Vaittinen]

Hello!

I am working with an asic that is controlled by CPU. With our current board
this asic sends interrupts to processor via single interrupt line. CPU sees
level active interrupt, and reads the reason(s) from asic's register. When
handler(s) have executed, the read interrupts are acked to asic, and if no
more interrupt(s) have ocurred on asic, this interrupt line is brought in
inactive state. If new (different type of) interrupts have occurred on
asic, the acking wont clean all interrupts from asic's register and asic
keeps the interrupt line activated. Thus CPU is interrupted again && this
process is done again && all interrupts are handled.

Now there is plans to make this asic to use PCIe, and MSI interrupts. Also
we hope to utilize the same driver(s) for this asic. So first idea would be
to implement this as:

1. asic generates irq
2. MSI interrupt is sent (to PCIe controller) and CPU is interrupted
3. CPU acks interrupt to PCIe controller.
4. isr reads the interrupt reason(s) from asic and handles interrupt(s)
5. isr acks the interrupts.

So is there a problem if new interrupt is generated between steps 4 and 5.
Do we lose this new interrupt because the isr is still running? So when the
isr acks interrupts to asic, it does not ack this new one because it had
not happened when the reasons were read at step 4?

I have read the MSI-HOWTO.txt and genirq guides, and even tried to read
some sources. However I have not found out solid answer. Is there some
de-facto method to do this so it works reliably?

Following section may contain errors, it is what I have guessed by reading
the sources - please kick me if it sounds stupid.

By reading the sources I have figured that the "interrupt-controller" for
MSI interrupts on processor does used handle_simple_irq as flow handler. If
I am correct, this does not "queue" interrupts in same fashion the
handle_edge_irq would do.

Does this mean that my fear is correct?

Br

Matti Vaittinen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130417/f4ddc8b2/attachment.html