On 04/03/2014 09:14 AM, Antoine Ténart wrote:
On 03/04/2014 10:54, Antoine Ténart wrote:
On 03/04/2014 10:22, Jisheng Zhang wrote:
On Thu, 3 Apr 2014 01:08:15 -0700
Antoine Ténart <antoine.tenart@xxxxxxxxxxxxxxxxxx> wrote:
Signed-off-by: Antoine Ténart <antoine.tenart@xxxxxxxxxxxxxxxxxx>
---
Documentation/devicetree/bindings/arm/cpus.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
b/Documentation/devicetree/bindings/arm/cpus.txt index
333f4aea3029..a9e42a2dbc99 100644 ---
a/Documentation/devicetree/bindings/arm/cpus.txt +++
b/Documentation/devicetree/bindings/arm/cpus.txt @@ -185,6 +185,8 @@
nodes
to be present and contain the properties described below.
"qcom,gcc-msm8660"
"qcom,kpss-acc-v1"
"qcom,kpss-acc-v2"
+ "marvell,88de31-smp" - cpu-core handling for
why not "marvell,berlin-smp"?
We have SMP on the BG2 and the BG2Q currently. Future boards may not be
compatible with this method (BG3 ?), I think "marvell,berlin-smp" is too
generic.
We could use "marvell,88de31xx-smp" as Alexandre suggested.
"marvell,88de31xx-smp" is not a good choice too, since futur SoC may
match the "xx" and not use this method. A better way should be to use
the first SoC implementing the feature, so "marvell,88de3100".
Never introduce the SoC numbers, we have chosen to stick with
berlin2{,cd,q} so use that.
Given the comment from Mark Rutland and Russell King here[1], I'd rather
concentrate on a proper SMP implementation. Unfortunately, I haven't
found a good documentation about the requirements nor call sequence -
but I haven't looked hard.
Having said that, can we postpone the DT enable method patches until
we agreed on a better SMP implementation?
Sebastian
[1] http://www.spinics.net/lists/arm-kernel/msg318585.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
