Joseph Smith wrote:
I wish you could make your internal picture external, so I could see what it is then.
Interrupts are a little complex. I'll try to add some things.
The PCI bus allows each PCI device (by device I mean chip, with a device id, and possibly with several functions) to use at most four interrupt signals. They are called INTA, INTB, INTC and INTD.
Each PCI device is allowed to use (=activate) zero or more of them. Devices with several functions can benefit from using more interrupt signals, because then each function can get it's own interrupt signal, which helps throughput. When multiple bus INTx signals are connected to a device, how the device INTx pins are connected internally in the device to the various functions is described by the mapping in register 3d for each function, as Ron mentioned.
Many devices only generate one interrupt signal, and that will always be INTA on the device. Some generate more than one signal.
The mainboard designer can swizzle interrupt signals between devices, in order to spread out interrupt load so that four devices all signalling on "their" INTA do not have to share the INTA bus signal.
The four PCI bus interrupt signals do not (and should not!) connect to all PCI devices in parallell. The PCI bus INTA may be connected to device 1 INTA, and device 2 INTB. This routing is what irq_tables.c expresses, and unfortunately it cannot be probed. It's really a small part of the mainboard netlist.
There's one device per line in irq_tables.c. How many of the four fields in irq_tables.c which require values depends on how many interrupt signals that are connected to that device.
So much for the PCI bus.
Between the bus and the CPU there's more logic. Different chipsets have different complexity. This is the PIC/XPIC/APIC/IOAPIC. It needs to be configured by firmware to pass on the PCI bus interrupt signals to the CPU, and it can usually map the four bus interrupts onto any of the 16 first CPU interrupts. The original PC had the same PIC which remains today.
The PIC mapping determines which CPU interrupts can be assigned to the devices and have them actually work.
Originally it was hoped that operating systems would do interrupt assignment, but that did not work out. The firmware has to do most if not all of this work with mapping the system and telling devices about which CPU interrupts they are generating.
Register 3c is not really used by hardware, it just stores the interrupt assignment for each device, it is written by the resource allocator and read by the operating system device driver.
There's no connection between register 3c and the PIC mapping either, so the resource allocator has to keep track of the PCI bus as well as the PIC mapping in order to assign working interrupts to devices.
http://tldp.org/LDP/tlk/dd/pci.html has more info about the PCI bus.
I hope this helps. :)
//Peter