newbus ioport usage

[Nate Lawson]

On Mon, 26 Jan 2004, M. Warner Losh wrote:
> In message: <20040126191657.B31071 at root.org>
>             Nate Lawson <nate at root.org> writes:
> : On Mon, 26 Jan 2004, M. Warner Losh wrote:
> : > In message: <20040126165523.W30461 at root.org>
> : >             Nate Lawson <nate at root.org> writes:
> : > : Ok, I'm doing the set/alloc and it works.  However, one weird thing.  If I
> : > : allocate all ports at boot time, it succeeds.  My driver goes through
> : > : multiple release/allocate cycles and it all works as expected.  However if
> : > : I boot and attach to only one of the registers, subsequent attempts to
> : > : attach the second one fail.  The resources are 2 IO ports, 0x101c and
> : > : 0x101d.  Both are 1 byte.
> : >
> : > Deos devinfo -r show any cause for the problem?  Maybe you aren't
> : > releasing them properly?  Also, why not allocate them as a block of 2?
> :
> : Ok, I've found what's going on.  Apparently my acpi_sysresource0
> : pseudo-device is claiming all resources in its _CRS method.  If I don't
> : boot with 0x101c and 0x101d attached, it attaches to 0x1010-0x109d.  But
> : if I boot attaching them, it reserves less of the range.
> :
> :     acpi_cpu0
> :         I/O ports:
> :             0x101c
> :             0x101d
> :
> :     acpi_sysresource0
> :         I/O ports:
> :             0x10-0x1f
> :             0x24-0x25
> :             0x28-0x29
> :             0x2c-0x2d
> :             0x2e-0x2f
> :             0x30-0x31
> :             0x34-0x35
> :             0x38-0x39
> :             0x3c-0x3d
> :             0x50-0x53
> :             0x72-0x77
> :             0x90-0x9f
> :             0xa4-0xa5
> :             0xa8-0xa9
> :             0xac-0xad
> :             0xb0-0xb5
> :             0xb8-0xb9
> :             0xbc-0xbd
> :             0x101e-0x109d
> :             0x1180-0x11bf
> :             0x15e0-0x15ef
> :             0x1600-0x167f
> :
> : I'm not sure of a way around this.  All ASL I've seen keeps these
> : registers contiguous so I could whack out a block of 8 of them, although
> : that doesn't seem correct.  Perhaps acpi_cpu should be able to override
> : the acpi_sysresource0 allocations, maybe by asking it for the resource if
> : bus_resource_alloc returns NULL.  Thoughts?
>
> Have acpi bus own the resources that acpi_sysresource0 uses.

bus_set_resource(device_get_parent(dev), ...) ?

> Allow children to get at parts of that as they see fit.

Sounds good, but no idea how to implement this.  Would I have to implement
new parts to acpi_alloc_resource()?

-Nate