From owner-freebsd-arch@FreeBSD.ORG Tue Jan 27 14:10:31 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 5C8A516A4CE; Tue, 27 Jan 2004 14:10:31 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8018743D5A; Tue, 27 Jan 2004 14:09:43 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i0RM9gET098264; Tue, 27 Jan 2004 15:09:42 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 27 Jan 2004 15:09:36 -0700 (MST) Message-Id: <20040127.150936.73380598.imp@bsdimp.com> To: nate@root.org From: "M. Warner Losh" In-Reply-To: <20040127133251.W75080@root.org> References: <20040127125547.G74774@root.org> <20040127.141937.45155991.imp@bsdimp.com> <20040127133251.W75080@root.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 cc: msmith@freebsd.org Subject: Re: newbus ioport usage 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: Tue, 27 Jan 2004 22:10:31 -0000 In message: <20040127133251.W75080@root.org> Nate Lawson writes: : On Tue, 27 Jan 2004, M. Warner Losh wrote: : > In message: <20040127125547.G74774@root.org> : > Nate Lawson writes: : > : Ok, let me propose a design and I'd appreciate your comments. The probe : > : routine for acpi_sysresource will stay the same. The attach will allocate : > : the resources to its parent device (acpi0). : > : : > : acpi0 will make this set of resources available to its children via a : > : flag included with bus_alloc_resource, say ACPIDEV_REQUEST. If : > : acpi_resource_alloc finds a range already has that flag set, it will : > : refuse the request. Otherwise, it will release that range and then : > : immediately allocate it to the child. : > : > That seems overly convoluted. Why not just allocate it in acpi0? If : > a driver requests something that acpi0 has allocated, it assigns it to : > the child and takes it out of its resource manager. If not, then it : > passes things up a level in the tree. No special flags needed, : > although acpi does get a little more complicated. This will ensure : > that the resources are owned by someone, and can easily be delegated. : > These resource ranges are there to be used by acpi, and only acpi. : : So acpi0 would do a resource_list_delete for the given resource if it's in : the list and then perform the alloc request. This would then succeed : since no one owns the resource at that point. Once it succeeds, the child : owns the range and it can't be stolen. And I guess when the child : releases the range, acpi0 can reclaim all such resources. I wouldn't want : a pccard device plugged in later to grab the IO ports after a child : temporarily releases them (say while the ACPI Performance cpufreq driver : is unloaded and then reloaded). Right, that's why it would delegate the resource. This implies that when the delegation is released, it would go back to being owned by acpi0. : > There's nothing magical about the acpi_sysresource device, and it can : > be relegated to the scrap-heap of history if needed. : : Well, the way we find out about the resources is through a pseudo-device : with a PNPID. So it makes sense to use the normal device discovery method : to find these resources. This leads me to do the allocation for the : parent by the acpi_sysresource0 attach method. This gets ugly. The reason that I suggested not doing the discovery this way is because you want to allocate *ALL* resources up front before giving any to any children. pci has issues with this right now that I'm working to fix. Warner