From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 22:31:59 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 DFE4916A419 for ; Fri, 28 Dec 2007 22:31:58 +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 C343813C447 for ; Fri, 28 Dec 2007 22:31:58 +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 14:31:56 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 14:30:30 -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 lBSMUf998170; Fri, 28 Dec 2007 14:30:41 -0800 (PST) (envelope-from marcelm@juniper.net) Message-Id: <4FA37AAF-8113-44DE-8FF9-5BB203188912@juniper.net> From: Marcel Moolenaar To: "M. Warner Losh" In-Reply-To: <20071228.150443.-924279995.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 14:30:40 -0800 References: <20071228.130329.43010549.imp@bsdimp.com> <20071228.150443.-924279995.imp@bsdimp.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 28 Dec 2007 22:30:30.0620 (UTC) FILETIME=[40D321C0:01C849A1] 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 22:31:59 -0000 On Dec 28, 2007, at 2:04 PM, M. Warner Losh wrote: > We're never going to get around the fact that we have to have a > different bus attachment for each of the enumeration mechanisms in the > kernel. Euh... the whole point of our discussion is exactly about creating an abstraction layer that hides the details of the enumeration mechanism from the driver so that you can in fact have a single bus attachment. ocpbus(4) is inherently useless if we still need to create different bus attachments for different, bus similar, busses. While I don't intend ocpbus(4) to be the one and only bus attachment, it should at least unify busses and/or configurations that aren't self-enumerating. > If I understand your proposed method, then we would create a new > integer of some flavor assigned for each and every type of device > there is. You'd have us have something like: > > #define DEVICE_TYPE_UART 1 > #define DEVCIE_TYPE_NETIF 2 > #define DEVICE_TYPE_MMCSD 3 > #define DEVICE_TYPE_SYNC 4 > #define DEVICE_TYPE_SPI 5 > #define DEVICE_TYPE_WIRELESS 6 > #define DEVICE_TYPE_OHCI 7 > #define DEVICE_TYPE_PCIB 8 > #define DEVICE_TYPE_UHCI 9 > ... > > #define DEVICE_ID_16550 1 > #define DEVICE_ID_ATMEL_SERIAL 2 > #define DEVICE_ID_ARM_LTD_SERIAL 3 > #define DEVICE_ID_CIRRUS_SERIAL 4 > #define DEVICE_ID_ATMEL_SSC 5 > #define DEVICE_ID_ATMEL_MCI 6 > #define DEVICE_ID_ATMEL_MCI2 7 > #define DEVICE_ID_ATMEL_ETHER 8 /* AT91RM9200 ethernet device */ > #define DEVICE_ID_ATMEL_ETHER2 9 /* AT91SAMxxx ethernet device */ > #define DEVICE_ID_ATMEL_SPI 10 > #define DEVICE_ID_ATMEL_TWI 11 > #define DEVICE_ID_ATMEL_RTC 12 > #define DEVICE_ID_ATMEL_PMC 13 > #define DEVICE_ID_ATMEL_ST 14 > #define DEVICE_ID_ATMEL_SERIAL_DBGU 15 /* Special, limited func > serial port */ > #define DEVICE_ID_ATMEL_UDP 16 > #define DEVICE_ID_ATMEL_PIO 16 > #define DEVICE_ID_CIRRUS_ETHER 18 > #define DEVICE_ID_CIRRUS_GPIO 19 > #define DEVICE_ID_XSCALE_MMC1 20 > #define DEVICE_ID_XSCALE_MMC2 21 > #define DEVICE_ID_XSCALE_MMC3 22 > #define DEVICE_ID_XSCALE_GPIO 23 > ... > > Am I understanding your proposal correctly? I can't see how else it > would work if this isn't the case, but if you have some clever scheme, > I'd be interested. No, this is more or less the gist of it. The type and id can be chosen in any way we like, including using the type as the id. The abstract bus driver does not need to know anything other than maybe translate a table into a newbus hierarchy and using the type/id combination to flag a child. Any newbus node that implements the ocpbus handshake is then automatically an ocpbus driver even though there's no mention of how it obtains the device information. As I said before: it's about avoiding the flurry of bus attachments, not about dictating how devices are enumerated. -- Marcel Moolenaar marcelm@juniper.net