[PATCH 15/16] Add device tree for Ebony

[Yoder Stuart-B08248]

> -----Original Message-----
> From: Segher Boessenkool [mailto:segher at kernel.crashing.org] 
> Sent: Wednesday, February 14, 2007 3:12 PM
[snip]
> > 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.
> 
> A "soc" node is meant to contain SoC specific stuff like
> clock registers or whatnot.  It typically wouldn't have
> child nodes.

That's not what booting_without_of.txt says.  It says:

    The SOC node may contain child nodes for each SOC
    device that the  platform uses.

All the dts files in arch/powerpc/boot/dts I've looked at have
an soc node with a whole bunch of devices under it.

The current practice seems to be that an "soc" node contains
all the on chip devices (regardless of the physical bus internal
to the soc).

> > If for some reason the bus hierarchy distinction _is_ required,
> 
> It doesn't matter if you feel it is required.  You could in
> principal list all devices as direct children of the root
> node, if you take your argument to the extreme.  The device
> tree is meant to reflect the physical hierarchy of the
> devices in the system -- so it should show the PLB etc.
> busses.  Maybe some day in the future the kernel can actually
> make good use of the extra knowledge -- reconfigure something
> about the PLB bus for example, who knows.  Also remember that
> the device tree is *not* just for Linux, any argument that
> says "Linux doesn't need this" is irrelevant.  And, again,
> maybe Linux _could_ make good use of it.
> 
> > 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.
> 
> The device_type represents the programming model of the
> device (programming model for OF).

The device_type is typically things like "network" and "serial"
which don't specify the programming model.   The compatible 
property is used in driver selection. 

> Each type of bus has
> its own programming model.  Your suggestion makes sense
> for bus bridges that are 100% transparent -- same address
> domain on both sides, completely identical ordering rules,
> no configuration whatsoever.  I've never seen such a bus.

If the busses have different address domains and specific 
configuration then I agree, they need their own unique device_type.

Do the ipb and opb busses have their own device driver similar to
PCI?

Stuart