OSDev.org

Hi all,

I am a bit overwhelmed by the topic, but I think I got it and wanted to ask if I got everything right.

As far as I understand, the PCI spec says that all single-function devices have to use INTA#, but anyway, and all multi-function PCI devices have all 4 interrupt lines available, but only one line per function, which is written in the "interrupt line" field. The destination of this line is then dependent on the bus. If it is a root bus, all four lines on every device might be rerouted somewhere different. If it isn't on a root bus, then the four lines must go through a bridge. No idea if those then get remapped.

All the theoretical possibilities made my head hurt, so I had a look at the practical implementation in my laptop instead. So first let's look at the devices themselves:



So almost all devices are on the root bus, only two are on other busses, and each have a bus to themselves. Nice.

PCI interrupt routing for IOAPIC systems is handled by ACPI tables. So let's look at a bunch of those. First, you are supposed to call _PIC with an argument of 1 for IOAPIC. This is simple since in this case, my ACPI tables only define a single _PIC method, on the top definition level in the DSDT. And it does nothing except set two global variables. So then I'm supposed to run _PRT. This is a problem, as there are multiple of those. Namely:



OK, so how to locate the right one? I think I got it:
For devices on bus 0 (the only root bus), we use _SB.PCI0._PRT, for all others we have to find the correct bridge device and use its _PRT method. But what if a bridge device is mentioned in _SB.PCI0._PRT? In my case for example, in IOAPIC mode, the root bus returns the following PRT:


For those that didn't read the ACPI spec (I don't blame you), the first member of each package is a PCI address (first half device number, second half function number, with FFFF meaning "any function"), the second is 0, 1, 2, or 3 for INTA#, INTB#, INTC#, and INTD# respectively, and if the third is zero (which it always is, here), then the fourth is the GSI number. Since I only have a single IOAPIC in the system (according to the MADT), and its base is zero, the GSI number also equals the IOAPIC input number.

So the first thing I note is that this contains definitions for devices I don't have (like 0x13 and 0x15) and it doesn't contain definitions for devices that I have (like 0x14, the USB controller). So now what do I do with this one?

Anyway, on to the easier case. lspci tells me the SATA controller uses pin B, and pin B on device 0x1f is routed to GSI 19. Correct so far?

As for the other case, let's look at the Wifi card. It is located on bus 3. According to lspci, bus 3 is handled by device 00:1c.3 (PCI Express Root Port #4). And that one is really funny. The name suggests I should call _SB.PCI0.RP04._PRT. And not just the naming, even part of the address. Unfortunately, all root ports have dynamic addresses, some of the time:



RPA3 is part of a field in system memory. So, in theory, in order to identify the GSI number for the Wifi card, I have to look at all the devices under _SB.PCI0 to find the one with an address of 0x001c0003 at that moment. Since the address can be dynamic, I might have to reconfigure that. How do I know? Then I have to run its _PRT method or the _PRT method for any of its parents and iterate over the return values to find something.

In this case, if we ignore the possibility of RPA3 being nonzero, RP04 has a _PRT method, which returns this nicety in APIC mode:



I don't know why it tells me about pins B, C, and D, since the only device on the bus is a single-function device and can thus only use pin A, but why not.

So the Wifi card uses GSI 19.

So, am I correct so far? And what do I do about the USB controller? I mean, the point is mostly moot, anyway, since most of these devices support MSI, but I still would like to figure this out.

Ciao,
Markus