From owner-freebsd-arch@FreeBSD.ORG Sun Aug 1 18:54:35 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED24716A4CE for ; Sun, 1 Aug 2004 18:54:35 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 902CD43D48 for ; Sun, 1 Aug 2004 18:54:35 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i71IrY4s011848; Sun, 1 Aug 2004 12:53:34 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 01 Aug 2004 12:54:03 -0600 (MDT) Message-Id: <20040801.125403.13772512.imp@bsdimp.com> To: scottl@samsco.org From: "M. Warner Losh" In-Reply-To: <410D2FEA.5050504@samsco.org> References: <410D2FEA.5050504@samsco.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: PCI-Express support X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Aug 2004 18:54:36 -0000 In message: <410D2FEA.5050504@samsco.org> Scott Long writes: : Proper support likely entails splitting up the pci host-bridge drivers : so that a given ACPI or legacy front-end can plug into a given enhanced : or legacy configuration layer. This definitely is not going to happen : in time for 5.3, though. A hack that could work for 5-STABLE would be : to provide pcie_[read|write]_config() methods that would compliment the : existing pci methods and be available for drivers that want to access : the >255 configuration addresses. Devices are already showing up that : want to use these registers, btw. The mechanics of doing this would : involve using pmap_mapdev() to map in the range that is specific to each : function, and then hang this information off of the pcicfg structure. : It's a bit hackish, yes, but it does seem to work in tests that a : colleague of mine has done. Why not just have the bridge do a bus_alloc_resource for those things? That would cause the pmap_mamdev() to happen behind the scenes. We already do a number of things like this in the CardBus driver, but on a smaller scale. But is there really a reason we need pcie_*_config routines? wouldn't the pcib_* routines do the same job nicely? They are already virtualized so that we can plug in the pcie bridge functionality to the existing bridge drivers if there is a pcie structure allocated to the pcicfg. Why invent an interface that we know we're going to deprecate in short order when the existing interface can be used. In the pci_pci.c code, we could add a couple of ifs in pcib_{read,write}_config if the bridge supports it, for example. Warner