newbus ioport usage

[M. Warner Losh]

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