From owner-freebsd-arch@FreeBSD.ORG Tue Jan 27 13:07:49 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 8481616A4CE for ; Tue, 27 Jan 2004 13:07:49 -0800 (PST) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 3882443D2F for ; Tue, 27 Jan 2004 13:06:59 -0800 (PST) (envelope-from nate@root.org) Received: (qmail 74877 invoked by uid 1000); 27 Jan 2004 21:05:08 -0000 Date: Tue, 27 Jan 2004 13:05:08 -0800 (PST) From: Nate Lawson To: "M. Warner Losh" In-Reply-To: <20040127.032119.28084825.imp@bsdimp.com> Message-ID: <20040127125547.G74774@root.org> References: <20040126.181720.15264443.imp@bsdimp.com> <20040126191657.B31071@root.org> <20040127.032119.28084825.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:07:49 -0000 On Tue, 27 Jan 2004, M. Warner Losh wrote: > In message: > Mike Smith writes: > : The whole reason for the sysresource device was to have something > : sitting on resources that the AML said had "something" behind them > : so that they didn't get handed out to devices on eg. PCI. If you're > : in the same sort of scope as the sysresource device, it's fair to > : say that you know more than eg. the PCI bus resource code does about > : whether you can use the resource in question. > > Yes. It is a form of resource enumeration that belongs to ACPI. > Therefore, ACPI should manage it and dole it out to its children which > are based on the AML. That's what it is there for. It is akin to the > PCI code assigning resources based on the BARs that a child has. > However, only akin, because the entire resource space is enumerated in > the bus, not the children, for ACPI. The sysresource stuff was a > means to an end, not the only way to that end. I'm starting to think > that the right way to go is to reserve EVERYTHING up front, and then > have all the acpi_foo devices allocate out of that reserveation. > > In this way it is similar to a BAR that has been assigned by the BIOS, > but isn't allocated by a child device on pci. In the code I'm working > on, those resources are reserved at the bus level and given to the > child if it asks for it later. Well, it is a little more complex than > that because the child device actually owns the resource, but the bus > is who assigns ownership. In ACPI, since the resource maps aren't > child specific, the ownership should resided in the bus layer. So > instead of belonging to acpi_sysresource0, it would belong to acpi0. > This may also help some downstream resource allocations, since they > would now be happening a little earlier in the game. 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. -Nate