Subject: Re: [PATCH 15/16] Add device tree for Ebony

From: David Gibson <[email-masked]>
Date: Thu, 15 Feb 2007 10:27:01 +1100

On Wed, Feb 14, 2007 at 01:08:01PM -0700, Yoder Stuart-B08248 wrote:
>  
> > >> Hmm.  There are two "soc" devices here, one nested under the
> > >> first??
> > >>
> > >> I'm assuming these are two levels of busses the opb bus is attached
> > >> to the plb bus.  Is the "soc" device_type the right way to
> > >> do this?
> > >
> > > Right, OPB hangs off of PLB in this case.  I dunno if "soc" is the 
> > > right
> > > device type for them though.
> > 
> > I would use device_type "plb" (or "plb4") and "opb" I think.
> > Similar to how PCI and ISA etc. busses are represented.
> 
> I think we should avoid making up new device_types unlesss it
> really is necessary.
> 
> Is it really necessary to distinguish between devices on
> the PLB or OPB?

Well.. maybe.  There are registers (DCR, not MMIO) in the PLB<->OPB
bridge.  I don't think the actual mapping can be changed, but some
error reporting and arbitration are controller there.  I think it's
better to represent the two busses, in case the distinction becomes
important at some point.

> As I undestand it the "soc" device type is a logical container
> for a group of devices in an SOC, not necessarily a group
> of devices on the same bus.  Could we simply list all those
> devices under an "soc" node at the same level.
> 
> If for some reason the bus hierarchy distinction _is_ required,
> my suggestion would be to create new generic device type for
> representing an internal bus.   The "device_type" is supposed
> to be somewhat general-- "network", "serial", etc.
> 
> We could create something like "soc-bus" or "internal-bus" with
> a compatible field that identifies the type of bus.
> 
> The general philosophy is a general device_type prooperty and
> a specific compatible property.

Yes, that's partly why I'm using "soc" for now.  I've thought that a
new general device_type might be a good idea though.  What's a "soc"
and what's an "internal" bus I think are not necessarily clear,
though.  I would suggest a type for any memory mapped,
non-hotpluggable, non-probeable bus.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson