Thread (32 messages) 32 messages, 5 authors, 2011-11-23

[PATCH 01/10] arm/tegra: initial device tree for tegra30

From: Olof Johansson <hidden>
Date: 2011-11-18 21:48:09
Also in: linux-devicetree, linux-tegra, lkml

On Fri, Nov 18, 2011 at 11:30 AM, Rob Herring [off-list ref] wrote:
On 11/18/2011 12:49 PM, Olof Johansson wrote:
quoted
On Thu, Nov 17, 2011 at 11:39:14AM -0800, Stephen Warren wrote:
quoted
Peter De Schrijver wrote at Thursday, November 17, 2011 9:19 AM:
quoted
This patch adds the initial device tree for tegra30
quoted
diff --git a/Documentation/devicetree/bindings/arm/tegra.txt
...
quoted
+* harmony: tegra20 based development board
+Required root node properties:
+ - compatible = "nvidia,harmony", "nvidia,tegra20";
+
+* seaboard: tegra20 based clamshell reference design
+Required root node properties:
+ - compatible = "nvidia,seaboard", "nvidia,tegra20";
Do we really want to list all the board names here? In the future, there
could be tens or hundreds. I would argue that we should just document
nvidia,tegra20 and nvidia,tegra30.
Agreed.
It's not really any different than mach-types which does have every
board in it.
Yeah, and the whole idea of having device trees is to not have to do
code changes when introducing a new derivative board. So enumerating
all supported boards in the documentation means we're back to an
equivalence to having to add machine ids.
I think if a board requires a new dts, then it needs a unique name.
Sure, that's fine. But the idea is to be able to do it without
changing code for many cases, just provide a new dts that configures
the devices in question.
quoted
quoted
At a later point, we should fix board-dt.c to solely look for those
compatible values, although this will have to wait until the pinmux DT
bindings are present. Then, the kernel won't care about the board names.
Exactly.
That is perfectly acceptable, but you should still have the option to do
something specific for any given board.
Of course. That's not what we're objecting to here.


-Olof
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help