From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 19:17: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 7395716A419 for ; Fri, 28 Dec 2007 19:17:49 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by mx1.freebsd.org (Postfix) with ESMTP id 259D213C45B for ; Fri, 28 Dec 2007 19:17:49 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from source ([66.129.224.36]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Fri, 28 Dec 2007 11:17:15 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Dec 2007 11:16:39 -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 lBSJGh955854; Fri, 28 Dec 2007 11:16:45 -0800 (PST) (envelope-from marcelm@juniper.net) Message-Id: From: Marcel Moolenaar To: "M. Warner Losh" In-Reply-To: <20071228.114559.-311937481.imp@bsdimp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Fri, 28 Dec 2007 11:16:43 -0800 References: <20071228.114559.-311937481.imp@bsdimp.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 28 Dec 2007 19:16:39.0598 (UTC) FILETIME=[2C3204E0:01C84986] 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 19:17:49 -0000 On Dec 28, 2007, at 10:45 AM, M. Warner Losh wrote: > : The main part of the handshake seems to be the means > : for a driver to probe/match the hardware. In our > : implementation of ocpbus(4), we use an IVAR for the > : device type, as in: > : > : parent = device_get_parent(dev); > : error = BUS_READ_IVAR(parent, dev, OCPBUS_IVAR_DEVTYPE, > : &devtype); > : if (error) > : return (error); > : if (devtype != OCPBUS_DEVTYPE_PCIB) > : return (ENXIO); > : > : Since we only have 1 PCI-host controller driver to > : worry about, this is perfectly fine. However, if we > : want to generalize, then we probably need to extend > : the handshake to support different classes. Take > : for example an USB host controller. With EHCI, there's > : always at least 1 companion host controller (either > : OHCI or UHCI). Thus, checking if OCPBUS_DEVTYPE equals > : OCPBUS_DEVTYPE_USB (or something along those lines) is > : not enough. We need to know if it's an EHCI, OHCI or > : UHCI host controller. > > This is why I don't think it will work. The child device shouldn't be > checking to see if it is the right type or not. But that's how PCI works: the hardware has a vendor and device Id and the driver checks for combinations that it knows it can work with. Translated into IVARs, that means that there's a device tree or device list that mentions the existence of some DEVTYPE and DEVCLASS which the bus driver makes available through the IVARs and the driver checks if it's something it knows it can handle and attaches to the device of it does. > : Q1: Do people think it's worthwhile to pursue a generic > : ocpbus(4) definition? > > Generally, yes. In fact, I've done a bunch of things with what I've > called obio (On Board I/O) that does similar things, but relies > entirely on hints to do the job. Since that's how we do things > elsewhere, this seems like a reasonable approach. If we move to doing > things differently, then we can talk about that. Hints can be used to implement the device tree or device list, but is rather limited. I'd like us to implement something richer in the future. For that reason I don't want to expose hints to the driver, but rather abstract the implementation of the device tree or the device list behind IVARs. That makes it possible to implement the "bus" in many different ways without having to change the device drivers that attach to the bus. > I implemented obio as a set of routines rather than as a bus itself, > since doing the bus generically is going to be nearly impossible. > There's too many fussy bits of logic for this SoC or that SoC that > need to be in code. An abstract bus is just a means for devices to attach to. There's a bus driver component behind it, but that can be nexus(4) itself. The main purpose is to allow a single bus attachment to be used in various and many ways, so as to limit the flurry of single-use and one-off bus attachments. A single generic "bus" that does not imply anything about the underlying hardware or means of enumeration is the most flexible. > : Q2: Is there a better handshake possible than IVARs? > > Have the bus say "I have this or that on it" rather than having the > drivers themselves try to match. That way lies madness, I think, > since you'll soon wind up with lots of platform specific code > infecting the generic device drivers. Can you elaborate. I don't quite follow you. > : Q3: For probing, would DEVTYPE and DEVCLASS suffice or > : do we need something more or something else? > > Is this supposed to be a 'generic' replacement for the product/vendor > stuff ala pci or something else? I'm not sure that we can uniquely do > this in a generic enough way. Yes, it's akin to the vendor/product pair that PCI uses. As for being generic: I don't think we can account for every possible hardware upfront. What I think will work is something that can be extended. For example, for async serial hardware, DEVTYPE equals UART. For the various chips, DEVCLASS can be set accordingly. So, for standard PC hardware DEVCLASS equals NS8250. Since DEVTYPE and DEVCLASS are just numbers, we can add as many types and classes as we need. If we need to support a new network interface, we add it to DEVCLASS (DEVTYPE being NETIF or something). Existing drivers that only check DEVTYPE (which I'm sure we'll start with) will have to check DEVCLASS as well if there's going to be variation within DEVTYPE. > : Q4: What is minimally needed if we want to re-implement > : existing embedded busses using ocpbus(4)? > > The atmel at91 code is moving in this direction in p4, but uses the > obio routines I wrote. I'll take a look at obio. It seems to overlap in function with what I intend to do with ocpbus, so we may be able to turn obio into ocpbus or vice versa. -- Marcel Moolenaar marcelm@juniper.net