Re: [PATCH] rename CONFIG_PCI_USE_VECTOR to CONFIG_PCI_MSI

[Zwane Mwaikambo]

On Mon, 26 Jul 2004, Roland Dreier wrote:

>     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.)

Agreed, this was discussed earlier and shouldn't be too hard to work into
the current MSI code. Something akin to arrays of msi_desc indexed by
irq handling node depending on the source irq/bus information.

>     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.

We can do this right now using the topology information, it's been done
before on NUMAQ.

> 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.

Ok, some of those really are vectors, the thing is, for irqs > 15 (non
legacy) we pass the real vector around. This is done by setting
pci_dev->irq the vector assigned to that irq line. It can get quite
confusing in places so variable naming is indeed important. But in
general, on i386, all irqs with CONFIG_PCI_MSI are vectors.
-
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/