Date: Fri, 28 Dec 2007 11:45:59 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: marcelm@juniper.net Cc: embedded@freebsd.org Subject: Re: ocpbus(4) Message-ID: <20071228.114559.-311937481.imp@bsdimp.com> In-Reply-To: <B56F8F3C-7872-47B9-8154-1C08F5BEEA3D@juniper.net> References: <B56F8F3C-7872-47B9-8154-1C08F5BEEA3D@juniper.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <B56F8F3C-7872-47B9-8154-1C08F5BEEA3D@juniper.net>
Marcel Moolenaar <marcelm@juniper.net> writes:
: All,
:
: As part of the PowerPC e500 port we created an ocpbus
: (On-Chip Peripheral bus), with devices likes uart(4).
: This, of course, is perfectly normal. In fact, it's so
: normal that I wondered why we don't have a single
: abstract bus already.
:
: What I'm thinking about is a handshake between bus
: driver and device drivers that makes it possible for
: us to create a single (abstract) bus attachment per
: driver, usable whenever that particular driver is
: used in an embedded environment.
:
: The main part of the handshake seems to be the means
: for a driver to probe/match the hardware. In our
: implementation of ocpbus(4), we use an IVAR for the
: device type, as in:
:
: parent = device_get_parent(dev);
: error = BUS_READ_IVAR(parent, dev, OCPBUS_IVAR_DEVTYPE,
: &devtype);
: if (error)
: return (error);
: if (devtype != OCPBUS_DEVTYPE_PCIB)
: return (ENXIO);
:
: Since we only have 1 PCI-host controller driver to
: worry about, this is perfectly fine. However, if we
: want to generalize, then we probably need to extend
: the handshake to support different classes. Take
: for example an USB host controller. With EHCI, there's
: always at least 1 companion host controller (either
: OHCI or UHCI). Thus, checking if OCPBUS_DEVTYPE equals
: OCPBUS_DEVTYPE_USB (or something along those lines) is
: not enough. We need to know if it's an EHCI, OHCI or
: UHCI host controller.
This is why I don't think it will work. The child device shouldn't be
checking to see if it is the right type or not.
: Q1: Do people think it's worthwhile to pursue a generic
: ocpbus(4) definition?
Generally, yes. In fact, I've done a bunch of things with what I've
called obio (On Board I/O) that does similar things, but relies
entirely on hints to do the job. Since that's how we do things
elsewhere, this seems like a reasonable approach. If we move to doing
things differently, then we can talk about that.
I implemented obio as a set of routines rather than as a bus itself,
since doing the bus generically is going to be nearly impossible.
There's too many fussy bits of logic for this SoC or that SoC that
need to be in code.
: Q2: Is there a better handshake possible than IVARs?
Have the bus say "I have this or that on it" rather than having the
drivers themselves try to match. That way lies madness, I think,
since you'll soon wind up with lots of platform specific code
infecting the generic device drivers.
: Q3: For probing, would DEVTYPE and DEVCLASS suffice or
: do we need something more or something else?
Is this supposed to be a 'generic' replacement for the product/vendor
stuff ala pci or something else? I'm not sure that we can uniquely do
this in a generic enough way.
: Q4: What is minimally needed if we want to re-implement
: existing embedded busses using ocpbus(4)?
The atmel at91 code is moving in this direction in p4, but uses the
obio routines I wrote.
: Q5: Thoughts?
: Q6: Suggestions?
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071228.114559.-311937481.imp>