From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 21:00:49 2007 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B61516A469 for ; Fri, 28 Dec 2007 21:00:49 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by mx1.freebsd.org (Postfix) with ESMTP id 16F8E13C458 for ; Fri, 28 Dec 2007 21:00:49 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from source ([66.129.224.36]) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP; Fri, 28 Dec 2007 13:00:41 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Dec 2007 12:55:47 -0800 Received: from mini-g4.jnpr.net (aparmelee-t41.jnpr.net [172.24.104.164] (may be forged)) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id lBSKtv978045; Fri, 28 Dec 2007 12:55:57 -0800 (PST) (envelope-from marcelm@juniper.net) Message-Id: From: Marcel Moolenaar To: "M. Warner Losh" In-Reply-To: <20071228.130329.43010549.imp@bsdimp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Fri, 28 Dec 2007 12:55:57 -0800 References: <20071228.114559.-311937481.imp@bsdimp.com> <20071228.121213.-494094613.imp@bsdimp.com> <20071228.130329.43010549.imp@bsdimp.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 28 Dec 2007 20:55:47.0253 (UTC) FILETIME=[05462650:01C84994] Cc: embedded@freebsd.org Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 21:00:49 -0000 On Dec 28, 2007, at 12:03 PM, M. Warner Losh wrote: > In message: > Marcel Moolenaar writes: > : On Dec 28, 2007, at 11:12 AM, M. Warner Losh wrote: > : > : > If the ocpbus has a table of bus types, what's wrong with having > it > : > directly assign the driver when it ads its children? > : > : It violates newbus in that drivers compete for a device. > : If the bus assigns the driver, then there's no competition > : possible. The fact that the bus is abstract should not > : mean that we should change its paradigm. > > No it doesn't. There's two kinds of busses in newbus. Those that > self enumerate based on the hardware present (ie pccard, pci, usb, > firewire) and then those that are told what's there (oldcard-style > pccard, pure ISA, I2C, etc). I don't make that distinction at all. I see a probe method that's called to match a driver to a device. Whether that probe method is called only when it's known up-front that the driver matches the device is, to me, irrelevant. All I'm trying to achieve is: 1. we can relief the SoC or bus driver from having to know about device drivers by allowing it to create wildcard children that are being probed and attached in a generic way by allowing probe methods to obtain information (in am abstract way) about the corresponding hardware so as to have everything fall into place. 2. Avoid a flurry of bus-attachments to generic drivers by providing an abstract bus to which they can attach and from which they can obtain whatever information they need to function (IVARs were suggested) so as to allow many instances of a single driver that's attached to many and varying busses. 3. Keep the separation between bus and device pure by only using a generic handshake or protocol to pass information from one to the other. This has nothing to do with the origin of the device tree (firmware, kernel or other) or whether the bus is self- enumerating or not. Any bus that's not self-enumerating is enumerable in some other shape or form, including those that need hardcoded tables in the kernel. I don't care and that's why I want it abstracted from drivers. They should not have to care either. > : > Plus the > : > problem is complicated because none of these devices is standard. > : > Sorry if my first reply came on a little strong on the enumeration > : > point. If there is a compelling argument for it, I'll listen, > but it > : > isn't as if we have competing drivers for devices in this domain > like > : > we did with sio vs uart. > : > : We should not abandon competition, because that would > : be a step away from generalization. Even though we're > : discussing this in the context of embedded systems, > : I don't see any reason why it couldn't equally apply to > : the LPC devices in PCs that are enumerated by ACPI... > > That's a different case. Do not confuse these cases. ACPI has a > table of devices that associated resources with an ID. There's no > such tables in the SoC world, typically. Yes there is. If the table is not in firmware, it typically is in the kernel. The ID may not be needed if the table references the driver directly, but other than that it's exactly the same. There's no confusion. There's simply no distinction. Somewhere it's recorded that something exists. The ocpbus(4) idea is to abstract the details of where that information comes from by making it available in a generic way. > At most, you have a CPU ID > you can read and from that know, based on a hardwired set of tables, > the devices that are present. My point exactly ;-) > It isn't extensible in any way when a > new CPU ID comes along. With ACPI you'd get new devices and you > wouldn't worry. With the new CPU ID in the SoC world, you'd get > nothing until you created a new table. It's irrelevant to the abstraction whether a new device is dynamically found or whether it needs to be added to some static table by virtue of a firmware or kernel upgrade. The ability to allow a dynamic scheme does not impact static schemes. -- Marcel Moolenaar marcelm@juniper.net