On Nov 5, 2013, at 11:35 AM, Stephen Boyd wrote:

On 11/05/13 09:12, Kumar Gala wrote:

quoted

On Nov 4, 2013, at 11:36 AM, Stephen Boyd wrote:

quoted

On 11/01, Rob Herring wrote:

quoted

On Fri, Nov 1, 2013 at 5:08 PM, Stephen Boyd [off-list ref] wrote:

quoted

From: Rohit Vaswani <redacted>

Scorpion and Krait are Qualcomm cpus. These cpus don't use the
spin-table enable-method. Instead they rely on mmio register
accesses to enable power and clocks to bring CPUs out of reset.

Cc: <redacted>
Signed-off-by: Rohit Vaswani <redacted>
[sboyd: Split off into separate patch, renamed method to
qcom,mmio]
Signed-off-by: Stephen Boyd <redacted>
---

This slightly conflicts with my krait EDAC series.

Documentation/devicetree/bindings/arm/cpus.txt | 3 +++
1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
index 37258f9..e2969fa2 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt

@@ -44,6 +44,8 @@ For the ARM architecture every CPU node must contain the following properties:
              "marvell,mohawk"
              "marvell,xsc3"
              "marvell,xscale"
+               "qcom,scorpion"
+               "qcom,krait"

And the following optional properties:

@@ -52,6 +54,7 @@ And the following optional properties:
               different types of cpus.
               This should be one of:
               "spin-table"
+                "qcom,mmio"

Not exactly specific. How would you handle variations in the enable
method? The mmio method to enable is tied to the core type or SOC
type?

Variations in the enable method are handled by searching for
another node with different compatible strings. Later on in this
series you'll see that we search for gcc-8660, kpss-acc-v1, or
kpps-acc-v2. Once we find one of these nodes we perform the
correct cold boot routine.

I'm actually considering renaming this to "qcom,cold-boot". We
could further extend the enable-metho property to allow
"qcom,warm-boot" and then for cases like kexec we could make the
enable method be warm boot and our smp code could be smart enough
to know to skip the whole cold boot sequence.

I think this should be more specific than just 'qcom,mmio' or 'qcom,warm-boot'.  It should be 'qcom,kpss-acc-v1' or 'qcom-gcc-8660'.

Do you have any reasons why? I don't see why we need to keep adding more
and more enable-methods every time the subsystem surrounding the CPU
changes. The method is the same, write some registers to power up the
CPU for the first time (cold boot) or ping the CPU to wake it up
(warmboot). The only difference is where those registers live and a
slight variation in the sequence that we perform.

By that argument every device could just be compatible with 'mmio' and be done with it ;)

As the registers you write vary, the compatible should vary.

- k
-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation