From owner-freebsd-acpi@FreeBSD.ORG Mon Jul 10 14:35:22 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 F402A16A505 for ; Mon, 10 Jul 2006 14:35:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF44343D49 for ; Mon, 10 Jul 2006 14:35:20 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k6AEZ8dZ061078; Mon, 10 Jul 2006 10:35:18 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: "M. Warner Losh" Date: Mon, 10 Jul 2006 10:26:19 -0400 User-Agent: KMail/1.9.1 References: <200607071240.57062.jhb@freebsd.org> <20060709.014658.-460542464.imp@bsdimp.com> In-Reply-To: <20060709.014658.-460542464.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607101026.20045.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [192.168.0.1]); Mon, 10 Jul 2006 10:35:18 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1590/Mon Jul 10 01:34:09 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: freebsd-acpi@freebsd.org, 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: Mon, 10 Jul 2006 14:35:22 -0000 On Sunday 09 July 2006 03:46, M. Warner Losh wrote: > 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. The problem is that ACPI enumerates ISA devices just like PNP BIOS. A serial port is not an "ACPI device" on an ACPI bus. It's an ISA device that the BIOS enumerates because the ISA bus itself is too dumb/simple/whatever to enumerate itself. If you look at the actual device tree in ACPI, it looks like this: _SB_ \-- PCI0 \-- ISA0 \-- COMA If we actually followed this in new-bus we'd have: acpi0 pcib0 pci0 isab0 isa0 sio0 However, instead of making an ACPI-aware isa0 (which we have done for pcib0 and pci0 to get PCI interrupt routing to work correctly in ACPI-land) we attach ISA devices directly to acpi0. We should treat the ACPI case similar to the PNPBIOS case for enumerating built-in ISA devices. In both cases, whatever serial port contains the resources for 'sio.0' as specified in 'hints' should probe and attach as 'sio0' and take on non-resource hints such as 'flags' to mark the serial console. > 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. The serial console needs to work during boot. :-/ > 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). What you are missing here is that ISA is a "special case" of a non-enumerated bus in that there are side-band methods (PNPBIOS and ACPI) to enumerate it for you. ACPI can also provides some of the same stuff for other non-enumerated bus's such as SMB. > 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. My proposal is to add a method to bus drivers so they can tell new-bus when to do a hard-wiring operation. new-bus would by default not hand out hard-wired unit numbers unless the bus driver agrees to the match. -- John Baldwin