Messages in this thread | | | Date | Mon, 12 May 2003 11:48:51 -0700 | From | Matt Porter <> | Subject | Re: Message Signalled Interrupt support? |
| |
On Mon, May 12, 2003 at 07:20:23PM +0100, Matthew Wilcox wrote: > On Mon, May 12, 2003 at 10:43:00AM -0700, Matt Porter wrote: > > 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. > > Yes, but ideally this kludge would go away...
Well, with respect to MSI, yes it could. Interrupt values are still a Linux fabrication regardless on many platforms with cascaded PICs.
> > 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. > > That sounds like a lot of overhead. In particular it means we keep > converting to and from `virtual IRQs'. I would hope the MSI work would > allow us to tie in at a lower level than virtual interrupts. I was > thinking an interface would look something like:
Yes, it's a bit. Just pointing out that one *could* do it that way, not really that we *should* do it that way. I would personally prefer to see native msi support. However, most of the functionality I mentioned are things the PCI subsystem needs to do specific to PCI MSI anyway.
> void *request_msi(struct device *dev, > irqreturn_t (*handler)(int, void *, struct pt_regs *), > unsigned long irqflags, > void *dev_id) > > You need a struct device to figure out which interrupt controller it > needs.
request_msi() needs an additional parameter to specify which MSI it is hooking. A device can implement many messages in order to clarify which one of many events on a device has occurred. It may be desired to hook a separate handler for each of those to avoid another read of a status register.
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/
| |