OSDev.org

How do you determine the IRQ line that's being triggered by a PCI device? Is it better to use the APIC for separately routing them and if so, how do you determine which apic interrupt is triggered by a particular device?

I hope this quote from the PCI Local Bus Specification 3.0 answers your questions:

Interrupt Line
The Interrupt Line register is an eight-bit register used to communicate interrupt line routing information. The register is read/write and must be implemented by any device (or device function) that uses an interrupt pin. POST software will write the routing information into this register as it initializes and configures the system. The value in this register tells which input of the system interrupt controller(s) the device's interrupt pin is connected to. The device itself does not use this value, rather it is used by device drivers and operating systems. Device drivers and operating systems can use this information to determine priority and vector information. Values in this register are system architecture specific. *43

Interrupt Pin
The Interrupt Pin register tells which interrupt pin the device (or device function) uses. A value of 1 corresponds to INTA#. A value of 2 corresponds to INTB#. A value of 3 corresponds to INTC#. A value of 4 corresponds to INTD#. Devices (or device functions) that do not use an interrupt pin must put a 0 in this register. The values 05h through FFh
are reserved. This register is read-only. Refer to Section 2.2.6 for further description of the usage of the INTx# pins.

*43 For x86 based PCs, the values in this register correspond to IRQ numbers (0-15) of the standard dual 8259 configuration. The value 255 is defined as meaning "unknown" or "no connection" to the interrupt controller. Values between 15 and 254 are reserved.

Hi,

Candy wrote:How do you determine the IRQ line that's being triggered by a PCI device? Is it better to use the APIC for separately routing them and if so, how do you determine which apic interrupt is triggered by a particular device?

For the PIC chips, the BIOS is responsible for storing the IRQ number in each device's PCI configuration space (the "Interrupt Line Register" mentioned by Bluecode). This has nothing to do with I/O APICs (it's for PIC chips only)

For I/O APICs, the information is in the MP specification tables (if present) and/or the ACPI configuration tables (if present). In both cases this consists of an "interrupt assignment" entry for each device saying which I/O APIC input (and which I/O APIC) it is routed to, and how that input needs to be programmed (level/edge triggered, polarity, etc).

For setting up I/O APICs there's also (usually) other interrupt assignment entries for any motherboard specific interrupts (e.g. SMI), and also some entries for local APIC inputs (usually "INTR" and "NMI").

There's also entries for legacy/ISA IRQ lines, showing how ISA IRQs are mapped to I/O APICs inputs. For e.g. you might have an entry saying ISA IRQ 0 is connected to I/O APIC input #2, and that it's edge triggered active low.

There's very little difference between the information given by MP specification tables and the ACPI tables, except that the MP specification usually doesn't include SCI (which is only used for ACPI systems anyway - non-ACPI systems use an SMI instead of an SCI). There's also differences in how legacy/ISA IRQs are reported - IIRC MP specification reports all of them regardless, while ACPI only reports IRQs that are unusual (e.g. if ISA IRQs 2 to 15 are connected the corresponding I/O APIC inputs 2 to 15 then they won't be listed by ACPI, but if ISA IRQ 1 isn't connected to I/O APIC input 1 then it will be listed).

In any case, I'd recommend building your own generic I/O APIC configuration table from the information you find in ACPI or MP specification tables, and then use your own generic I/O APIC configuration table for initializing and managing I/O APIC connections - not forgetting that the OS may setup MSI for some devices afterwards and may want to keep track of which device/IRQ is using which IRQ priority (or interrupt vector).


Cheers,

Brendan