Re: [RFC PATCH 02/10] MIPS: Octeon: Add device tree source files.

On Fri, 2011-02-25 at 08:22 -0700, Grant Likely wrote:

Generally I've applied the argument that it's a good idea to populate
the /cpus node as an anchor for future things that might require it.
For example, a theoretical hypervisor which doesn't allow the guest
access to all the CPUs would use cpu nodes to tell the OS 'hands off'.
 Or possibly more likely, and AMP scenario where Linux would certainly
detect all the CPUs, but is supposed to leave some of them alone.  It
would also be an anchor for anything NUMA-like which is also
theoretical, but may become more likely in some of the larger ARM
designs that I've been hearing about.

It also allows to bring other informations in there such as clock
frequencies etc... In some kind, binding to a reset GPIO used to soft
reset secondaries (ie on Macs we have something like that)...

Given that we've been very explicit that the device tree is for
describing things that aren't probable, the argument that it is not
necessary to populate the cpus node probably holds some water.  If
there are no special considerations (ie. disabled CPUs or NUMA) and
nothing holds a phandle to a specific cpu node, then it is probably
okay to omit.  In that case the lack of /cpus node would mean simply,
"detect the cpus", and /cpus could be populated to override the
detected behaviour.

Well... I tend to recommend putting things that are soldered on the mobo
in the device-tree, simply because that allows to pass all sort of
additional informations that can be useful. For example, if you have a
PCI2PCI bridge on the mobo, it allows you to provide proper slot names
for the slots below it, or if devices have oddly routed interrupts (not
the standard INTA...D with swizzling), which happens on embedded a lot,
the device-tree can convey that more easily.

Other things like clock frequencies or in general clock relationships,
or even location codes, MAC addresses, etc... 

But you don't -have- to. It's just a recommendation.

Picking up on something David Daney said...

quoted

quoted

The number and type of CPUs can be (and is) probed.  There is an
existing mechanism for the bootloader to communicate which CPUs
should be used.

I do get a little nervous about this (the bootloader communication
bit).  For ARM, I had an argument with Nicolas Pitre about preserving
the existing ATAGs mechanism and adding DT on top vs. replacing ATAGs
entirely with DT.  I wanted to keep ATAGs, but Nicolas was concerned
about how to handle ambiguity about which data to use when the ATAGs
and DT disagree.  In hindsight Nicolas was 100% right and I'm glad he
pushed back.  The ARM DT support now detects if ATAGs or a .dtb were
passed at boot (one or the other), and it is *so* much cleaner.  All
configuration data lives in the same place and is manipulated in the
same way.  Plus it means that the dt usage model is the same for
multiple architectures, arm, powerpc and microblaze. 

I think doing a "blend" of existing bootloader channels + device-tree is
bad. The device-tree should convey all of the informations that were
previously passed using a different mechanism, or hell will freeze over
in the long run.

Cheers,
Ben.