RE: PCI interrupt queries
Rajat Jain wrote: Hello Rene, Thanks for the reply. On 19-08-08 07:11, Rajat Jain wrote: 1) My first question is WHO writes that IRQ value in the device configuration space? Is it hardwired on the card? Is it written by the PCI controller driver or some other kernel component? Or some other piece of software takes care of it? The thing hardwired on the card is the interrupt PIN(s) it uses; A, B, C and/or D (one pin per device and thus per config space). The thing that writes the LINE value into the register is generally the BIOS; being motherboard specific it knows which IRQ line it is that pin X (A, B, C or D) from slot N is routed to and it writes those values back into the device. OK. But who does it in an embedded environment (PPC for eg) where there is no POST software. The first piece of code that gets executed is U-boot and then the kernel. So who writes the LINE value into the config space? U-boot does. There is a fairly standardised way to connect PCI interrupt lines, especially for PCI slots where various cards can be plugged in: A rotation on 1 is applied to the wiring of the interrupt lines between each device/slot, order is dependant on the wiring of the device select lines, I think chapter 6 of TLK[1] has some of the basics. These rotations also need to be carried across PCI-to-PCI bridges. Hence the third device on bus 0 should have: A-INT3; B-INT4; C-INT1; d-INT2. INT[1-4] then map into a set of interrupt numbers, which are also highly dependant on the hardware. There is a lot of hardware where this doesn't hold true for onboard devices (and probably even slots) and the mapping of the devices interrupts with relation to their device select lines are provided by a board specific table. Martyn [1] http://www.tldp.org/LDP/tlk/dd/pci.html -- Martyn Welch MEng MPhil MIET Principal Software Engineer GE Fanuc Intelligent Platforms Tove Valley Business Park, Towcester, Northants, NN12 6PF, United Kingdom Telephone: +44 (0) 1327 359444 Direct Dial: +44 (0) 1327 322748 Fax: +44 (0) 1327 322800 email: [EMAIL PROTECTED] web: www.gefanuc.com GE Fanuc Intelligent Platforms Ltd, registered in England and Wales (3828642) at 100 Barbirolli Square, Manchester, M2 3AB, VAT GB 729 849 476 GE Fanuc Intelligent Platforms Confidential and Proprietary. If you have received this message in error please notify us immediately and permanently remove it from your system and destroy any printed hardcopies. -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to [EMAIL PROTECTED] Please read the FAQ at http://kernelnewbies.org/FAQ
Re: PCI interrupt queries
On 21-08-08 11:31, Welch, Martyn (GE EntSol, Intelligent Platforms) wrote: Rajat Jain wrote: OK. But who does it in an embedded environment (PPC for eg) where there is no POST software. The first piece of code that gets executed is U-boot and then the kernel. So who writes the LINE value into the config space? U-boot does. There is a fairly standardised way to connect PCI interrupt lines, especially for PCI slots where various cards can be plugged in: How peculiar, a boot loader doing hardware programming... Rene. -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to [EMAIL PROTECTED] Please read the FAQ at http://kernelnewbies.org/FAQ
Re: PCI interrupt queries
Welch, Martyn (GE EntSol, Intelligent Platforms) wrote: Rajat Jain wrote: Hello Rene, Thanks for the reply. On 19-08-08 07:11, Rajat Jain wrote: 1) My first question is WHO writes that IRQ value in the device configuration space? Is it hardwired on the card? Is it written by the PCI controller driver or some other kernel component? Or some other piece of software takes care of it? The thing hardwired on the card is the interrupt PIN(s) it uses; A, B, C and/or D (one pin per device and thus per config space). The thing that writes the LINE value into the register is generally the BIOS; being motherboard specific it knows which IRQ line it is that pin X (A, B, C or D) from slot N is routed to and it writes those values back into the device. OK. But who does it in an embedded environment (PPC for eg) where there is no POST software. The first piece of code that gets executed is U-boot and then the kernel. So who writes the LINE value into the config space? U-boot does. There is a fairly standardised way to connect PCI interrupt lines, especially for PCI slots where various cards can be plugged in: A rotation on 1 is applied to the wiring of the interrupt lines between each device/slot, order is dependant on the wiring of the device select lines, I think chapter 6 of TLK[1] has some of the basics. These rotations also need to be carried across PCI-to-PCI bridges. Hence the third device on bus 0 should have: A-INT3; B-INT4; C-INT1; d-INT2. INT[1-4] then map into a set of interrupt numbers, which are also highly dependant on the hardware. I think this rotation is required by PCI bridge spec, and it was included primarily to reduce loading of any one line alone. Thanks, Om. -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to [EMAIL PROTECTED] Please read the FAQ at http://kernelnewbies.org/FAQ
Re: PCI interrupt queries
On 20-08-08 06:50, Rajat Jain wrote: On 19-08-08 07:11, Rajat Jain wrote: I want to understand who decides the IRQ number that a agiven PCI card will use. I understand that from a PCI device drivers point of view, it'll find the IRQ vector that it needs to attach by reading it from the configuration space of the device. Actually, a quick look at struct pci_dev suggests you should be using pci_dev-irq. Note sure why that is; maybe odd bridged setups. Where in source code is pci_dev-irq getting populated? I tried but could not exactly locate it... pci_read_irq() it seems. OK. But who does it in an embedded environment (PPC for eg) where there is no POST software. The first piece of code that gets executed is U-boot and then the kernel. So who writes the LINE value into the config space? If anything, the kernel and specifically that bit of the kernel that sets up the routing (if there is anything to setup; might ofcourse be fully hardwired there). The if anything might be the reason for needing to use pci_dev-irq as per the comment. As said, don't know. Makes sense though; why would you write it back to config space if you can just supply it as part of pci_dev. Rene. -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to [EMAIL PROTECTED] Please read the FAQ at http://kernelnewbies.org/FAQ
Re: PCI interrupt queries
On 19-08-08 07:11, Rajat Jain wrote: I want to understand who decides the IRQ number that a agiven PCI card will use. I understand that from a PCI device drivers point of view, it'll find the IRQ vector that it needs to attach by reading it from the configuration space of the device. Actually, a quick look at struct pci_dev suggests you should be using pci_dev-irq. Note sure why that is; maybe odd bridged setups. Greg might know if he's reading this :-) 1) My first question is WHO writes that IRQ value in the device configuration space? Is it hardwired on the card? Is it written by the PCI controller driver or some other kernel component? Or some other piece of software takes care of it? The thing hardwired on the card is the interrupt PIN(s) it uses; A, B, C and/or D (one pin per device and thus per config space). The thing that writes the LINE value into the register is generally the BIOS; being motherboard specific it knows which IRQ line it is that pin X (A, B, C or D) from slot N is routed to and it writes those values back into the device. Well, basically at least. It knows as long as it has programmed the interrupt router itself as well: 2) Secondly, irrespective of whoever writes it, what determines the irq vector VALUE that will be written? So given that a PCI card uses PCI INTA, what determines the IRQ vector associated with it? My understanding is that the board specifications say something like The INTA from this PCI slot goes to IRQx input of interrupt controller. And then from interrupt controller dosument we can find out which IRQ vector is associated with input IRQx. Is this right? That's the basic form but in reality things are not hardwired on the motherboard either; there's a programmable interrupt router (part of the PCI chipset) between the lines coming from the bus and the lines going into the interrupt controller that enables software control of the routing. So the answer is -- whoever sets up the interrupt routing. In your dmesg you will see things like: ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 *9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 11 *12 14 15) which lists the routing as setup by the BIOS. Linux _could_ change the routing although I'm not sure if it ever does. What it certainly can do is enable devices that the BIOS left disabled (wish it couldn't so it would butt out already!) and then it is running the show. 3) Lastly, if we boot linux and a different OS, on the same board with the same PCI card plugged in, are they bound to use the same IRQ number? Why or why not? Not bound then. The programmable interrupt router could be set up differently. Also see the nice daisy-chaining diagram in Documentation/x86/i386/IO-APIC.txt The programmable interrupt router is to the left, between the PIRQ lines and the IRQ input lines on the PIC. Rene. -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to [EMAIL PROTECTED] Please read the FAQ at http://kernelnewbies.org/FAQ
RE: PCI interrupt queries
Hello Rene, Thanks for the reply. On 19-08-08 07:11, Rajat Jain wrote: I want to understand who decides the IRQ number that a agiven PCI card will use. I understand that from a PCI device drivers point of view, it'll find the IRQ vector that it needs to attach by reading it from the configuration space of the device. Actually, a quick look at struct pci_dev suggests you should be using pci_dev-irq. Note sure why that is; maybe odd bridged setups. Where in source code is pci_dev-irq getting populated? I tried but could not exactly locate it... 1) My first question is WHO writes that IRQ value in the device configuration space? Is it hardwired on the card? Is it written by the PCI controller driver or some other kernel component? Or some other piece of software takes care of it? The thing hardwired on the card is the interrupt PIN(s) it uses; A, B, C and/or D (one pin per device and thus per config space). The thing that writes the LINE value into the register is generally the BIOS; being motherboard specific it knows which IRQ line it is that pin X (A, B, C or D) from slot N is routed to and it writes those values back into the device. OK. But who does it in an embedded environment (PPC for eg) where there is no POST software. The first piece of code that gets executed is U-boot and then the kernel. So who writes the LINE value into the config space? 2) Secondly, irrespective of whoever writes it, what determines the irq vector VALUE that will be written? So given that a PCI card uses PCI INTA, what determines the IRQ vector associated with it? My understanding is that the board specifications say something like The INTA from this PCI slot goes to IRQx input of interrupt controller. And then from interrupt controller dosument we can find out which IRQ vector is associated with input IRQx. Is this right? That's the basic form but in reality things are not hardwired on the motherboard either; there's a programmable interrupt router (part of the PCI chipset) between the lines coming from the bus and the lines going into the interrupt controller that enables software control of the routing. Thanks, I got it. 3) Lastly, if we boot linux and a different OS, on the same board with the same PCI card plugged in, are they bound to use the same IRQ number? Why or why not? Not bound then. The programmable interrupt router could be set up differently. Ok. Thanks. Thank you very much for the informative reply, Rajat -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to [EMAIL PROTECTED] Please read the FAQ at http://kernelnewbies.org/FAQ
