From owner-freebsd-acpi@FreeBSD.ORG Fri Jul 7 17:38:58 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C6A216A4E1; Fri, 7 Jul 2006 17:38:58 +0000 (UTC) (envelope-from takawata@init-main.com) Received: from ns.init-main.com (104.194.138.210.bn.2iij.net [210.138.194.104]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC5D043D49; Fri, 7 Jul 2006 17:38:57 +0000 (GMT) (envelope-from takawata@init-main.com) Received: from init-main.com (localhost [127.0.0.1]) by ns.init-main.com (8.13.6/8.13.3) with ESMTP id k67HcmJG006425; Sat, 8 Jul 2006 02:38:55 +0900 (JST) (envelope-from takawata@init-main.com) Message-Id: <200607071738.k67HcmJG006425@ns.init-main.com> To: freebsd-acpi@freebsd.org In-reply-to: Your message of "Fri, 07 Jul 2006 12:40:56 -0400." <200607071240.57062.jhb@freebsd.org> Date: Sat, 08 Jul 2006 02:38:48 +0900 From: Takanori Watanabe Cc: atkin901@yahoo.com Subject: Re: acpi on msi-9218 (-current) swaps sio0 and sio1 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2006 17:38:58 -0000 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?