From owner-freebsd-arch@FreeBSD.ORG Tue Jan 27 14:33:23 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 67BFA16A4CE; Tue, 27 Jan 2004 14:33:23 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6690443D5D; Tue, 27 Jan 2004 14:32:38 -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 i0RMVQET098658; Tue, 27 Jan 2004 15:31:26 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 27 Jan 2004 15:31:20 -0700 (MST) Message-Id: <20040127.153120.67922084.imp@bsdimp.com> To: nate@root.org From: "M. Warner Losh" In-Reply-To: <20040127141708.O75272@root.org> References: <20040127133251.W75080@root.org> <20040127.150936.73380598.imp@bsdimp.com> <20040127141708.O75272@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:33:23 -0000 In message: <20040127141708.O75272@root.org> Nate Lawson writes: : On Tue, 27 Jan 2004, M. Warner Losh wrote: : > In message: <20040127133251.W75080@root.org> : > Nate Lawson writes: : > : > 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. : : 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: static int acpi_sysresource_probe(device_t dev) { if (!acpi_disabled("sysresource") && acpi_MatchHid(dev, "PNP0C02")) device_set_desc(dev, "System Resource"); else return (ENXIO); device_quiet(dev); return (-100); } static int acpi_sysresource_attach(device_t dev) { struct resource *res; int i, rid; /* * Suck up all the resources that might have been assigned to us. * Note that it's impossible to tell the difference between a * resource that someone else has claimed, and one that doesn't * exist. */ for (i = 0; i < 100; i++) { rid = i; res = bus_alloc_resource(dev, SYS_RES_IOPORT, &rid, 0, ~0, 1, 0); rid = i; res = bus_alloc_resource(dev, SYS_RES_MEMORY, &rid, 0, ~0, 1, 0); rid = i; res = bus_alloc_resource(dev, SYS_RES_IRQ, &rid, 0, ~0, 1, RF_SHAREABLE); } return (0); } I'm not sure that I see. : Allocating all resources up front would require multiple passes of the : namespace and I'm not ready to make that drastic of a change without some : more design work about how this fits in with the rest of FreeBSD (in : particular, PCI). Yes. We do need to redesign the probe/attach code to have multiple passes. Warner