From owner-freebsd-arch@FreeBSD.ORG Tue Jan 27 23:13: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 1A98016A4CE for ; Tue, 27 Jan 2004 23:13:49 -0800 (PST) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 0D21843D55 for ; Tue, 27 Jan 2004 23:13:39 -0800 (PST) (envelope-from nate@root.org) Received: (qmail 77898 invoked by uid 1000); 28 Jan 2004 07:13:41 -0000 Date: Tue, 27 Jan 2004 23:13:41 -0800 (PST) From: Nate Lawson To: "M. Warner Losh" In-Reply-To: <20040127.153120.67922084.imp@bsdimp.com> Message-ID: <20040127225912.A77804@root.org> References: <20040127133251.W75080@root.org> <20040127.150936.73380598.imp@bsdimp.com> <20040127.153120.67922084.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: Wed, 28 Jan 2004 07:13:49 -0000 On Tue, 27 Jan 2004, M. Warner Losh wrote: > In message: <20040127141708.O75272@root.org> > Nate Lawson writes: > : > : 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. > : > : I'm pretty sure there is no other way to know what resources acpi devices > : will be using without evaluating the resource pseudo-device. The other > : way (which we currently do) is assume everything is available and let each > : driver grab whatever is free and then attach the resource pseudo-device > : last to claim all remaining acpi resources. Unless you have a better > : idea, the short-term approach will not change any of the above. It will > : just add the ability for acpi devices to later reclaim resources from > : acpi0 (by having acpi_sysresource0 attach remaining resources to its > : parent). > > You could add acpi_sysresource as the first child, which would get > around the issues. It could then call a private method on its parent > to give it the resources. But why couldn't that code be moved up into > parent? I guess I'm not understanding the difficulty here, because > right now there's only one sysresource, and it does: As usual, the devil is in the details. If we want to attach the resources first, we must add another namespace walk first. (And while we're at that, I'd add another pass to hook up the embedded controller after the resources so all other devices if they ignore _REG will still work. I think this is needed for some Gateways.) Instead, let's assume we keep the current approach to keep this simpler. The first step is to move the resource attach code into acpi0. As we walk the tree, when we hit a resource object, set the resources and then attach them immediately: @@ -1035,7 +1040,10 @@ * device. Ignore the return value here; it's OK for the * device not to have any resources. */ acpi_parse_resources(child, handle, &acpi_res_parse_set); if (!acpi_disabled("sysresource") && acpi_MatchHid(dev, "PNP0C02")) { acpi_parse_resources(bus, acpi_get_handle(bus), &acpi_res_parse_set); device_probe_and_attach(bus); continue; } else acpi_parse_resources(child, handle, &acpi_res_parse_set); /* If we're debugging, probe/attach now rather than later */ ACPI_DEBUG_EXEC(device_probe_and_attach(child)); Now acpi0 owns the resources. In acpi_alloc_resource, I call resource_list_alloc(). If it returns NULL, then loop through all rids, calling resource_list_find() on each. For each that it finds, check if rl->start + rl->count overlaps the requested address. If so, free this resource via resource_list_free(), call BUS_ALLOC_RESOURCE() for the caller's resource, then generate a new resource_list_alloc() for the truncated range. This would be unnecessary if we had a way to free a partial range of a resource, but it appears this is the only way. Thoughts? -Nate