From owner-freebsd-embedded@FreeBSD.ORG Sat Dec 29 01:50:16 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 EE68216A41A for ; Sat, 29 Dec 2007 01:50:16 +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 BE4FD13C4E9 for ; Sat, 29 Dec 2007 01:50:16 +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 17:50:09 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Dec 2007 17:47:01 -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 lBT1lC937266; Fri, 28 Dec 2007 17:47:12 -0800 (PST) (envelope-from marcelm@juniper.net) Message-Id: <6712844B-1863-4316-9BEE-E43E9BE232A8@juniper.net> From: Marcel Moolenaar To: "M. Warner Losh" In-Reply-To: <20071228.181939.-957829045.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 17:47:11 -0800 References: <4FA37AAF-8113-44DE-8FF9-5BB203188912@juniper.net> <20071228.163257.756911359.imp@bsdimp.com> <1B0F37B8-D492-4E15-82A8-704243E67E90@juniper.net> <20071228.181939.-957829045.imp@bsdimp.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 29 Dec 2007 01:47:01.0421 (UTC) FILETIME=[B4B095D0:01C849BC] 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: Sat, 29 Dec 2007 01:50:17 -0000 On Dec 28, 2007, at 5:19 PM, M. Warner Losh wrote: > : > Right now, all of these situations are dealt with by having a > bit of > : > code in a specific attachment cope. > : > : Right. All these bits of code can be triggered by > : information that comes from the bus. The uart(4) register > : shift comes from the bus (when uart(4) is a child of > : puc(4) or scc(4)) or is hardcoded (sparc64 ebus or sbus). > : > : It's easy to expose that information through a single > : ocpbus handshake that includes information about the > : clock and register shift for UARTs. > > How does ocpbus know about these things if it is generic? The ocpbus handshake is generic, the code that implements the handshake is specific. What I'm trying to achieve is not a single generic bus implementation. I'm trying to achieve a single generic handshake that platform specific bus drivers can implement so that we can re-use bus attachments. Thus, if uart(4) has an ocpbus bus attachment, it will expect a couple of IVARs. Any SoC that has a ns8250 can implementation those IVARs and have uart(4) attach with the ocpbus attachment. No need to also create a new bus attachment. Look at puc(4) and scc(4). Both expose an abstract bus and both have separate bus attachments for uart(4). It would be nice if we can stop the growth of bus attachments (especially for uart(4)). > : > I agree that's a noble goal, and maybe we can avoid it in many > cases, > : > but not in all cases. I just don't think having a large > enumeration > : > table to make this work is worth the effort of maintaining it. > When > : > you go to add a new ocpbus driver, you need to touch additional > places > : > than the direct method. > : > : How so? > > If you had a string that's the device to attach in the table, then you > wouldn't have to edit ocpbusvar.h, or whatever file defined the > enumeration, every time you added new devices that could attach to > ocpbus. True. There will be a single header that defines the magic constants and that header needs updating whenever we need to add a magic constant. > This side of things isn't too horrible, but the sending side is what I > worry about. How does the ocpbus know about these details and remain > generic? The bus implementation is not necessarily generic. When we have a new and improved way to describe the hardware, we may be able to come up with a generic ocpbus that parses the description and constructs the newbus tree. Without that, I presume that we have separate drivers for the busses that implement the generic handshake. -- Marcel Moolenaar marcelm@juniper.net