From owner-freebsd-arch@FreeBSD.ORG Sun Aug 1 20:48:53 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 890DC16A4CF for ; Sun, 1 Aug 2004 20:48:53 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCFEC43D48 for ; Sun, 1 Aug 2004 20:48:52 +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 i71KkIPA012829; Sun, 1 Aug 2004 14:46:18 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 01 Aug 2004 14:46:48 -0600 (MDT) Message-Id: <20040801.144648.102436632.imp@bsdimp.com> To: scottl@samsco.org From: "M. Warner Losh" In-Reply-To: <410D53A0.5080909@samsco.org> References: <410D2FEA.5050504@samsco.org> <20040801.125403.13772512.imp@bsdimp.com> <410D53A0.5080909@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 20:48:53 -0000 In message: <410D53A0.5080909@samsco.org> Scott Long writes: : M. Warner Losh wrote: : > 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 : : First, doing this the Right Way is not going to happen for 5.x. I'm : just trying to define an API to bridge us over for the short term. : There is no emulation shim defined for the extended config space, so : either we support it or we don't. As as I said, there are already : devices showing up that want to use the extended registers. : : Second, I'm trying to approach this in the least disruptive manner. : Yes, it could be abstracted so that pci_config_read|write() would : do the right things, but that would add risk to a whole lot of code : that we don't want to rototill at the moment. You asked how it should be done. I provided an opinion on how do to it. There's no reason to get grumpy when the opinion differs from what you wanted to hear. I offered my opinion about how to do this right. Maybe if you were to provide a more fleshed out design of what you are trying to achieve, it would be easier to provide feedback. Otherwise, I'm left to guess at what you have in mind and have you get mad at me when I don't do a good job at it. Warner