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