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    [from the cache]
©2003-2011 Jasper Spaans