Thread (1 message) 1 message, 1 author, 2000-03-08

Re: Grabbing an Interrupt for a Brain-dead PCI Device

From: Matt Porter <hidden>
Date: 2000-03-08 14:15:54

On Wed, Mar 08, 2000 at 09:31:42AM +0100, Geert Uytterhoeven wrote:
On Tue, 7 Mar 2000, Michel Lanners wrote:
quoted
If this is in a PowerMac (at least those previous to UMA), then there
is a fixed IRQ per physical slot. All 4 PCI interrupt lines are OR'ed
together per slot.

However, there are other IRQ routing schemes as well... the above being
the easiest one, because the IRQ value can be hardcoded based on the
slot, which you can determine by software.
The most popular routing scheme looks like this:

    #INTA(slot_nr) -> pci_int(slot_nr % 4)
    #INTB(slot_nr) -> pci_int((slot_nr+1) % 4)
    #INTC(slot_nr) -> pci_int((slot_nr+2) % 4)
    #INTD(slot_nr) -> pci_int((slot_nr+3) % 4)

where

    pci_int(0) = #INTW
    pci_int(1) = #INTX
    pci_int(2) = #INTY
    pci_int(3) = #INTZ

Hence if all boards use one interrupt (the first interrupt on a board _must_ be
#INTA), they're evenly spread across the available interrupt sources.
This is documented in the PCI spec as the suggested method of routing irqs.
We usually call it the standard PCI swizzle, since the interrupts
tumble as they pass through each bridge.  I added this algorithm into
prep_pci.c for MCG boards recently since it is pretty crucial for CPCI
systems that are loaded up with bridges.  There are also plenty of regular
PCI boards that have a P2P and multiple single function devices on board
that also require this routing (old dual Ethernet cards come to mind,
slapping two 21x4x chips and a transparent bridge onboard).

--
Matt Porter
mmporter@home.com

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help