From owner-freebsd-new-bus@FreeBSD.ORG Mon Oct 2 17:42:46 2006 Return-Path: X-Original-To: freebsd-new-bus@freebsd.org Delivered-To: freebsd-new-bus@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E96B16A40F for ; Mon, 2 Oct 2006 17:42:46 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6BD6343D46 for ; Mon, 2 Oct 2006 17:42:45 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k92HekYT078501; Mon, 2 Oct 2006 11:40:46 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 02 Oct 2006 11:39:54 -0600 (MDT) Message-Id: <20061002.113954.756907493.imp@bsdimp.com> To: john@baldwin.cx From: "M. Warner Losh" In-Reply-To: <200610021323.50997.john@baldwin.cx> References: <200610021323.50997.john@baldwin.cx> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 02 Oct 2006 11:40:46 -0600 (MDT) Cc: freebsd-new-bus@freebsd.org Subject: Re: Properly managing sub-allocations X-BeenThere: freebsd-new-bus@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD's new-bus architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2006 17:42:46 -0000 In message: <200610021323.50997.john@baldwin.cx> John Baldwin writes: : I'm trying to cleanup a few things in apci and I ran into what I think is a : new-bus architecture issue. Specifically, acpi likes to allocate system : resource resources from its parent, and then turn around and sub-alloc those : out to children. This mostly works fine except for the bus space details of : the bus tag and bus handle. Currently acpi(4) just copies the tag from the : corresponding resource from the parent and sets the handle to the start of : the resource. This just happens to work currently because i386 and amd64 use : the start of the resource for the handle for SYS_RES_IO and overwrite the : handle in nexus_activate_resource() for SYS_RES_MEMORY. This does add some : ugliness though in that acpi needs to go find the parent resouce to copy the : bus tag. However, it's current algorithm wouldn't work in general (PC98 : needs to alloc bus handles, and it does so in nexus_alloc_resource() for : example). : : To solve this, I think we need to stop setting bus tags and handles in : bus_alloc_resource(). One solution might be to add a new bus method to set : those for a resource, but I think the better solution would be to set the bus : tags and handles in bus_activate_resource(). It already sort of does this : for some cases (SYS_RES_MEMORY on x86 for example) and will work with the : existing ACPI model (it already passes up activate_resource to the parent, so : we would just have to remove the explicit setting of the bus tag and handle). : : I actually wonder if this isn't how things are supposed to be in the first : place and that the current aberrations are just bugs? I think you are right. Thinking about it, you can't access the resources until you've activated them... However, this may break some existing drivers that allocate a BAR, peek at its type and then either activate it or allocate another BAR... The TAG is valid, but the handle isn't. This specific problem will never happen in pc98, since there are no ACPI pc98 machines and can never be. Warner