Date: Sun, 09 Jul 2006 01:46:58 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: jhb@freebsd.org Cc: freebsd-acpi@freebsd.org, atkin901@yahoo.com Subject: Re: acpi on msi-9218 (-current) swaps sio0 and sio1 Message-ID: <20060709.014658.-460542464.imp@bsdimp.com> In-Reply-To: <200607071240.57062.jhb@freebsd.org> References: <e8jalv$rs9$1@sea.gmane.org> <44AD6F67.9060804@root.org> <200607071240.57062.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Sorry to toppost on this. But I'm curious. Why are such extensive
changes needed to newbus when a two-pass device adding scheme would
work nearly as well in the acpi layer? Likewise for pci and the 'wire
this unit to a location' solution. A minor change to newbus to never
assign a unit to a hinted device would be all that's needed.
The big problem that I see with your solution is that sio0 is hinted
on the isa bus, but not on the acpi bus. acpi should rightly ignore
the isa hints. If someone wants to hint (wire) an ACPI device, that
someone should wire it on the acpi bus. Or on whatever other
bus is appropriate.
There's a number of overlapping problems here.
First, we need some way to enumerate a bus that has no way of doing
that enumeration for itself. This used to be ISA bus, but these days
ISA slots are almost gone, and the need to completely enumerate the
ISA bus is almost nil because all on-board devices are enumerated by
the PNPBIOS or ACPI (although I have seen some exceptions on boards
that we buy for our embedded stuff at work). Many new busses are
going to be added to the tree (or existing busses augmented) to do the
proper hinting because they are not self enumerating. i2c is one such
bus that's not self-enumerating (although i2c variants, such as smb,
do exist that are nearly probeable).
Next, there's the desire to wire units to locations. This is done to
an extent in cam right now, but isn't newbus aware since cam isn't
newbus aware. Although a simple problem on its surface, it really is
an ugly one once you get down into it. One solution is to use devd to
configure based on more information than is present at probe time.
This solves the fxp0 in slot 3 becomes fxp1 when another fxp card is
inserted in the wrong slot. If you base your configuration on
location or attribtues (eg mac address) of the device, then you solve
the problem in a more generic and scalable way. The kernel will
likely never allow you to assign rl0 to 00:0f:b0:fd:ab:39 and rl1 to
00:0f:b0:fd:ca:23, for example, since that information isn't present
until attach time.
Finally, there's the redundant specification problem. People want
sio0 to attach to this thing in the back of the computer that's
labeled COMA, and whose resources are this or that. They know from
their computer's documentation that this is COM1, and windows assigns
it to COM1. This desire is due in part to it being the way we've
always selected sio0. It traditionally has been the serial port at
address 0x3f8. There's also the problem that the low level kernel
console driver wants to talk to the port by address, while the newbus
system wants to talk to it by how it probed. So you get odd
cross-threading when these two don't agree. If the cross threading
didn't exist, and the right thing happened, users wouldn't care how
that happened. devfs could be used if one could express A<->B
relationships in it. That would be an awkward solution, to say the
least. However, given the momentum of history here, I think we need
to accomidate Windows' practice of wiring their serial ports.
The first problem is totally solved by hints. I just extended it from
the one bus in the system that had it (ISA) to the many that will need
it (i2c, spi, etc). The second problem is solved by devd
generically. A limited subset of it could be solved using hints and a
lot of goo to add a lot of DWIM to newbus, but guessing at user
desires has never been a strong suit of unix. The third problem could
also be solved with hints and some minor adjustments to newbus. Each
bus could solve it differently, and likely should. But the number of
busses that need to solve it are small. ISA + PNPBIOS info is one,
and ACPI is another. I'm unaware of others where it is meaningful
(after all, you'd never think of doing it on the PCI bus, where
resource allocations fluxuate a lot).
I've actually given a lot of thought to problem 3, and have a scheme
worked out in my mind that I think will work well. I don't think it
needs to be complicated or even two passes if newbus never assigns a
unit number to a -1 device that has any hints at all. We could look
at devclass creation time and just create the devices that have hints
easily enough I think. It would mean gutting the current isahint
driver, I think, and hoisting its function up into isa proper. I
think it would also mean that PNP enumerated busses (ISA PNPBIOS and
ACPI's system resources) would need have some way of looking up a
device by its resources, and then for those it gets a 'hit' on, hard
wiring the device and the unit. The down side is that it makes it
harder for things that also live at COMx addresses to have different
drivers. Like IrDA ports and the like.
I'll have to see if I can code some of this up in p4 so we can hash
out what approach will work best.
Warner
P.S. The fdc issue is completely orthogonal to all of this. That's
purely a resource issue, and has nothing to do with device wiring...
It shows an unlying weakness in the resource model, but that's a topic
for another post...
In message: <200607071240.57062.jhb@freebsd.org>
John Baldwin <jhb@freebsd.org> writes:
: 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
: _______________________________________________
: freebsd-acpi@freebsd.org mailing list
: http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
: To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org"
:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060709.014658.-460542464.imp>