Jeff Garzik wrote:
> Has anybody done any work, or put any thought, into MSI support?
>
> Would things massively break if I set up MSI manually in the driver?
>
> I heard rumblings on lkml that Intel has done some work internally w/
> MSI support in Linux, but that doesn't help me much without further
> details ;-)
I found this in my archives:
================================
Subject: RE: [PATCH] 2.5.68 Fix IO_APIC IRQ assignment bug
Date: Mon, 21 Apr 2003 09:34:34 -0700
From: "Nakajima, Jun" <[email protected]>
<SNIP>
After (vector-based)
CPU0 CPU1
0: 709682 0 IO-APIC-edge timer
2: 0 0 XT-PIC cascade
9: 0 0 IO-APIC-level acpi
14: 4988 1 IO-APIC-edge ide0
15: 10 1 IO-APIC-edge ide1
177: 78 0 IO-APIC-level uhci-hcd
185: 0 0 IO-APIC-level uhci-hcd, uhci-hcd
193: 58 0 IO-APIC-level uhci-hcd
201: 0 0 IO-APIC-level ehci-hcd
209: 356 0 IO-APIC-level eth0
NMI: 0 0
LOC: 707613 707524
ERR: 0
MIS: 0
=========================================
They changed things so the MSI scheme uses the vector number
directly instead of remapping it...
I agree. We did not change arch/i386/kernel/irq.c, for example.
Thanks,
Jun
> -----Original Message-----
> From: Matt Porter [mailto:[email protected]]
> Sent: Monday, May 12, 2003 10:43 AM
> To: Matthew Wilcox
> Cc: Jeff Garzik; [email protected]; Ivan Kokshaysky;
> [email protected]
> Subject: Re: Message Signalled Interrupt support?
>
> On Mon, May 12, 2003 at 05:53:31PM +0100, Matthew Wilcox wrote:
> > On Mon, May 12, 2003 at 12:32:49PM -0400, Jeff Garzik wrote:
> > > Has anybody done any work, or put any thought, into MSI support?
> >
> > Work -- no. Thought? A little. Seems to me that MSIs need to be
> treated
> > as a third form of interrupts (level/edge/message). The address that
> > the MSI will write to is clearly architecture dependent (may even be
> > irq-controller-dependent, depending on your architecture).
> request_irq()
> > is an insufficient function to deal with this -- request_msi() may be
> > needed instead. It'll need to return an address to pass to the card.
> > (We need a mechanism to decide whether it's a 32-bit or 64-bit address).
>
> I've also done some thought for PPC440xx's PCI MSI support. It isn't
> strictly necessary to have a new request_msi() if the kernel "does
> the right thing". request_irq() already hooks using an interrupt
> value that is virtual on many platforms. In that case, the PCI
> subsystem would only need to provide an interface to provide
> the architecture/platform specific inbound MSI location. The PCI
> subsystem would then find all MSI capable PCI devices, and assign
> the appropriate number of unique messages and inbound MSI address
> to each device via the speced PCI MSI interface. The PCI subsystem
> would also be responsible for maintaining a correspondence between
> virtual Linux interrupt values and MSI values.
>
> Software specific to the PCI MSI capable "Northbridge", will then
> route general MSI interrupt events to some PCI subsystem helper
> functions to verify which MSI has occurred and thus which Linux
> virtual interrupt.
>
> Perhaps request_irq() just needs to be explicitly abstracted if
> an unsigned int is not sufficient for the entire message space or
> if we want messages unique only on a per-space basis i.e. PCI MSIs
> can be dups of RapidIO MSIs, etc.
>
> > Oh, and don't make this too PCI-specific -- native PARISC interrupts
> > are MSI and you can see how handled it in arch/parisc/kernel/irq.c.
>
> FWIW, another interconnect that natively uses MSI is RapidIO. It's
> all in-band doorbell messages, no out-of-band discrete interrupts like
> PCI.
>
> Regards,
> --
> Matt Porter
> [email protected]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Yes. We are posting a patch soon (probably this week).
You don't need to change the existing device drivers unless you want to support multiple messages (something like multiple vectors per IRQ).
Thanks,
Jun
> -----Original Message-----
> From: Jeff Garzik [mailto:[email protected]]
> Sent: Monday, May 12, 2003 9:33 AM
> To: [email protected]
> Cc: Ivan Kokshaysky; [email protected]; [email protected]
> Subject: Message Signalled Interrupt support?
>
> Has anybody done any work, or put any thought, into MSI support?
>
> Would things massively break if I set up MSI manually in the driver?
>
> I heard rumblings on lkml that Intel has done some work internally w/
> MSI support in Linux, but that doesn't help me much without further
> details ;-)
>
> Jeff
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
I think that MSI should be made quite explicit. If the device and
platform both support MSI, then the driver should be able to ask for
MSI, but kernel must be able to deny it. All devices supporting MSI must
support also pin based interrupt delivery. As MSI can be costy (one
interrupt vector per device for instance), it could be that a device has
to work in pin based mode instead.
--Mika
David S. Miller wrote:
> From: Matthew Wilcox <[email protected]>
> Date: Mon, 12 May 2003 17:53:31 +0100
>
> On Mon, May 12, 2003 at 12:32:49PM -0400, Jeff Garzik wrote:
> > Has anybody done any work, or put any thought, into MSI support?
>
> Work -- no. Thought? A little. Seems to me that MSIs need to be
> treated as a third form of interrupts (level/edge/message).
>
>The fact that Alpha already supports them pretty much transparently
>suggests that the thing to do might very well be "nothing" :-)
>
>To be honest, MSIs are very similar to how interrupts work on sparc64,
>in that each device generates a unique interrupt cookie. The only
>different is the size of this cookie, MSIs are larger than sparc64's.
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>