newbus ioport usage

[Nate Lawson]

On Tue, 3 Feb 2004, M. Warner Losh wrote:
> [[ I'll draft a longer reply this evening ]]

Great.

> In message: <20040203111312.Q32201 at root.org>
>             Nate Lawson <nate at root.org> writes:
> : 1. Do I have to do all the bus_set_handle gyrations found in nexus?
>
> I think so.  I'd have to look at the code.  You may be able to  copy
> the bus_handle from the BUS_ALLOC_RESOURCE resource.

I'm not quite sure how things work but I think I shouldn't have to do any
post-processing of resources retrieved from BUS_ALLOC_RESOURCE.  The nexus
should do all the original setup and then I am just storing it in an rman
pool with rman_manage_region.  The handle may need to be regenerated when
allocating a resource out of the rman pool (later), especially if the
range changes.  For example, if I BUS_ALLOC_RESOURCE 4 I/O ports and
manage the whole region in rman, a later rman_release_resource and then
rman_reserve_resource of 1 of them should re-set the bus handle.

I can post the code if it would help.  It makes my laptop hard reset a
little ways into the boot.  ;-)  But for now, I think all I need to know
is what I need to do differently in acpi than in the nexus.  The
differences as I see it are:

1. No previous knowledge of start/end for my rman pools.  Call
rman_manage_region for each resource retrieved from nexus.

2. Try a BUS_ALLOC_RESOURCE first instead of going straight to the rman
pool.

3. Always release to the local rman pool, not the parent.

4. Skip most bus handle initialization that is already done in nexus.

I'm sure there are problems with these assumptions.

> : I
> : thought that they could be dispensed with since nexus should do all those
> : when acpi0 allocates resources from it with BUS_ALLOC_RESOURCE.
>
> It all depends on the details (eg, I'd have to look at the code you
> are writing).
>
> : In the future, I'll make two passes, first to detect system resource
> : objects (PNP0C01 and PNP0C02) and reserve resources and the second to
> : actually probe acpi devices.  I'd rather wait for newbus to do this
> : multi-pass approach than attempt it myself with hacks to try to localize
> : it.
>
> Yes.  We need a better discovery phase followed by an attach phase.  I
> don't know if this is a newbus API change yet or not.  I can see it
> being done with most of the APIs that are in place now, but a few
> tweaks might be in order.

I could implement this in acpi since we already make two attach passes for
busses like PCI.  Perhaps the general case could be a flags argument that
is passed through to the attach handler that says what pass this is.

-Nate