From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 20:56:31 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 AF88B16A419 for ; Fri, 28 Dec 2007 20:56:31 +0000 (UTC) (envelope-from olivier@gautherot.net) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by mx1.freebsd.org (Postfix) with ESMTP id 76F3413C469 for ; Fri, 28 Dec 2007 20:56:31 +0000 (UTC) (envelope-from olivier@gautherot.net) Received: by py-out-1112.google.com with SMTP id u77so6754605pyb.3 for ; Fri, 28 Dec 2007 12:56:30 -0800 (PST) Received: by 10.142.105.14 with SMTP id d14mr3250976wfc.67.1198873917598; Fri, 28 Dec 2007 12:31:57 -0800 (PST) Received: by 10.70.53.11 with HTTP; Fri, 28 Dec 2007 12:31:57 -0800 (PST) Message-ID: Date: Fri, 28 Dec 2007 17:31:57 -0300 From: "Olivier Gautherot" To: "M. Warner Losh" In-Reply-To: <20071228.130329.43010549.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071228.114559.-311937481.imp@bsdimp.com> <20071228.121213.-494094613.imp@bsdimp.com> <20071228.130329.43010549.imp@bsdimp.com> Cc: embedded@freebsd.org, marcelm@juniper.net 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 20:56:31 -0000 Hi there! On 12/28/07, 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). The busses on the SoC more strongly > resemble the latter than the former. The former busses already are > enumerated with hints, but the actual mechanism is just a few calls > that could be replaced with something better. Excuse my ignorance about obio, ocpbus and the like... If we envisage to use a PCI-like approach to initialise the on-chip drivers, couldn't we generate a table on a per CPUID basis? In PCI land, the device enumerates all the functions it supports and the kernel installs the approriate modules. In this case, we would have a table of devices indexed by the CPUID - for instance, the MPC5200 has 2 UARTs at addresses x and y, the MPC5512 has 3 UARTs at addresses x, y and z, etc. These tables would be used only during boot time and would only use up ROM space... When compiling the kernel, we would then enable only the tables that apply (ideally, just one - and make sure at run time that it is the correct one). It does not sound like rocket science to me so I guess it has been evaluated at some point? My cent worth... Cheers Olivier -- Olivier Gautherot olivier@gautherot.net Cel:+56 98 730 9361 www.gautherot.net http://www.linkedin.com/in/ogautherot