newbus ioport usage
M. Warner Losh
imp at bsdimp.com
Tue Jan 27 14:10:31 PST 2004
In message: <20040127133251.W75080 at root.org>
Nate Lawson <nate at root.org> writes:
: On Tue, 27 Jan 2004, M. Warner Losh wrote:
: > In message: <20040127125547.G74774 at root.org>
: > Nate Lawson <nate at root.org> writes:
: > : 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.
: >
: > That seems overly convoluted. Why not just allocate it in acpi0? If
: > a driver requests something that acpi0 has allocated, it assigns it to
: > the child and takes it out of its resource manager. If not, then it
: > passes things up a level in the tree. No special flags needed,
: > although acpi does get a little more complicated. This will ensure
: > that the resources are owned by someone, and can easily be delegated.
: > These resource ranges are there to be used by acpi, and only acpi.
:
: So acpi0 would do a resource_list_delete for the given resource if it's in
: the list and then perform the alloc request. This would then succeed
: since no one owns the resource at that point. Once it succeeds, the child
: owns the range and it can't be stolen. And I guess when the child
: releases the range, acpi0 can reclaim all such resources. I wouldn't want
: a pccard device plugged in later to grab the IO ports after a child
: temporarily releases them (say while the ACPI Performance cpufreq driver
: is unloaded and then reloaded).
Right, that's why it would delegate the resource. This implies that
when the delegation is released, it would go back to being owned by
acpi0.
: > 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.
Warner
More information about the freebsd-arch
mailing list