[permalink] [raw]

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
<[email protected]> 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<[email protected]>
>> >>---
>> >> ?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.

2011-02-25 21:56:13

by Benjamin Herrenschmidt

[permalink] [raw]

Subject: 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...
> >> 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.