Date: Fri, 11 Oct 1996 12:16:41 +0200 From: se@zpr.uni-koeln.de (Stefan Esser) To: smp@csn.net (Steve Passe) Cc: hackers@freefall.freebsd.org Subject: Re: PCI internals Message-ID: <199610111016.MAA19281@x14.mi.uni-koeln.de> In-Reply-To: <199610110004.SAA07241@clem.systemsix.com>; from Steve Passe on Oct 10, 1996 18:04:29 -0600 References: <199610110004.SAA07241@clem.systemsix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Steve Passe writes: > Hi, > > I am doing the code for symmetric IO in the freeBSD SMP kernel. I currently > am struggling with the PCI INTerrupt redirection code. My problem: > > [ code in src/sys/pci/pci.c: ] > > 'pci_map_int( ... )' calls 'getirq( pcici_t tag )' to find the INTerrupt > to register with the kernel for use by the PCI card being setup. > > 'getirq()' gets the "re-directed" ISA INTerrupt from: > > irq = PCI_INTERRUPT_LINE_EXTRACT( > pci_conf_read (tag, PCI_INTERRUPT_REG)); > > BUT with the MP capable boards the 8259 PIC chips are abandoned after boot > and an APIC (Advanced Programmable Interrupt Controller) is used instead. > This chip directly supports 24 INTs, so the PCI INTS are directly attached > to its upper pins, and the "redirected" ISA INTs never reach it. Well, I never dealt with SMP boards, and IMHO SMP using one of the current P5 motherboards is a waste of time and money ... But this may change with P6 class CPUs and suitable chip sets, which do not have the second CPU starve for memory bandwitdh. I have considered buying a dual Pentium motherboard (Gigabyte 586DX) nonetheless, just for testing purposes, but did not yet decide to actually go for it. Now for the support of 24 interrupt lines: Are those numbers outside the range of the ISA IRQs ? Please send a VERBOSE boot message log. > The MP motherboard provides a BIOS table that tells me which PCI INTerrupt > line is attached to what APIC pin. This mapping is described as: > > PCI bus number, > PCI device number, > PCI line IRQ#: INT_[ABCD] The current FreeBSD PCI code completely ignores the PCI BIOS. The kernel does of course rely on the correct initialization of the chip set, but else does direct configuration space register accesses. It was designed this way, since 32 bit PCI BIOS calls did not work too well on many early PCI motherboards, and it appeared unnecessary given the concept of device independent config space accesses. There have been a few functions added to the PCI BIOS recently, mostly dealing with PC specific details. For example with IRQ routing setup. It was not necessary to deal with that, and I'm not sure whether the APIC specific code should go into the PCI support code, or whether it rather should go into the i386 specific tree ... > So in 'getirq()' I need to determine the PCI bus/device# of interest at the > time 'getirq()' is called. From this I can determine the APIC pin, and thus > the real IRQ#, to return. I am most interested in the device#, I can assumme > bus0 for now (but NOT forever). > > Can these be determined from 'tag'? > If not, how do I go about this? Well, where do I find information on the APIC features you rely on ? (I'm interested in both the hardware register description as the PCI BIOS support for APIC. I do not yet have the latest PCI BIOS docs, and did not intend to rely on the PCI BIOS in general. But support of SMP might make this necessary ...) Provide me with an URL or the necessary docs, and the getirq function will be changed accordingly witin a few days ... Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610111016.MAA19281>