acpi on msi-9218 (-current) swaps sio0 and sio1

[John Baldwin]

On Thursday 06 July 2006 16:15, Nate Lawson wrote:
> > Ahh ok. You must forgive me if I seem dense since this is the first time
> > I've looked at repairing these types of instruction files.   Are you
> > saying that the order that they appear in the .asl is important?
> 
> Yes, that's what he means.  Move the whole Device (COMA) { ... } section 
> before COMB if that's what you want.
> 
> Ultimate solution is probably to implement _SRS support (set resource) 
> so that we can reconfigure the devices according to their desired order. 
>   That's not even on anyone's todo list I think.

That actually wouldn't fix it.  One of the issues here with the backwards com 
ports is that the serial port ends up on sio0 by default, so if sio0 ends up 
as COM2, then the kernel ends up switching to a different port for its serial 
console (or it just uses a different one than the rest of the bootstrap).  
Since COMA is wired to com1 and COMB is wired to the com2 port on the 
motherboard, merely swapping the resources around will end up with the same 
end result: sio0 will be COMB == com2, and sio1 will be COMA == com1.  The 
real solution is to allow for hints to be used to "wire" unit numbers.  I 
thought about this on my drive into work today and came up with a rough 
design:

First, when new-bus goes to probe a device, it currently temporarily assigns 
it a unit number for each candidate driver.  If new-bus ends up using that 
driver for the device, the unit number "sticks".  Right now the unit number 
allocation is rather simple, it just uses the highest unit attached so far + 
1.  What I would like it to do is start with unit 0 and look for a free unit 
number each time.  The first test would be if the unit has an assigned device 
already.  Secondly, for each unit we would see if there were any matching 
hints for that (driver-name, unit) pair.  If so, then we'd call a method in 
the parent device (would be a new bus_if.m method called 
bus_hint_compatible() or something) to determine if this device is compatible 
with the specified hints and can thus "take over" the hint-specified device 
or if it should skip this unit number.

The default implementation would for bus_hint_compatible() would be to reject 
the hint device if it contains any resource hints (irq, port, mem, drq).  
This would mostly preserve existing behavior for things like the PCI bus (it 
would also remove the need for the current hack in sio to try to bump up the 
unit number of PCI sio(4) devices to leave sio0 and sio1 open for COM1 and 
COM2).  For the ISA and ACPI bus drivers though, they would actually compare 
the resource hints to see if they were a subset of the resources assigned to 
the device_t via PnP or ACPI.  For example, they would make sure the IRQ 
matched if it was assigned, or that the port. mem, and drq resources were 
contained in at least one of the port, mem, or drq resources that device had.  
Thus, you could wire sio0 to the default COM1 by specifying 0x3f8 for the 
port (in fact, our default device.hints file would Just Work(tm) for things 
like COM ports with this) regardless of the order of COM1 or COM2 in the ASL 
or PnP BIOS list.

This also makes it possible to define other hint mechanisms if we wanted.  For 
example, if you wanted to swap the unit numbers of two PCI NIC cards for some 
reason you could maybe do something like 'hint.fxp.0.slot="0.4.0"' to 
hardcode fxp0 as being the card at bus 0, device 4, function 0 and teach the 
PCI bus driver to grok that hint.

While this would make the search for unit numbers slower (potentially O(n^2)
to walk the list of units and walk the list of hints for each unit), that may 
not be a problem since we do that fairly rarely.  If needed we could also 
come up with some sort of caching mechanism for the hint search as that is 
the part I expect would be the slowest.  Probably easier to just do the 
simple implementation first and only try to optimize if we need it.

-- 
John Baldwin