Subject: Re: Interrupt Routing on PCI-PCI Bridges
To: Jochen Kunz <jkunz@unixag-kl.fh-kl.de>
From: Charles M. Hannum <abuse@spamalicious.com>
List: tech-kern
Date: 08/13/2004 20:21:52
On Friday 13 August 2004 19:15, Jochen Kunz wrote:
> Hi.
>
> I am hardening the hp700 PCI code by testing varois PCI devices. One
> device is a quad Ethernet card with a DEC DC21152 PCI-PCI bridge and
> four tlp(4) behind it. See dmesg(1) output below.
>
> What I don't understand is how interrupts are routed through a PCI-PCI
> bridge. To me it looks like the interrupt lines are maped 1:1 from the
> secondary to the primary bus. The devices on the primary bus already use
> IRQs 1, 3 and 0, so this IRQs are shared. The question now is:
> Can I detemine what device has caused a shared interrupt?
> Or is this impossible and I have to call the interrupt handler of all
> devices that share the interrupt in question? (Thus probably calling an
> interrupt handler of a device that didn't interrupt.)

This is actually system-specific.

PCI slots have four interrupt lines (INTA-INTD).  A PCI-PCI bridge maps these 
to its subdevices in a prescribed fashion, by "swizzling" them based on the 
device number.  (So, one device might gets A,B,C,D, another B,C,D,A, etc.).  
If the devices behind the bridge are all single-function devices, it will 
look like there is a 1:1 mapping; however, if they are multifunction devices, 
you'll seem some sharing even at that level.

How the slot interrupts are mapped to system interrupts is unspecified.  On 
PCs, it's done through 4 or 8 interrupts going into the southbridge, and the 
motherboard typically "swizzles" the interrupts.  (Some ultra-lame systems 
map everything to one IRQ.)  There is no method for determining which 
device(s) generated the interrupt; you just poll each one.

Alpha systems have per-slot interrupts, so you can identify a particular slot, 
but if there's a bridge, there may still be multiple devices that are 
asserting the interrupt.  In this case, there is also no way to determine 
which device(s) behind the slot generated the interrupt.

I'd say, if you have the mapping of the 4 interrupts working, don't argue with 
it too much.  :-)