[coreboot] PCI interrupts
peter at stuge.se
Fri May 1 03:40:13 CEST 2009
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. :)
More information about the coreboot