Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 27 Jan 2004 14:23:15 -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:  <20040127141708.O75272@root.org>
In-Reply-To: <20040127.150936.73380598.imp@bsdimp.com>
References:  <20040127125547.G74774@root.org> <20040127.141937.45155991.imp@bsdimp.com> <20040127.150936.73380598.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: <20040127133251.W75080@root.org>
>             Nate Lawson <nate@root.org> 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).

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).

-Nate



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040127141708.O75272>