lkml.org 
[lkml]   [2004]   [Jul]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH] rename CONFIG_PCI_USE_VECTOR to CONFIG_PCI_MSI
    From
    Date
        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/

    \
     
     \ /
      Last update: 2005-03-22 14:04    [W:0.034 / U:63.328 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site