![]() | |||||||||||||
Messages in this thread |
On Tue, Jun 07, 2005 at 10:41:12PM +0200, Arjan van de Ven wrote: > On Tue, 2005-06-07 at 09:10 -0700, Greg KH wrote: > > On Tue, Jun 07, 2005 at 09:31:39AM +0200, Arjan van de Ven wrote: > > > > > > > > * What if the driver writer does not want MSI enabled for their > > > > > hardware (even though there is an MSI capabilities entry)? Reasons > > > > > include: overhead involved in initiating the MSI; no support in some > > > > > versions of firmware (QLogic hardware). > > > > > > > > Yes, a very good point. I guess I should keep the pci_enable_msi() and > > > > pci_disable_msi() functions exported for this reason. > > > > > > > > > > well... only pci_disable_msi() is needed for this ;) > > > > I thought so too, until I looked at the IB driver :( > > > > The issue is, if pci_enable_msix() fails, we want to fall back to MSI, > > so you need to call pci_enable_msi() for that (after calling > > pci_disable_msi() before calling pci_enable_msix(), what a mess...) > > if the core enables msi.. shouldn't the core also do msix ? Damm, I knew someone was going to say that :) Yeah, problem is, the driver provides the msix entries for the core to fill in. I could just move that to the pci structure itself if no one minds, and just use the max number of entries as the default. Hm, or does it really help for the driver to specify different numbers of msi-x vectors? Roland, any ideas here? You seem to be the only one who has actually used the msix code so far. 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/ | ||||||||||||
| Last update: 2005-06-07 22:12 [from the cache] ©2003-2008 | |||||||||||||