Messages in this thread | | | Date | Mon, 6 Jun 2005 15:58:26 -0700 | From | Greg KH <> | Subject | Re: pci_enable_msi() for everyone? |
| |
On Fri, Jun 03, 2005 at 04:36:17PM -0700, Roland Dreier wrote: > Greg> In talking with a few people about the MSI kernel code, they > Greg> asked why we can't just do the pci_enable_msi() call for > Greg> every pci device in the system (at somewhere like > Greg> pci_enable_device() time or so). That would let all drivers > Greg> and devices get the MSI functionality without changing their > Greg> code, and probably make the api a whole lot simpler. > > Greg> Now I know the e1000 driver would have to specifically > Greg> disable MSI for some of their broken versions, and possibly > Greg> some other drivers might need this, but the downside seems > Greg> quite small. > > This was discussed the first time around when MSI patches were first > posted, and the consensus then was that it should be an "opt in" > system for drivers. However, perhaps things has matured enough now > with PCI Express catching on, etc.
Yeah, that's what I'm trying to find out.
> I think the number of devices truly compliant with the MSI spec is > quite tiny. Probably just about every driver for a device that > actually has an MSI capability in its PCI header will need code to > work around some breakage, or will just end up disabling MSI entirely > because it never works. Also I don't know how many PCI host bridges > implement MSI correctly. For example we have a quirk for AMD 8131, > but who knows how many other chipsets are broken (and some bugs may be > much more subtle than the way the AMD 8131 breaks, which is to never > deliver interrupts).
Motherboard quirks are one thing. Broken devices are a totally different thing. If there are too many of them, then the current situation is acceptable to me. Does ib have devices that will break with MSI?
> Also, there needs to be a way for drivers to ask for multiple MSI-X > vectors. For example the mthca InfiniBand driver gets a nice > performance boost by using separate interrupts for different types of > events. I'm also planning on adding support for having one completion > interrupt per CPU, to help SMP scalability.
In looking at that, I don't see a way to get rid of the msix stuff. So that's probably just going to stay the same.
thanks,
greg k-h - 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/
| |