Messages in this thread | | | Subject | RE: Message Signalled Interrupt support? | Date | Mon, 12 May 2003 11:26:47 -0700 | From | "Nakajima, Jun" <> |
| |
I agree. We did not change arch/i386/kernel/irq.c, for example.
Thanks, Jun
> -----Original Message----- > From: Matt Porter [mailto:mporter@kernel.crashing.org] > Sent: Monday, May 12, 2003 10:43 AM > To: Matthew Wilcox > Cc: Jeff Garzik; linux-kernel@vger.kernel.org; Ivan Kokshaysky; > davem@redhat.com > 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 > mporter@kernel.crashing.org > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |