From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 18:24: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 399C716A418 for ; Fri, 28 Dec 2007 18:24:49 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by mx1.freebsd.org (Postfix) with ESMTP id E2B9713C43E for ; Fri, 28 Dec 2007 18:24:48 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from source ([66.129.224.36]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Fri, 28 Dec 2007 10:24:01 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 10:10:47 -0800 Received: from mini-g4.jnpr.net (mini-g4.jnpr.net [172.24.104.164]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id lBSIAv940852 for ; Fri, 28 Dec 2007 10:10:57 -0800 (PST) (envelope-from marcelm@juniper.net) Message-Id: From: Marcel Moolenaar To: embedded@freebsd.org 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 10:10:57 -0800 X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 28 Dec 2007 18:10:47.0266 (UTC) FILETIME=[F86C0420:01C8497C] Cc: Subject: 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 18:24:49 -0000 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. Anyway... Q1: Do people think it's worthwhile to pursue a generic ocpbus(4) definition? Q2: Is there a better handshake possible than IVARs? Q3: For probing, would DEVTYPE and DEVCLASS suffice or do we need something more or something else? Q4: What is minimally needed if we want to re-implement existing embedded busses using ocpbus(4)? Q5: Thoughts? Q6: Suggestions? Thanks, -- Marcel Moolenaar marcelm@juniper.net