Message-ID: <AANLkTi=Oh0iu-d4n3rMLvXFH-DjS1mT3GgpoJyywjM=5@mail.gmail.com>
Date:	Fri, 25 Feb 2011 08:22:21 -0700
From:	Grant Likely <grant.likely@...retlab.ca>
To:	David Gibson <david@...son.dropbear.id.au>,
	David Daney <ddaney@...iumnetworks.com>,
	linux-mips@...ux-mips.org, ralf@...ux-mips.org,
	devicetree-discuss@...ts.ozlabs.org, grant.likely@...retlab.ca,
	linux-kernel@...r.kernel.org,
	Rob Herring <rob.herring@...xeda.com>,
	Kevin Hilman <khilman@...prootsystems.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Subject: Re: [RFC PATCH 02/10] MIPS: Octeon: Add device tree source files.

[cc'ing Ben Herrenschmidt, Rob Herring and Kevin Hilman]

On Thu, Feb 24, 2011 at 4:19 PM, David Gibson
<david@...son.dropbear.id.au> wrote:
> On Wed, Feb 23, 2011 at 08:59:29AM -0800, David Daney wrote:
>> On 02/22/2011 04:07 PM, David Gibson wrote:
>> >On Tue, Feb 22, 2011 at 12:57:46PM -0800, David Daney wrote:
>> >>Signed-off-by: David Daney<ddaney@...iumnetworks.com>
>> >>---
>> >>  arch/mips/cavium-octeon/.gitignore      |    2 +
>> >>  arch/mips/cavium-octeon/Makefile        |   13 ++
>> >>  arch/mips/cavium-octeon/octeon_3xxx.dts |  314 +++++++++++++++++++++++++++++++
>> >>  arch/mips/cavium-octeon/octeon_68xx.dts |   99 ++++++++++
>> >>  4 files changed, 428 insertions(+), 0 deletions(-)
>> >>  create mode 100644 arch/mips/cavium-octeon/.gitignore
>> >>  create mode 100644 arch/mips/cavium-octeon/octeon_3xxx.dts
>> >>  create mode 100644 arch/mips/cavium-octeon/octeon_68xx.dts
>> >>
>> [...]
>>
>> >>+    };
>> >>+  };
>> >
>> >Uh.. where are the CPUs?
>> >
>>
>> 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.
>
> Hrm, ok.
>
> Grant,
>
> We've seen this now on both MIPS and ARM - dts files with no cpus, on
> the grounds that those can be runtime probed.  I guess it makes sense,
> although a dts without cpus looks very, very odd to me.  What are your
> thoughts on this?

Yeah, it looks odd, but you and I have been looking at device trees,
and .dts file specifically for a lot longer and so are probably a
little set in our ways.

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.

For the same reason I've been recommending to SoC port authors to
populate the .dts will all the devices in the SoC, even for devices
that don't need any configuration data.  I2C and SPI busses are no
brainers because they need child nodes to describe the contents of the
bus, but there is no obvious configuration data for, say, an on chip
timer.  However, describing it in the tree still provides an anchor
for stuff like disabling devices that the OS should ignore for other
reasons, or for allowing other devices to hold a phandle reference to
it.

There is also the convenience factor of not needing to maintain a
table of platform_devices for each SoC if they are described in the
dt, but in the arm world the kernel still needs to support non-dt
board ports so it will have those tables regardless (unless an SoC
converts wholesale to dt).  It is valuable to share init code for both
dt and non-dt use cases.

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.

Picking up on something David Daney said...
>> 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.

g.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists