Date: Sat, 08 Jul 2006 02:38:48 +0900 From: Takanori Watanabe <takawata@init-main.com> To: freebsd-acpi@freebsd.org Cc: atkin901@yahoo.com Subject: Re: acpi on msi-9218 (-current) swaps sio0 and sio1 Message-ID: <200607071738.k67HcmJG006425@ns.init-main.com> In-Reply-To: Your message of "Fri, 07 Jul 2006 12:40:56 -0400." <200607071240.57062.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200607071240.57062.jhb@freebsd.org>, 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.
We may want to use _UID resource to wire unit number.
How about tweaking acpi_probe_child function so that attaching by
_UID order?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200607071738.k67HcmJG006425>