From owner-freebsd-new-bus Tue Aug 27 13:36:48 2002 Delivered-To: freebsd-new-bus@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B80737B400 for ; Tue, 27 Aug 2002 13:36:44 -0700 (PDT) Received: from mail.speakeasy.net (mail14.speakeasy.net [216.254.0.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id C12BF43E72 for ; Tue, 27 Aug 2002 13:36:43 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 16847 invoked from network); 27 Aug 2002 20:36:43 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail14.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 27 Aug 2002 20:36:43 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.5/8.12.5) with ESMTP id g7RKaeBQ039798 for ; Tue, 27 Aug 2002 16:36:40 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Tue, 27 Aug 2002 16:36:43 -0400 (EDT) From: John Baldwin To: new-bus@FreeBSD.org Subject: Fixing ISA device probing Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG The original reason for bringing this up: ACPI currently bogusly attaches ACPI-enumerated ISA devices to acpi0 instead of to an ACPI-aware ISA bus driver. After talking some with Warner offline we have come up with the following rough ideas and possible layout. This would probably be a big change but hopefully it can be broken down into a few chunks. Currently we have several types of ISA devices: - Devices enumerated by the BIOS. Currently we have two types: those enumerated by ACPI and those by the PNPBIOS. These two sets are mutually exclusive. - PnP ISA devices. - ISA devices that only the user can tell us about (currently they can use hints to tell us). All ISA busses can have the last two devices, but the first set of devices are not always present. Thus it makes sense to possibly have 3 ISA bus drivers: - A basic ISA bus which supports PnP ISA devices and hint devices (mostly what we have now but without PnPBIOS support) - A PNPBIOS ISA bus which inherits from the basic ISA bus with the addition of PNPBIOS devices. - An ACPI ISA bus which inherits from the basic ISA bus with the addition of ACPI-enumerated ISA devices. This in itself is not but so hard and perhaps we could do this as the first step. However, there are some annoying inconsistencies with our current hints mechanism. Namely, we don't support "merging" a hints device with an otherwise-enumerated device. For example, if I just have a single hint for sio0: hint.sio.0.flags=0x10 That flag should get applied to the sio0 enumerated by either ACPI or the PNPBIOS. How can this be done? Well, first of all, we can determine whether a hint device can be merged with a BIOS-enumerated ISA device by checking the resources. To do this, we can check if the resources of the hint device form a subset of the resources in the enumerated device? This should be slightly stronger than just being a strict subset, however. For example, in the case of I/O ports the port in the hint should match the first port in one of the port resources for the PnP device. If a resource is not specified in the hint then it would match the first such device. Thus, if I give the port associated with com2 in addition to the 'sio0' hint above as an sio0 port, then com2 should be attached as com2 and we should merge the sio0 hint device with the com2 PNPBIOS device. Next, if the resources do match, we can do a test probe. This is because hint devices are hardwired to a driver and unit as opposed to BIOS-enumerated devices which are not. For the test probe, we assign the BIOS-enumerated device the driver and unit of the hint device and then do our probe. If the probe succeeds we toss the hint device. If it fails, then we change the BIOS-enumerated device back to not having a driver yet and continue. We would then iterate through each hint device trying to match it against any BIOS-enumerated devices that have not already done a successful probe. Once that is done, the bus driver would probe any remaining unprobed BIOS-enumerated devices and then let the generic ISA bus handle remaining PnP and hint devices. This would give us hardwiring of devices as well as supplying hints to BIOS-enumerated devices. Note that I haven't covered applying those to PnP devices not enumerated by the BIOS. Presumably, the generic ISA bus could attempt to do its own hint device merging where appropriate. Unfortunately, we would need to fix a few things before taking this second step. Specifically, device probes need to be just that: probes. attach routines should not require that special magic be done in probe for them to work properly. For example, to avoid the "sensitive driver" problem we currently have, when an ISA device probes, if the device being probed has an HID, then the probe routine should only check to see if the HID matches or not and then return. This would allow the test probes during hint-merging for BIOS-enumerated or PNP devices to work w/o having negative side effects. Comments? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Thu Aug 29 12:12:34 2002 Delivered-To: freebsd-new-bus@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0DEC37B400; Thu, 29 Aug 2002 12:12:32 -0700 (PDT) Received: from sasami.jurai.net (sasami.jurai.net [66.92.160.223]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4270A43E6E; Thu, 29 Aug 2002 12:12:32 -0700 (PDT) (envelope-from winter@jurai.net) Received: from sasami.jurai.net (sasami.jurai.net [66.92.160.223]) by sasami.jurai.net (8.12.5/8.12.2) with ESMTP id g7TJCUOw046207; Thu, 29 Aug 2002 15:12:30 -0400 (EDT) (envelope-from winter@jurai.net) Date: Thu, 29 Aug 2002 15:12:30 -0400 (EDT) From: "Matthew N. Dodd" To: John Baldwin Cc: new-bus@FreeBSD.ORG Subject: Re: Fixing ISA device probing In-Reply-To: Message-ID: <20020829150953.N788-100000@sasami.jurai.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 27 Aug 2002, John Baldwin wrote: > Currently we have several types of ISA devices: > - Devices enumerated by the BIOS. Currently we have two types: those > enumerated by ACPI and those by the PNPBIOS. These two sets are > mutually exclusive. > - PnP ISA devices. > - ISA devices that only the user can tell us about (currently they can > use hints to tell us). We can also have devices that perform their own enumerated either by probing a list of possible IO addresses and retreiving their config from the card directly ('ex') or by performing a probe using an isolation protocol similar ISA PnP ('ep'). I won't get into destructive vs. non-destructive probes. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Fri Aug 30 9:46:55 2002 Delivered-To: freebsd-new-bus@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E38E37B400 for ; Fri, 30 Aug 2002 09:46:52 -0700 (PDT) Received: from mail.speakeasy.net (mail16.speakeasy.net [216.254.0.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id CDB8F43E6A for ; Fri, 30 Aug 2002 09:46:51 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 20723 invoked from network); 30 Aug 2002 16:46:59 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail16.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 30 Aug 2002 16:46:59 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.5/8.12.5) with ESMTP id g7UGkjBQ049406 for ; Fri, 30 Aug 2002 12:46:45 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Fri, 30 Aug 2002 12:46:47 -0400 (EDT) From: John Baldwin To: new-bus@FreeBSD.org Subject: Avoiding probing Host-PCI bridges twice on i386 Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ok, I have the following kind of ugly hack to keep the nexus from probing host-pci bridges when ACPI is found. It is still a hack but it works for the same reason that ACPI currently probes PCI devices ok: ACPI gets its identify routine called first: Index: pci_bus.c =================================================================== RCS file: /usr/cvs/src/sys/i386/pci/pci_bus.c,v retrieving revision 1.83 diff -u -r1.83 pci_bus.c --- pci_bus.c 2 Aug 2002 18:45:43 -0000 1.83 +++ pci_bus.c 30 Aug 2002 13:19:03 -0000 @@ -290,7 +290,7 @@ int found_orion = 0; int found_pcibios_flaming_death = 0; device_t child; - devclass_t pci_devclass; + devclass_t devclass; if (pci_cfgregopen() == 0) return; @@ -299,10 +299,17 @@ * via some other means. If we have, bail since otherwise * we're going to end up duplicating it. */ - if ((pci_devclass = devclass_find("pci")) && - devclass_get_device(pci_devclass, 0)) + if ((devclass = devclass_find("pci")) && + devclass_get_device(devclass, 0)) + return; + /* + * Check to see if the ACPI identify routine succeeded. If so, + * ACPI will find any host-PCI bridges so don't duplicate them + * here. + */ + if ((devclass = devclass_find("acpi")) && + devclass_get_device(devclass, 0)) return; - bus = 0; retry: I think, though, that really we should reorganize things a bit so that ACPI works right, not just by chance. We really need to somehow probe ACPI first, and then if it's identify routine (which is really a probe of an ACPI nexus-like device) fails, then we do the other nexus identifies. ACPI really is more of an alternate nexus almost. Perhaps on the i386 what we need is a kind of system-board/bus driver that attaches to the nexus. ACPI would be one driver, and a new driver would be made up of stuff that is currently in the nexus. I.e., if the ACPI probe fails, then our other driver's probe will succeed (maybe it is called system0 or something) and the system bus would be the one that the pci bus driver in sys/i386/pci/pci_bus.c would actually be an identify routine of. Does this make any sense? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Fri Aug 30 10:35:44 2002 Delivered-To: freebsd-new-bus@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 24F1637B400 for ; Fri, 30 Aug 2002 10:35:43 -0700 (PDT) Received: from mail.speakeasy.net (mail14.speakeasy.net [216.254.0.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6EA843E6E for ; Fri, 30 Aug 2002 10:35:42 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 9984 invoked from network); 30 Aug 2002 17:35:48 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail14.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 30 Aug 2002 17:35:48 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.5/8.12.5) with ESMTP id g7UHZeBQ049524 for ; Fri, 30 Aug 2002 13:35:40 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Fri, 30 Aug 2002 13:35:42 -0400 (EDT) From: John Baldwin To: new-bus@FreeBSD.org Subject: bus_generic_probe() is wrong I think Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG If we are going to support having multiple driver's for a given device which is a bus (like we do now for PCI busses and like I am doing for this concept of a system buson i386) then I think that bus devices do not need to go identify child devices until after they have won the probe and are being attached. Thus, I'm ending up calling bus_generic_probe() in my attach routines instead of my probe routines. Does this make sense or am I missing something? I at least have to do this in the system bus case here for the same reasons that when I added another PCI bus driver, I had to change the PCI drivers to add children devices (equivalent of doing an identify) during attach() time and not during probe() time. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Fri Aug 30 19:32:37 2002 Delivered-To: freebsd-new-bus@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CEF637B400; Fri, 30 Aug 2002 19:32:36 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 481D743E3B; Fri, 30 Aug 2002 19:32:35 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g7V2WY2F048726; Fri, 30 Aug 2002 20:32:34 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 30 Aug 2002 20:32:28 -0600 (MDT) Message-Id: <20020830.203228.35798916.imp@bsdimp.com> To: jhb@FreeBSD.ORG Cc: new-bus@FreeBSD.ORG Subject: Re: bus_generic_probe() is wrong I think From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: John Baldwin writes: : If we are going to support having multiple driver's for a given device : which is a bus (like we do now for PCI busses and like I am doing for : this concept of a system buson i386) then I think that bus devices do : not need to go identify child devices until after they have won the : probe and are being attached. Thus, I'm ending up calling : bus_generic_probe() in my attach routines instead of my probe routines. : Does this make sense or am I missing something? I at least have to do : this in the system bus case here for the same reasons that when I added : another PCI bus driver, I had to change the PCI drivers to add children : devices (equivalent of doing an identify) during attach() time and not : during probe() time. A more fundamental question is why bus_generic_probe() does the child attach/probe? In the probe routine, there's no guarantee that the bus will actually attach at some later point. Shouldn't that be in a bus_generic_attach() routine? The probe should just say 'is this bus here' and the attach should make it possible to then probe the children after a successful attach. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Fri Aug 30 19:59:55 2002 Delivered-To: freebsd-new-bus@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A105B37B400 for ; Fri, 30 Aug 2002 19:59:53 -0700 (PDT) Received: from mail.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2ADC943E77 for ; Fri, 30 Aug 2002 19:59:53 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 24701 invoked from network); 31 Aug 2002 02:59:51 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 31 Aug 2002 02:59:51 -0000 Received: from laptop.baldwin.cx (laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.12.5/8.12.5) with ESMTP id g7V2xoBQ050693; Fri, 30 Aug 2002 22:59:50 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020830.203228.35798916.imp@bsdimp.com> Date: Fri, 30 Aug 2002 22:59:52 -0400 (EDT) From: John Baldwin To: "M. Warner Losh" Subject: Re: bus_generic_probe() is wrong I think Cc: new-bus@FreeBSD.ORG Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 31-Aug-2002 M. Warner Losh wrote: > In message: > John Baldwin writes: >: If we are going to support having multiple driver's for a given device >: which is a bus (like we do now for PCI busses and like I am doing for >: this concept of a system buson i386) then I think that bus devices do >: not need to go identify child devices until after they have won the >: probe and are being attached. Thus, I'm ending up calling >: bus_generic_probe() in my attach routines instead of my probe routines. >: Does this make sense or am I missing something? I at least have to do >: this in the system bus case here for the same reasons that when I added >: another PCI bus driver, I had to change the PCI drivers to add children >: devices (equivalent of doing an identify) during attach() time and not >: during probe() time. > > A more fundamental question is why bus_generic_probe() does the child > attach/probe? In the probe routine, there's no guarantee that the > bus will actually attach at some later point. Shouldn't that be in a > bus_generic_attach() routine? The probe should just say 'is this bus > here' and the attach should make it possible to then probe the > children after a successful attach. Pretty much what I was saying. I have an atsys(4) driver btw that apm and nexus_pcib are now descendants of and only gets attached if the acpi identify fails in the jhb_acpipci p4 branch. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Fri Aug 30 20:27:55 2002 Delivered-To: freebsd-new-bus@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D405937B400; Fri, 30 Aug 2002 20:27:53 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23C3043E42; Fri, 30 Aug 2002 20:27:53 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g7V3Rq2F048993; Fri, 30 Aug 2002 21:27:52 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 30 Aug 2002 21:27:44 -0600 (MDT) Message-Id: <20020830.212744.52905008.imp@bsdimp.com> To: jhb@FreeBSD.org Cc: new-bus@FreeBSD.org Subject: Re: bus_generic_probe() is wrong I think From: "M. Warner Losh" In-Reply-To: References: <20020830.203228.35798916.imp@bsdimp.com> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: John Baldwin writes: : Pretty much what I was saying. I have an atsys(4) driver btw that apm : and nexus_pcib are now descendants of and only gets attached if the : acpi identify fails in the jhb_acpipci p4 branch. hmmmm, I like this. maybe a pc98sys(4) driver might also not be a bad idea. I'm not sure how pc98's nexus is related to i386's, but I know that there's a lot of intertwingling there that aren't immeidately apparent :-(. Looking at the files.pc98 list, it appears that it uses the i386 nexus. Of course at this point apm(98) and the pci host bridge stuff likely is the same between the two ports. So maybe atsys isn't quite the right name. This is one thing that's common between the two ports, even though a lot of the details of each of these beasts differ. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Fri Aug 30 21: 7:35 2002 Delivered-To: freebsd-new-bus@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3184137B400 for ; Fri, 30 Aug 2002 21:07:33 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95C8243E7B for ; Fri, 30 Aug 2002 21:07:31 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g7V47T2F049131 for ; Fri, 30 Aug 2002 22:07:29 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 30 Aug 2002 22:07:23 -0600 (MDT) Message-Id: <20020830.220723.10970697.imp@bsdimp.com> To: new-bus@FreeBSD.org Subject: ISA bus notes From: "M. Warner Losh" In-Reply-To: References: <20020830.203228.35798916.imp@bsdimp.com> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG If the system has ACPI: attach acpi_isabus else if the system has pnpbios attach pnpbios_isabus else attach isabus Then call the attached isa bus' attach routine. If appropriate, enumerate devices from the enumeration source. For acpi and pnpbios, lists of devices come from those enumeration sources. Since this information contains other information (such as IRQ, IOPORT, MEMORY, etc), these resources can be set on the children that are added. Then call the generic attach routine. The common code will then call any of the children's drivers identify routines, as it does now. The PnP ISA devices would then be added. Hints would then be added to the mix. If a given 'hint ball' matches to a device (with the above set resources), that device would be hard wired to that unit. Otherwise a new child is added. After all this enumeration happens, then the pnp isa devices are disabled. The children are then probed in the proper order (sensitive devices, then normal devices). PnP ISA devices are then re-enabled and the probe routines for them are called. I don't where winter's stuff fits into this... I've not done the research here to know for sure. Other than that, I think that we're going to be in good shape without hints on all but the most primitive machines (and lucky me, I have two of these beasties still in service or hot-standby). This is a bit of a re-hash of John's post, but I wanted to make sure that it was all summarized to make sure that we're not missing some step or anything. Look good? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Fri Aug 30 22:10:40 2002 Delivered-To: freebsd-new-bus@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 859A637B400 for ; Fri, 30 Aug 2002 22:10:37 -0700 (PDT) Received: from mail.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F86C43E4A for ; Fri, 30 Aug 2002 22:10:37 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 25191 invoked from network); 31 Aug 2002 05:10:35 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 31 Aug 2002 05:10:35 -0000 Received: from laptop.baldwin.cx (laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.12.5/8.12.5) with ESMTP id g7V5AYBQ050940; Sat, 31 Aug 2002 01:10:34 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020830.220723.10970697.imp@bsdimp.com> Date: Sat, 31 Aug 2002 01:10:36 -0400 (EDT) From: John Baldwin To: "M. Warner Losh" Subject: RE: ISA bus notes Cc: new-bus@FreeBSD.org Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 31-Aug-2002 M. Warner Losh wrote: > > If the system has ACPI: > attach acpi_isabus > else if the system has pnpbios > attach pnpbios_isabus > else > attach isabus > > Then call the attached isa bus' attach routine. If appropriate, > enumerate devices from the enumeration source. For acpi and pnpbios, > lists of devices come from those enumeration sources. Since this > information contains other information (such as IRQ, IOPORT, MEMORY, > etc), these resources can be set on the children that are added. Then > call the generic attach routine. The common code will then call any > of the children's drivers identify routines, as it does now. The PnP > ISA devices would then be added. Hints would then be added to the > mix. If a given 'hint ball' matches to a device (with the above set > resources), that device would be hard wired to that unit. Otherwise a > new child is added. After all this enumeration happens, then the pnp > isa devices are disabled. The children are then probed in the proper > order (sensitive devices, then normal devices). PnP ISA devices are > then re-enabled and the probe routines for them are called. > > I don't where winter's stuff fits into this... I've not done the > research here to know for sure. > > Other than that, I think that we're going to be in good shape without > hints on all but the most primitive machines (and lucky me, I have two > of these beasties still in service or hot-standby). > > This is a bit of a re-hash of John's post, but I wanted to make sure > that it was all summarized to make sure that we're not missing some > step or anything. > > Look good? Well, I think you are looking at it not quite from an OOP perspective. :) Try using the same model of overriding bus drivers that I use with ACPI and the PCI bus. Thus, instead of having the system try and know which kind of ISA bus to attach, you have three drivers for "isa": - acpi_isa (called "isa" though) whose probe routine only succeeds if it can read it's handle via ivars on itself. In all ACPI systems that I know of, we can handle this case fairly easily by providing an ACPI PCI-ISA bridge driver that adds ivar support for the child bus device like the ACPI PCI bus driver does; probe routine returns 0 on success - pnp_isa (again, "isa") whose probe routine only succeeds if PNPBIOS is detected. This probe routine can return -100 or some such. - isa (again, "isa") whose probe routine pretty much always succeeds and returns -1000 or some such This way, ISA busses become the right "flavor" of an ISA bus via normal probe/attach methods (i.e. we let the probe routines choose what type of ISA bus to use). I think we should leave the hint-device merging stuff until later as it requires to fix all the broken ISA drivers to get it right. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Fri Aug 30 22:10:43 2002 Delivered-To: freebsd-new-bus@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC5C937B401 for ; Fri, 30 Aug 2002 22:10:37 -0700 (PDT) Received: from mail.speakeasy.net (mail15.speakeasy.net [216.254.0.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F31E43E6A for ; Fri, 30 Aug 2002 22:10:37 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 13763 invoked from network); 31 Aug 2002 05:10:36 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail15.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 31 Aug 2002 05:10:36 -0000 Received: from laptop.baldwin.cx (laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.12.5/8.12.5) with ESMTP id g7V5AZBQ050943; Sat, 31 Aug 2002 01:10:35 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020830.212744.52905008.imp@bsdimp.com> Date: Sat, 31 Aug 2002 01:10:37 -0400 (EDT) From: John Baldwin To: "M. Warner Losh" Subject: Re: bus_generic_probe() is wrong I think Cc: new-bus@FreeBSD.org Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 31-Aug-2002 M. Warner Losh wrote: > In message: > John Baldwin writes: >: Pretty much what I was saying. I have an atsys(4) driver btw that apm >: and nexus_pcib are now descendants of and only gets attached if the >: acpi identify fails in the jhb_acpipci p4 branch. > > hmmmm, I like this. maybe a pc98sys(4) driver might also not be a bad > idea. I'm not sure how pc98's nexus is related to i386's, but I know > that there's a lot of intertwingling there that aren't immeidately > apparent :-(. Looking at the files.pc98 list, it appears that it uses > the i386 nexus. > > Of course at this point apm(98) and the pci host bridge stuff likely > is the same between the two ports. So maybe atsys isn't quite the > right name. This is one thing that's common between the two ports, > even though a lot of the details of each of these beasts differ. Actually, a pc98sys(4) wouldn't be that hard to do, but most of those differences are in things like rman management that is still in the nexus after my atsys(4) changes. If we want to merge that with AT-sys for now, that's no big deal, though I would need a better name for it. > Warner -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Fri Aug 30 22:53: 1 2002 Delivered-To: freebsd-new-bus@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7CB237B400 for ; Fri, 30 Aug 2002 22:52:58 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA83743E65 for ; Fri, 30 Aug 2002 22:52:31 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g7V5qU2F049473 for ; Fri, 30 Aug 2002 23:52:30 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 30 Aug 2002 23:52:24 -0600 (MDT) Message-Id: <20020830.235224.34542516.imp@bsdimp.com> To: new-bus@FreeBSD.org Subject: Re: ISA bus notes From: "M. Warner Losh" In-Reply-To: References: <20020830.220723.10970697.imp@bsdimp.com> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: John Baldwin writes: : Well, I think you are looking at it not quite from an OOP perspective. : :) Try using the same model of overriding bus drivers that I use : with ACPI and the PCI bus. Thus, instead of having the system try : and know which kind of ISA bus to attach, you have three drivers for : "isa": That's what the probe routines are for (oh, I see below you grok that too). The system doesn't really know. I just wrote the if to show the order. I wrote the driver names the way I did to make sure that they were separate drivers and we didn't try to cobble it all into the isa driver. : - acpi_isa (called "isa" though) whose probe routine only : succeeds if it can read it's handle via ivars on itself. In : all ACPI systems that I know of, we can handle this case fairly : easily by providing an ACPI PCI-ISA bridge driver that adds ivar : support for the child bus device like the ACPI PCI bus driver : does; probe routine returns 0 on success : - pnp_isa (again, "isa") whose probe routine only succeeds if : PNPBIOS is detected. This probe routine can return -100 or some : such. : - isa (again, "isa") whose probe routine pretty much always succeeds : and returns -1000 or some such Yup. We're on the same page here. Good detail catch. : This way, ISA busses become the right "flavor" of an ISA bus via : normal probe/attach methods (i.e. we let the probe routines choose : what type of ISA bus to use). I think we should leave the hint-device : merging stuff until later as it requires to fix all the broken ISA : drivers to get it right. Actually, it doesn't require that we fix them. In an ideal world we'd only match on the HID (and not touch hardware) if a HID was provided, but the more I've thought about it, the more I think that probing for the device after matching the HID is OK. If the device doesn't match the HID, the probe will fail anyway without touching the hardware. Touching hardware when we fail the probe is where we run into trouble. It is OK to touch the hardware if the probe routine returns 0 because no other hardware can attach to it. The hints merging stuff could be done later, or by someone else. It would just be a modification of the isahint.c file, since I think that it gets done at the right time. The pnpisa driver is also a child of the ISA bus with an identify routine, so that wouldn't be a special case. We'd have to make sure that the pnp driver's identify routine was called before the isahint driver's identify routine. I think that we could do that after calling bus_generic_attach() and moving the isahint code into the isa (generic one) bus driver. But that relates back to your other question here about bus_generic_probe vs bus_generic_attach :-). Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message