Date: Fri, 28 Dec 2007 17:47:11 -0800 From: Marcel Moolenaar <marcelm@juniper.net> To: "M. Warner Losh" <imp@bsdimp.com> Cc: embedded@freebsd.org Subject: Re: ocpbus(4) Message-ID: <6712844B-1863-4316-9BEE-E43E9BE232A8@juniper.net> In-Reply-To: <20071228.181939.-957829045.imp@bsdimp.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6712844B-1863-4316-9BEE-E43E9BE232A8>