From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 19:13:07 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 09A0016A41B for ; Fri, 28 Dec 2007 19:13:07 +0000 (UTC) (envelope-from imp@BSDIMP.COM) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id A750813C465 for ; Fri, 28 Dec 2007 19:13:06 +0000 (UTC) (envelope-from imp@BSDIMP.COM) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lBSJ7Q0Z075776; Fri, 28 Dec 2007 12:07:27 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 28 Dec 2007 12:12:13 -0700 (MST) Message-Id: <20071228.121213.-494094613.imp@bsdimp.com> To: marcelm@juniper.net From: "M. Warner Losh" In-Reply-To: <20071228.114559.-311937481.imp@bsdimp.com> References: <20071228.114559.-311937481.imp@bsdimp.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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:13:07 -0000 In message: <20071228.114559.-311937481.imp@bsdimp.com> "M. Warner Losh" writes: : In message: : Marcel Moolenaar writes: : : All, : : : : As part of the PowerPC e500 port we created an ocpbus : : (On-Chip Peripheral bus), with devices likes uart(4). : : This, of course, is perfectly normal. In fact, it's so : : normal that I wondered why we don't have a single : : abstract bus already. : : : : What I'm thinking about is a handshake between bus : : driver and device drivers that makes it possible for : : us to create a single (abstract) bus attachment per : : driver, usable whenever that particular driver is : : used in an embedded environment. : : : : 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. : : : 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. : : 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. : : : 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. : : : 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. : : : 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. : : : Q5: Thoughts? : : Q6: Suggestions? A couple more thoughts: We can't have one generic bus for all the processors. But we maybe able to do the subclassing we do with PCI/Cardbus. We'd have to fix a couple of corner cases relating to device driver loading, but once those are fixed, we could have a generic base class. However, we're always going to need to specialize for two reasons. First, the on board devices are always attached in ways that require intimate knowledge of the board/soc. Sometimes this is which resources to give and what interrupts to use. Other times it can be what clocks to enable, or what GPIO pins are needed. Sometimes the devices in question need to do different things for different processors, even if the core of the driver is shared (like the ohci usb controller in the atmel vs in the Cirrus logic arm9). So we'll still need to have some specialization. If the ocpbus has a table of bus types, what's wrong with having it directly assign the driver when it ads its children? That would eliminate the probe part of child driver's routine, making it simpler to write. There are also some on board busses that are self enumerating (ARM defines a standard, and there's at least one similar standard used by some Broadcom MIPS chips). So any solution likely would need to take both models into account. I guess I agree with you that we need an abstraction layer, but quibble over the details. I especially object to creating an enumeration where an actual device driver name would do. 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. Warner