![]() This picture is a little bit complicated, but the point is that here we simply connect INTx# lanes with PIRQy lanes in a round-robin way (PIRQA, PIRQB, PIRQC, PIRQD, PIRQA, PIRQB, PIRQC, PIRQD, PIRQA, PIRQB, PIRQC, PIRQD. Here is a picture that illustrates this problem: And in this case lanes PIRQB-PIRQD would stand idle wasted most of the time. If there are many of those devices, it surely wouldn't increase system response to the interrupt. This way, every time a processor has a signal that there is an interrupt on a IRQ16 line, it has to question all of the device drivers of the PCI devices connected to that IRQ16 line (PIRQA) if they have an interrupt. Suppose this lane is connected to the IRQ16. Therefore if we decided to route all lanes as we've written, almost all of the devices in a system would share interrupt lane PIRQA. For example:Īs we've already said above, the most common case is when a PCI device has only one function, and its interrupt is connected to the INTA# lane (because why would hardware device developer route it in a different way?). Why should we waste our time paying attention to the interrupt routing setup? Suppose we've decided to not bother at all and have connected all the interrupt lanes from every PCI device to the PIRQ lanes in the same way. ![]() Why can't we just connect INTA#→PIRQA, INTB#→PIRQB,… everywhere? ) from the interrupt controller (APIC/PIC), which is connected with the PIRQy lane ) from the PIR, which is connected with the INTx# lane INTx# - INT# lane (INTA#, INTB#, INTC#, INTD#) of the PCI device, which is used by a PCI function.Summarizing all of that, let us write the complete path (routing) for an interrupt from any PCI function through INTx#→PIRQy→IRQz, where: Also for PCI devices that are part of a chipset, by writing to its special registers it is usually possible to declare which functions use which INTx# lanes (or don't use them at all). In general the device can have even more that 4 functions (as we've already said up to 8), and in this case it has to connect some of them to the same INTx# lane (PCI interrupts can share an interrupt lane). In the most simple (and most common) case, a PCI device has only one function with its interrupt going to the lane INTA#. From the point of view of the OS every function is like a separate device with its own configuration space PCI Config. For example, one PCI device can have in itself the 'SMBus controller' function, the 'SATA controller' function, and the 'LPC bridge' function. In a nutshell these functions are like separate logical blocks. Which INTx# interrupt will trigger each of the functions is either fixed in the hardware, or is defined by the device software configuration. Also, every PCI device can have up to 8 so called 'functions' (which actually trigger interrupts) and each of these functions can connect to one of the INTx# lanes. ![]() In reality every PCI device has four interrupt lanes (INTA#, INTB#, INTC#, INTD#). On these pictures the mapping 'PCI device → PIR' is fairly abstract - it is actually a little bit more complicated. In Part 1 we highlighted a common path of an interrupt from the external device for the PIC and APIC cases. To start let's review and expand our theoretical knowledge of the subject. In its source code we'll see what is needed to setup the interrupt routing in a chipset. But luсkily there is coreboot - a project aimed at replacing proprietary BIOS with free firmware code. None of the modern BIOS developer companies (AwardBIOS/AMIBIOS/Insyde) open their source code. In this part we will investigate how the BIOS sets IRQ to the interrupt controllers routing in a chipset. In Part 2 ( Linux kernel boot options) we looked at how in practice the OS chooses between different interrupt controllers. In Part 1 ( Interrupt controller evolution) we looked at the theory behind interrupt controllers and all the necessary terminology. We continue to investigate external device interrupt routing setup in the x86 system.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |