Re: [RFC/PATCH 0/16] Ops based MSI Implementation

[David Miller <davem@davemloft.net>]

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Mon, 29 Jan 2007 11:58:21 +1100

> Do you have some pointers to documentation on those sparc64
> interfaces ?

So I got things working on sparc64 with a one-liner to the current
upstream vanilla 2.6.20-rc7 :-)  It's not the best, but it works.

You can see it all at:

	kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6.git

Basically, I changed arch_teardown_msi_irq() to pass in the
PCI device pointer, that's it.

The rest is sparc64 specific stuff.

One thing that's disappointing is that this "MSI Queue" framework
sparc64 has really suggests a two-tiered interrupt handling scheme.
As I previously explained, on sparc64 you assosciated each MSI with a
queue, and you can attach multiple MSIs to a single queue.

The queue is what generates the interrupt, and in response to that
interrupt you process a ring of MSI descriptors in the queue.  The
descriptors have a bunch of very useful information which we have no
way to make use of currently, and in particular it has the MSI number
in each entry.

So what would be cool would be to be able to attach the IRQ
action entries to a list inside of the MSI queue.

Instead, what happens right now is that each queue has a single
MSI assosciated with it, and that's the interrupt.

The MSI descriptors have all sorts of useful information, such as a
system TICK timestamp (for profiling), the exact bus/dev/fn that
generated the MSI (for debugging), as well as the full MSI address,
data, and code values (for IRQ dispatch and PCI-E error message
processing).

I've tested tg3 with MSI on my Niagara, it seems to work well.
Unfortunately I don't have any MSI-X capable devices here, but
eventually I am sure I will.  I glanced over the MSI-X code and I see
no reason why it wouldn't work.