Date: Fri, 7 Jul 2006 12:40:56 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-acpi@freebsd.org Cc: othermark <atkin901@yahoo.com> Subject: Re: acpi on msi-9218 (-current) swaps sio0 and sio1 Message-ID: <200607071240.57062.jhb@freebsd.org> In-Reply-To: <44AD6F67.9060804@root.org> References: <e81i17$h7u$1@sea.gmane.org> <e8jalv$rs9$1@sea.gmane.org> <44AD6F67.9060804@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200607071240.57062.jhb>