Messages in this thread | | | Subject | Re: [PATCH] rename CONFIG_PCI_USE_VECTOR to CONFIG_PCI_MSI | From | Roland Dreier <> | Date | Mon, 26 Jul 2004 18:03:13 -0700 |
| |
Roland> 1) Merge Long's latest MSI/MSI-X patches (updated patches Roland> in http://gmane.linux.kernel/218830). Without the new Roland> semantics of pci_disable_msi()/pci_disable_msix(), it's Roland> very difficult to use MSI/MSI-X in a device driver.
Bjorn> That sounds fine to me. There's nobody really using MSI Bjorn> yet, so it can't break too much.
Yup... as far as I can tell there are no in-kernel users, and nobody noticed that the MSI-X code didn't enable MSI-X properly until my patch from last month. My mthca driver:
https://openib.org/svn/gen2/branches/roland-merge/src/linux-kernel/infiniband/hw/mthca
seems to be one of the first attempts to use MSI/MSI-X. I have some uncommitted changes to match Long's patch -- without the patch the semantics of free_irq() releasing an MSI-X vector make my driver code very awkward.
Roland> 2) Split the config options so we have an i386-specific Roland> CONFIG_PCI_USE_VECTOR and a generic CONFIG_PCI_MSI (with Roland> CONFIG_PCI_MSI depending on something like !I386 || Roland> CONFIG_PCI_USE_VECTOR) This would be an updated version of Roland> your patch.
Bjorn> Yup. Nothing in MSI has changed since April, so I thought Bjorn> my patch would be a reasonable no-risk first step.
I agree... I'd just really, really like to see Long's patch merged first, since I've been waiting for it for a long time and my driver is broken without it :)
Roland> 3) Make the code in drivers/pci/msi.c less Intel-specific Roland> -- instead of hard-coding Intel-specific addresses for Roland> vectors have the computation call into arch code. This Roland> would be a fair amount of work and depends documentation Roland> for non-Intel platforms that implement MSI/MSI-X -- should Roland> be easier as PCI Express comes out.
Bjorn> This is the bit I really want to get to. In particular, I Bjorn> want to support multiple interrupt vector spaces on ia64, Bjorn> because we're running out of vectors. I can't do that as Bjorn> long as MSI mucks around with the arch-specific vector Bjorn> allocation. (There's plenty of ia64 code that needs to be Bjorn> cleaned up, too; it's not just MSI.)
Bjorn> I think there needs to be some arch interface to Bjorn> allocate/deallocate Linux IRQ numbers (not interrupt Bjorn> vectors). Then MSI can allocate as many as it needs, and Bjorn> use yet another arch interface to translate the Linux IRQ Bjorn> numbers to the appropriate address/data info to program the Bjorn> device.
Sounds good, although I don't know much about the low-level details of interrupt vectors on either i386 or ia64. Some way of exposing which interrupts are "closest" to which CPUs would be a good thing too.
One thing that I would be a little concerned about is making the numbers in /proc/interrupts too divorced from the underlying platform interrupt code -- it seems that ACPI debugging is hard enough as it is.
- Roland - 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/
| |