Re: [PATCH] rename CONFIG_PCI_USE_VECTOR to CONFIG_PCI_MSI

[Roland Dreier]

    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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/