From owner-cvs-src@FreeBSD.ORG Thu Feb 19 11:23:34 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7528116A4D0 for ; Thu, 19 Feb 2004 11:23:34 -0800 (PST) Received: from mail4.speakeasy.net (mail4.speakeasy.net [216.254.0.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3082F43D3F for ; Thu, 19 Feb 2004 11:23:34 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 6432 invoked from network); 19 Feb 2004 19:23:33 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 19 Feb 2004 19:23:33 -0000 Received: from 10.50.40.205 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.10/8.12.10) with ESMTP id i1JJNM2J004803; Thu, 19 Feb 2004 14:23:22 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Nate Lawson Date: Thu, 19 Feb 2004 14:24:32 -0500 User-Agent: KMail/1.6 References: <20040218224027.4992016A4DA@hub.freebsd.org> <20040219104132.G41856@root.org> In-Reply-To: <20040219104132.G41856@root.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200402191424.32733.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/pci pci_pir.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2004 19:23:34 -0000 On Thursday 19 February 2004 01:43 pm, Nate Lawson wrote: > On Wed, 18 Feb 2004, John Baldwin wrote: > > Modified files: > > sys/i386/pci pci_pir.c > > Log: > > Rework the $PIR (aka PCIBIOS) PCI interrupt routing code and split it > > off into its own file: > > - All of the $PIR interrupt routing is now done in a link-centric > > fashion. When a host-PCI bridge that uses the $PIR attaches, it calls > > pir_parse() to parse the table. This scans for link devices and merges > > all the masks for each link device from the table entries. It then looks > > at the intline register of PCI devices connected to a link to figure out > > if the BIOS has routed this link and if so to which IRQ. > > - The IRQ for any given link can be overridden via a hint like so: > > 'hw.pci.link.0x62.irq=10' Any IRQ set in this matter is treated as > > if it were set that way by the BIOS. > > - We only call the BIOS to route each link device once. > > - When a PCI device wants to route an interrupt, we look it up in the > > $PIR to find the associated link. If the link is routed, we simply > > return the IRQ it is using. If it is not routed, we have to pick one. > > This uses a different algorithm from the old code. First off, when we > > try to pick an interrupt from a mask of possible interrupts, we try to > > pick the one that is least loaded as far as PCI devices. We maintain > > this weight based on the number of devices attached to each link device. > > When choosing an IRQ, we first attempt to route using any PCI only > > interrupts (the old code did this as well). If that doesn't work, we try > > to use the list of IRQs that the BIOS has used. This is a new step that > > the new code didn't do and avoids using IRQ 3 or 4 for every virgin > > interrupt routing. If none of the IRQs that the BIOS used worked, then > > we fall back to trying anything. > > - The fallback mask for !PC98 was fixed to include IRQ 3 and not allow > > IRQ 2. > > - We don't use the $PIR to route interrupts on a PCI-PCI bridge unless > > it has already been used to route on at least one Host-PCI bridge. This > > helps to avoid mixing and matching x86 firmware PCI interrupt routing > > methods (which is a Bad Thing(tm)). > > > > Silence on: current@ > > > > Revision Changes Path > > 1.109 +447 -611 src/sys/i386/pci/pci_pir.c > > This is great! Care to look at cleaning up the ACPI _PRT routing? I > believe it prefers 3-4 initially for many common BIOSen too. Yes, I have thought about adjusting the ACPI PCI link stuff to work the way $PIR does now (it's already fairly close). -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org