Re: pci_enable_msi() for everyone?

[Greg KH <gregkh@suse.de>]

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/