From owner-freebsd-arch@FreeBSD.ORG Tue Jan 27 13:41:30 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 1B49516A4CE for ; Tue, 27 Jan 2004 13:41:30 -0800 (PST) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id B5A9243D5D for ; Tue, 27 Jan 2004 13:41:28 -0800 (PST) (envelope-from nate@root.org) Received: (qmail 75131 invoked by uid 1000); 27 Jan 2004 21:40:18 -0000 Date: Tue, 27 Jan 2004 13:40:18 -0800 (PST) From: Nate Lawson To: "M. Warner Losh" In-Reply-To: <20040127.141937.45155991.imp@bsdimp.com> Message-ID: <20040127133251.W75080@root.org> References: <20040127.032119.28084825.imp@bsdimp.com> <20040127125547.G74774@root.org> <20040127.141937.45155991.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 21:41:30 -0000 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). > 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. -Nate