Date: Tue, 27 Jan 2004 23:13:41 -0800 (PST) From: Nate Lawson <nate@root.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: msmith@freebsd.org Subject: Re: newbus ioport usage Message-ID: <20040127225912.A77804@root.org> In-Reply-To: <20040127.153120.67922084.imp@bsdimp.com> References: <20040127133251.W75080@root.org> <20040127.150936.73380598.imp@bsdimp.com> <20040127.153120.67922084.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 27 Jan 2004, M. Warner Losh wrote:
> In message: <20040127141708.O75272@root.org>
> Nate Lawson <nate@root.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040127225912.A77804>