ocpbus(4)

[M. Warner Losh]

In message: <6712844B-1863-4316-9BEE-E43E9BE232A8 at juniper.net>
            Marcel Moolenaar <marcelm at 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