From owner-freebsd-embedded@FreeBSD.ORG Sat Dec 29 02:21:58 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 BCD8E16A417 for ; Sat, 29 Dec 2007 02:21:58 +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 713AB13C442 for ; Sat, 29 Dec 2007 02:21:58 +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 lBT2GNtr080010; Fri, 28 Dec 2007 19:16:24 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 28 Dec 2007 19:21:15 -0700 (MST) Message-Id: <20071228.192115.783710089.imp@bsdimp.com> To: marcelm@juniper.net From: "M. Warner Losh" In-Reply-To: <6712844B-1863-4316-9BEE-E43E9BE232A8@juniper.net> References: <1B0F37B8-D492-4E15-82A8-704243E67E90@juniper.net> <20071228.181939.-957829045.imp@bsdimp.com> <6712844B-1863-4316-9BEE-E43E9BE232A8@juniper.net> 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: Sat, 29 Dec 2007 02:21:58 -0000 In message: <6712844B-1863-4316-9BEE-E43E9BE232A8@juniper.net> Marcel Moolenaar writes: : : 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. That's a good goal... But I see difficulties in realizing it based on other design choices... : 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'm not sure how much you can do about that. You'll run into problems doing that. If you have a 'generic' attachment for uart, then you'll have code that looks like: switch (class) { case NS8250: sc->sc_class = &uart_ns8250_class; break; case AT91: sc->sc_class = &at91_usart_class; break; case CIRRUS: sc->sc_class = &uart_cirrus_class; break; case ARMIP: sc->sc_class = &uart_armip_class; break; ... } which drags in a bunch of unwanted code. The ARMIP only exists on one of our mips ports, while the cirrus and at91 ports typically don't have ns8250. So short of having a bunch of ifdefs, I'm not sure how you'd solve this problem. : > : > 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. Right. For me, this is a needless file that will be a cause of integration problems. This is my biggest complaint: we're reintroducing a file that lists all possible devices. : > 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. Right. So we're back to the bus subclassing to make everything work... Which is fine... Warner