[PATCH 00/11] CPU enable method based SMP/hotplug + MSM conversion

[PATCH 00/11] CPU enable method based SMP/hotplug + MSM conversion

[Stephen Boyd]

This is a rework of patches sent a few months back by Rohit[1].
The goal of these patches is to add support for SMP and (basic)
hotplug on MSM based SoCs. To get there, we add support for a
generic way to add SMP/hotplug support code in the kernel. To
show how it's used, we convert the MSM8660 SMP support code over
to the new method. After that we add support for the rest of the
upstream MSM SoCs (note these patches are piled high on top of
Rohit's patches to add 8074 support to MSM[2] and my follow ups[3,4],
but this should only matter to the MSM maintainers).

This is one of the last items of code that still requires us to have
a mach directory and a machine descriptor. We should be able to move
the hotplug/smp code out of mach directories if this approach is
accepted.

[1] https://lkml.org/lkml/2013/8/1/770
[2] https://lkml.org/lkml/2013/10/17/520
[3] https://lkml.org/lkml/2013/10/18/406
[4] http://lkml.org/lkml/2013/10/28/501
 
Rohit Vaswani (7):
  devicetree: bindings: Document cpu enable-method for ARM CPUs
  devicetree: bindings: Document Qualcomm cpus and enable-method
  ARM: msm: Remove pen_release usage
  ARM: msm: Re-organize platsmp to make it extensible
  ARM: msm: Add SMP support for KPSSv1
  ARM: msm: Add SMP support for KPSSv2
  ARM: dts: msm: Add nodes necessary for SMP boot

Stephen Boyd (4):
  devicetree: bindings: Document qcom,kpss-acc
  devicetree: bindings: Document qcom,saw2 node
  ARM: Introduce CPU_METHOD_OF_DECLARE() for cpu hotplug/smp
  ARM: msm: Remove nr_cpus detection logic

 Documentation/devicetree/bindings/arm/cpus.txt     |  11 +
 .../devicetree/bindings/arm/msm/qcom,kpss-acc.txt  |  21 ++
 .../devicetree/bindings/arm/msm/qcom,saw2.txt      |  23 ++
 arch/arm/boot/dts/qcom-msm8660-surf.dts            |  24 ++
 arch/arm/boot/dts/qcom-msm8960-cdp.dts             |  32 +++
 arch/arm/boot/dts/qcom-msm8974.dtsi                |  49 ++++
 arch/arm/include/asm/smp.h                         |   9 +
 arch/arm/kernel/devtree.c                          |  38 +++
 arch/arm/mach-msm/Makefile                         |   2 +-
 arch/arm/mach-msm/board-dt.c                       |  14 -
 arch/arm/mach-msm/common.h                         |   1 -
 arch/arm/mach-msm/headsmp.S                        |  39 ---
 arch/arm/mach-msm/hotplug.c                        |  31 +--
 arch/arm/mach-msm/platsmp.c                        | 301 +++++++++++++++------
 arch/arm/mach-msm/scm-boot.h                       |   8 +-
 include/asm-generic/vmlinux.lds.h                  |  10 +
 16 files changed, 448 insertions(+), 165 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
 create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
 delete mode 100644 arch/arm/mach-msm/headsmp.S

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

[PATCH 01/11] devicetree: bindings: Document cpu enable-method for ARM CPUs

[Stephen Boyd]

From: Rohit Vaswani <rvaswani@codeaurora.org>

According to the ePAPR CPUs should have an enable method. On ARM
the enable-method property has not been used so far, so document
this property as an optional property and add the spin-table
method as one value

Cc: <devicetree@vger.kernel.org>
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
[sboyd: Split off into separate patch]
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
 Documentation/devicetree/bindings/arm/cpus.txt | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
index f32494d..37258f9 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -45,6 +45,14 @@ For the ARM architecture every CPU node must contain the following properties:
 		"marvell,xsc3"
 		"marvell,xscale"
 
+And the following optional properties:
+
+- enable-method: Specifies the method used to enable or take the secondary cores
+		 out of reset. This allows different reset sequence for
+		 different types of cpus.
+		 This should be one of:
+		 "spin-table"
+
 Example:
 
 	cpus {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 01/11] devicetree: bindings: Document cpu enable-method for ARM CPUs

[Rob Herring]

On Fri, Nov 1, 2013 at 5:08 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> From: Rohit Vaswani <rvaswani@codeaurora.org>
>
> According to the ePAPR CPUs should have an enable method. On ARM
> the enable-method property has not been used so far, so document
> this property as an optional property and add the spin-table
> method as one value
>
> Cc: <devicetree@vger.kernel.org>
> Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
> [sboyd: Split off into separate patch]
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>

Acked-by: Rob Herring <rob.herring@calxeda.com>

[PATCH 01/11] devicetree: bindings: Document cpu enable-method for ARM CPUs

[Tomasz Figa]

On Friday 01 of November 2013 15:08:49 Stephen Boyd wrote:
> From: Rohit Vaswani <rvaswani@codeaurora.org>
> 
> According to the ePAPR CPUs should have an enable method. On ARM
> the enable-method property has not been used so far, so document
> this property as an optional property and add the spin-table
> method as one value
> 
> Cc: <devicetree@vger.kernel.org>
> Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
> [sboyd: Split off into separate patch]
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
>  Documentation/devicetree/bindings/arm/cpus.txt | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
> b/Documentation/devicetree/bindings/arm/cpus.txt index f32494d..37258f9
> 100644
> --- a/Documentation/devicetree/bindings/arm/cpus.txt
> +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> @@ -45,6 +45,14 @@ For the ARM architecture every CPU node must contain
> the following properties: "marvell,xsc3"
>  		"marvell,xscale"
> 
> +And the following optional properties:
> +
> +- enable-method: Specifies the method used to enable or take the
> secondary cores +		 out of reset. This allows different reset 
sequence
> for
> +		 different types of cpus.
> +		 This should be one of:
> +		 "spin-table"

What about saying a word or two (other than property value) about each 
method?

Best regards,
Tomasz

[PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method

[Stephen Boyd]

From: Rohit Vaswani <rvaswani@codeaurora.org>

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: <devicetree@vger.kernel.org>
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
[sboyd: Split off into separate patch, renamed method to
qcom,mmio]
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---

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"
 
 Example:
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method

[Rob Herring]

On Fri, Nov 1, 2013 at 5:08 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> From: Rohit Vaswani <rvaswani@codeaurora.org>
>
> 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: <devicetree@vger.kernel.org>
> Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
> [sboyd: Split off into separate patch, renamed method to
> qcom,mmio]
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
>
> 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?

Rob

[PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method

[Stephen Boyd]

On 11/01, Rob Herring wrote:
> On Fri, Nov 1, 2013 at 5:08 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> > From: Rohit Vaswani <rvaswani@codeaurora.org>
> >
> > 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: <devicetree@vger.kernel.org>
> > Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
> > [sboyd: Split off into separate patch, renamed method to
> > qcom,mmio]
> > Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> > ---
> >
> > 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.

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

[PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method

[Kumar Gala]

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

> On 11/01, Rob Herring wrote:
>> On Fri, Nov 1, 2013 at 5:08 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
>>> From: Rohit Vaswani <rvaswani@codeaurora.org>
>>> 
>>> 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: <devicetree@vger.kernel.org>
>>> Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
>>> [sboyd: Split off into separate patch, renamed method to
>>> qcom,mmio]
>>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>>> ---
>>> 
>>> 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'.

- k

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

[PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method

[Stephen Boyd]

On 11/05/13 09:12, Kumar Gala wrote:
> On Nov 4, 2013, at 11:36 AM, Stephen Boyd wrote:
>
>> On 11/01, Rob Herring wrote:
>>> On Fri, Nov 1, 2013 at 5:08 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
>>>> From: Rohit Vaswani <rvaswani@codeaurora.org>
>>>>
>>>> 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: <devicetree@vger.kernel.org>
>>>> Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
>>>> [sboyd: Split off into separate patch, renamed method to
>>>> qcom,mmio]
>>>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>>>> ---
>>>>
>>>> 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.

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

[PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method

[Kumar Gala]

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

> On 11/05/13 09:12, Kumar Gala wrote:
>> On Nov 4, 2013, at 11:36 AM, Stephen Boyd wrote:
>> 
>>> On 11/01, Rob Herring wrote:
>>>> On Fri, Nov 1, 2013 at 5:08 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
>>>>> From: Rohit Vaswani <rvaswani@codeaurora.org>
>>>>> 
>>>>> 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: <devicetree@vger.kernel.org>
>>>>> Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
>>>>> [sboyd: Split off into separate patch, renamed method to
>>>>> qcom,mmio]
>>>>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>>>>> ---
>>>>> 
>>>>> 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

[PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method

[Stephen Boyd]

On 11/05/13 09:43, Kumar Gala wrote:
> On Nov 5, 2013, at 11:35 AM, Stephen Boyd wrote:
>
>> On 11/05/13 09:12, Kumar Gala wrote:
>>> 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.

The compatible does vary. The enable-method is not a compatible property.

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

[PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method

[Kumar Gala]

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

> On 11/05/13 09:43, Kumar Gala wrote:
>> On Nov 5, 2013, at 11:35 AM, Stephen Boyd wrote:
>> 
>>> On 11/05/13 09:12, Kumar Gala wrote:
>>>> 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.
> 
> The compatible does vary. The enable-method is not a compatible property.
> 
> -- 

I've always felt that the enable-method is equivalent of a compatible property.

- k

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

[PATCH 03/11] devicetree: bindings: Document qcom,kpss-acc

[Stephen Boyd]

The kpss acc binding describes the clock, reset, and power domain
controller for a Krait CPU.

Cc: <devicetree@vger.kernel.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
 .../devicetree/bindings/arm/msm/qcom,kpss-acc.txt   | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt

diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
new file mode 100644
index 0000000..ed4a9c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
@@ -0,0 +1,21 @@
+* Krait Processor Sub-system (KPSS) Application Clock Controller (ACC)
+
+The KPSS ACC provides clock, power domain, and reset control to a Krait CPU.
+There is one ACC register region per CPU within the KPSS remaped region as
+well as an alias register region that remaps accesses to the ACC associated
+with the CPU accessing the region.
+
+Required Properties:
+
+- compatible : Shall contain "qcom,kpss-acc-v1" or "qcom,kpss-acc-v2".
+- reg: Specifies the base address and size of the banked register region.
+- cpu-offset : per-cpu offset used when the device is accessed without the
+		CPU remapping facilities.
+		The offset is cpu-offset + (0x10000 * cpu-nr).
+
+Example:
+
+	clock-controller at 2008000 {
+		compatible = "qcom,kpss-acc-v2";
+		reg = <0x02008000 0x1000>;
+	};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 03/11] devicetree: bindings: Document qcom,kpss-acc

[Kumar Gala]

On Nov 1, 2013, at 5:08 PM, Stephen Boyd wrote:

> The kpss acc binding describes the clock, reset, and power domain
> controller for a Krait CPU.
> 
> Cc: <devicetree@vger.kernel.org>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> .../devicetree/bindings/arm/msm/qcom,kpss-acc.txt   | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
> new file mode 100644
> index 0000000..ed4a9c8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
> @@ -0,0 +1,21 @@
> +* Krait Processor Sub-system (KPSS) Application Clock Controller (ACC)
> +
> +The KPSS ACC provides clock, power domain, and reset control to a Krait CPU.
> +There is one ACC register region per CPU within the KPSS remaped region as
> +well as an alias register region that remaps accesses to the ACC associated
> +with the CPU accessing the region.
> +
> +Required Properties:
> +
> +- compatible : Shall contain "qcom,kpss-acc-v1" or "qcom,kpss-acc-v2".
> +- reg: Specifies the base address and size of the banked register region.
> +- cpu-offset : per-cpu offset used when the device is accessed without the
> +		CPU remapping facilities.
> +		The offset is cpu-offset + (0x10000 * cpu-nr).
> +
> +Example:
> +
> +	clock-controller at 2008000 {
> +		compatible = "qcom,kpss-acc-v2";
> +		reg = <0x02008000 0x1000>;
> +	};
> -- 

I don't get the cpu-offset business, shouldn't this just be:
	reg = <0x02008000 0x1000>, <0x02018000 0x1000>, <0x02028000 0x1000>, <0x02038000 0x1000>;

- k

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

[PATCH 03/11] devicetree: bindings: Document qcom,kpss-acc

[Stephen Boyd]

On 11/05/13 09:13, Kumar Gala wrote:
> On Nov 1, 2013, at 5:08 PM, Stephen Boyd wrote:
>
>> diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
>> new file mode 100644
>> index 0000000..ed4a9c8
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
>> @@ -0,0 +1,21 @@
>> +* Krait Processor Sub-system (KPSS) Application Clock Controller (ACC)
>> +
>> +The KPSS ACC provides clock, power domain, and reset control to a Krait CPU.
>> +There is one ACC register region per CPU within the KPSS remaped region as
>> +well as an alias register region that remaps accesses to the ACC associated
>> +with the CPU accessing the region.
>> +
>> +Required Properties:
>> +
>> +- compatible : Shall contain "qcom,kpss-acc-v1" or "qcom,kpss-acc-v2".
>> +- reg: Specifies the base address and size of the banked register region.
>> +- cpu-offset : per-cpu offset used when the device is accessed without the
>> +		CPU remapping facilities.
>> +		The offset is cpu-offset + (0x10000 * cpu-nr).
>> +
>> +Example:
>> +
>> +	clock-controller at 2008000 {
>> +		compatible = "qcom,kpss-acc-v2";
>> +		reg = <0x02008000 0x1000>;
>> +	};
>> -- 
> I don't get the cpu-offset business, shouldn't this just be:
> 	reg = <0x02008000 0x1000>, <0x02018000 0x1000>, <0x02028000 0x1000>, <0x02038000 0x1000>;
>

(Sorry I forgot to add the cpu-offset to the example.)

Your reg property is one way to do it. I was following the example of
the GIC binding which just specifies the alias region of the GIC's CPU
registers and then has a cpu-offset property to describe how to reach a
specific CPU's region.

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

[PATCH 03/11] devicetree: bindings: Document qcom,kpss-acc

[Kumar Gala]

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

> On 11/05/13 09:13, Kumar Gala wrote:
>> On Nov 1, 2013, at 5:08 PM, Stephen Boyd wrote:
>> 
>>> diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
>>> new file mode 100644
>>> index 0000000..ed4a9c8
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
>>> @@ -0,0 +1,21 @@
>>> +* Krait Processor Sub-system (KPSS) Application Clock Controller (ACC)
>>> +
>>> +The KPSS ACC provides clock, power domain, and reset control to a Krait CPU.
>>> +There is one ACC register region per CPU within the KPSS remaped region as
>>> +well as an alias register region that remaps accesses to the ACC associated
>>> +with the CPU accessing the region.
>>> +
>>> +Required Properties:
>>> +
>>> +- compatible : Shall contain "qcom,kpss-acc-v1" or "qcom,kpss-acc-v2".
>>> +- reg: Specifies the base address and size of the banked register region.
>>> +- cpu-offset : per-cpu offset used when the device is accessed without the
>>> +		CPU remapping facilities.
>>> +		The offset is cpu-offset + (0x10000 * cpu-nr).
>>> +
>>> +Example:
>>> +
>>> +	clock-controller at 2008000 {
>>> +		compatible = "qcom,kpss-acc-v2";
>>> +		reg = <0x02008000 0x1000>;
>>> +	};
>>> -- 
>> I don't get the cpu-offset business, shouldn't this just be:
>> 	reg = <0x02008000 0x1000>, <0x02018000 0x1000>, <0x02028000 0x1000>, <0x02038000 0x1000>;
>> 
> 
> (Sorry I forgot to add the cpu-offset to the example.)
> 
> Your reg property is one way to do it. I was following the example of
> the GIC binding which just specifies the alias region of the GIC's CPU
> registers and then has a cpu-offset property to describe how to reach a
> specific CPU's region.

Even in the gic's case I think we should have the reg property cover the memory map.

- k

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

[PATCH 03/11] devicetree: bindings: Document qcom,kpss-acc

[Tomasz Figa]

On Tuesday 05 of November 2013 11:51:07 Kumar Gala wrote:
> On Nov 5, 2013, at 11:44 AM, Stephen Boyd wrote:
> > On 11/05/13 09:13, Kumar Gala wrote:
> >> On Nov 1, 2013, at 5:08 PM, Stephen Boyd wrote:
> >>> diff --git
> >>> a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
> >>> b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt new
> >>> file mode 100644
> >>> index 0000000..ed4a9c8
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
> >>> @@ -0,0 +1,21 @@
> >>> +* Krait Processor Sub-system (KPSS) Application Clock Controller
> >>> (ACC)
> >>> +
> >>> +The KPSS ACC provides clock, power domain, and reset control to a
> >>> Krait CPU. +There is one ACC register region per CPU within the
> >>> KPSS remaped region as +well as an alias register region that
> >>> remaps accesses to the ACC associated +with the CPU accessing the
> >>> region.
> >>> +
> >>> +Required Properties:
> >>> +
> >>> +- compatible : Shall contain "qcom,kpss-acc-v1" or
> >>> "qcom,kpss-acc-v2".
> >>> +- reg: Specifies the base address and size of the banked register
> >>> region. +- cpu-offset : per-cpu offset used when the device is
> >>> accessed without the +		CPU remapping facilities.
> >>> +		The offset is cpu-offset + (0x10000 * cpu-nr).
> >>> +
> >>> +Example:
> >>> +
> >>> +	clock-controller at 2008000 {
> >>> +		compatible = "qcom,kpss-acc-v2";
> >>> +		reg = <0x02008000 0x1000>;
> >>> +	};
> >> 
> >> I don't get the cpu-offset business, shouldn't this just be:
> >> 	reg = <0x02008000 0x1000>, <0x02018000 0x1000>, <0x02028000 
0x1000>,
> >> 	<0x02038000 0x1000>;> 
> > (Sorry I forgot to add the cpu-offset to the example.)
> > 
> > Your reg property is one way to do it. I was following the example of
> > the GIC binding which just specifies the alias region of the GIC's CPU
> > registers and then has a cpu-offset property to describe how to reach
> > a
> > specific CPU's region.
> 
> Even in the gic's case I think we should have the reg property cover the
> memory map.

The GIC case was supposed to be a hack for Exynos SoCs that do not have 
banked per-CPU registers. Currently I consider it broken, because it does 
not scale for multi cluster configurations. I believe you should consider 
the same.

IMHO the way to provide per-CPU properties should involve CPU nodes to 
make sure that the same CPU ID namespace is always used.

Best regards,
Tomasz

[PATCH 03/11] devicetree: bindings: Document qcom,kpss-acc

[Kumar Gala]

On Nov 8, 2013, at 3:10 AM, Tomasz Figa wrote:

> On Tuesday 05 of November 2013 11:51:07 Kumar Gala wrote:
>> On Nov 5, 2013, at 11:44 AM, Stephen Boyd wrote:
>>> On 11/05/13 09:13, Kumar Gala wrote:
>>>> On Nov 1, 2013, at 5:08 PM, Stephen Boyd wrote:
>>>>> diff --git
>>>>> a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
>>>>> b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt new
>>>>> file mode 100644
>>>>> index 0000000..ed4a9c8
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
>>>>> @@ -0,0 +1,21 @@
>>>>> +* Krait Processor Sub-system (KPSS) Application Clock Controller
>>>>> (ACC)
>>>>> +
>>>>> +The KPSS ACC provides clock, power domain, and reset control to a
>>>>> Krait CPU. +There is one ACC register region per CPU within the
>>>>> KPSS remaped region as +well as an alias register region that
>>>>> remaps accesses to the ACC associated +with the CPU accessing the
>>>>> region.
>>>>> +
>>>>> +Required Properties:
>>>>> +
>>>>> +- compatible : Shall contain "qcom,kpss-acc-v1" or
>>>>> "qcom,kpss-acc-v2".
>>>>> +- reg: Specifies the base address and size of the banked register
>>>>> region. +- cpu-offset : per-cpu offset used when the device is
>>>>> accessed without the +		CPU remapping facilities.
>>>>> +		The offset is cpu-offset + (0x10000 * cpu-nr).
>>>>> +
>>>>> +Example:
>>>>> +
>>>>> +	clock-controller at 2008000 {
>>>>> +		compatible = "qcom,kpss-acc-v2";
>>>>> +		reg = <0x02008000 0x1000>;
>>>>> +	};
>>>> 
>>>> I don't get the cpu-offset business, shouldn't this just be:
>>>> 	reg = <0x02008000 0x1000>, <0x02018000 0x1000>, <0x02028000 
> 0x1000>,
>>>> 	<0x02038000 0x1000>;> 
>>> (Sorry I forgot to add the cpu-offset to the example.)
>>> 
>>> Your reg property is one way to do it. I was following the example of
>>> the GIC binding which just specifies the alias region of the GIC's CPU
>>> registers and then has a cpu-offset property to describe how to reach
>>> a
>>> specific CPU's region.
>> 
>> Even in the gic's case I think we should have the reg property cover the
>> memory map.
> 
> The GIC case was supposed to be a hack for Exynos SoCs that do not have 
> banked per-CPU registers. Currently I consider it broken, because it does 
> not scale for multi cluster configurations. I believe you should consider 
> the same.
> 
> IMHO the way to provide per-CPU properties should involve CPU nodes to 
> make sure that the same CPU ID namespace is always used.
> 
> Best regards,
> Tomasz


Yeah, Stephen and I talked off line about it and I think we'll end up with a bit of both.  Having the reg property describe both regions, as well as having some nodes via the CPU node to get to the proper "device" for that cpu.

- k

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

[PATCH 04/11] devicetree: bindings: Document qcom,saw2 node

[Stephen Boyd]

The saw2 binding describes the SPM/AVS wrapper hardware used to
control the regulator supplying voltage to the Krait CPUs.

Cc: <devicetree@vger.kernel.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---

When a SAW is for a CPU it is put behind the CPU alias region similar
to the ACC and timers. I haven't documented that here because I'm not using
it right now. I'm also thinking perhaps l2-saw2 is not important (technically
its the same hardware block as a CPU's saw). Instead I should point to this
node via the l2-cache node via some *-supply property. Thoughts?

 .../devicetree/bindings/arm/msm/qcom,saw2.txt      | 23 ++++++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt

diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt b/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
new file mode 100644
index 0000000..6360db2
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
@@ -0,0 +1,23 @@
+* SPM AVS Wrapper 2 (SAW2)
+
+The SAW2 is a wrapper around the Subsystem Power Manager (SPM) and the
+Adaptive Voltage Scaling (AVS) hardware. The SPM is programmable
+micro-controller that transitions a piece of hardware (like a processor) into
+and out of low power modes via a direct connection to the PMIC. It can also
+be wired up to interact with other processors in the system, notifying them
+when a low power state is entered or exited.
+
+Required Properties:
+
+- compatible : Shall contain "qcom,saw2".
+	       A more specific property can be specified as follows:
+		"qcom,l2-saw2"
+- reg: Specifies the base address and size of the register region.
+
+Example:
+
+	regulator at f9012000 {
+		compatible = "qcom,l2-saw2", "qcom,saw2";
+		reg = <0xf9012000 0x1000>;
+	};
+
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 04/11] devicetree: bindings: Document qcom,saw2 node

[Kumar Gala]

On Nov 1, 2013, at 5:08 PM, Stephen Boyd wrote:

> The saw2 binding describes the SPM/AVS wrapper hardware used to
> control the regulator supplying voltage to the Krait CPUs.
> 
> Cc: <devicetree@vger.kernel.org>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> 
> When a SAW is for a CPU it is put behind the CPU alias region similar
> to the ACC and timers. I haven't documented that here because I'm not using
> it right now. I'm also thinking perhaps l2-saw2 is not important (technically
> its the same hardware block as a CPU's saw). Instead I should point to this
> node via the l2-cache node via some *-supply property. Thoughts?

I don't get this, why wouldn't the SAW just be under the soc node?  Do we really need to encode a relationship between the cpu and the SAW?

And kill the "l2-saw2" stuff until its needed.

Also are SAWs specific to a given SoC or not?

> 
> .../devicetree/bindings/arm/msm/qcom,saw2.txt      | 23 ++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt b/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
> new file mode 100644
> index 0000000..6360db2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
> @@ -0,0 +1,23 @@
> +* SPM AVS Wrapper 2 (SAW2)
> +
> +The SAW2 is a wrapper around the Subsystem Power Manager (SPM) and the
> +Adaptive Voltage Scaling (AVS) hardware. The SPM is programmable
> +micro-controller that transitions a piece of hardware (like a processor) into
> +and out of low power modes via a direct connection to the PMIC. It can also
> +be wired up to interact with other processors in the system, notifying them
> +when a low power state is entered or exited.
> +
> +Required Properties:
> +
> +- compatible : Shall contain "qcom,saw2".
> +	       A more specific property can be specified as follows:
> +		"qcom,l2-saw2"
> +- reg: Specifies the base address and size of the register region.
> +
> +Example:
> +
> +	regulator at f9012000 {
> +		compatible = "qcom,l2-saw2", "qcom,saw2";
> +		reg = <0xf9012000 0x1000>;
> +	};
> +
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[PATCH 05/11] ARM: Introduce CPU_METHOD_OF_DECLARE() for cpu hotplug/smp

[Stephen Boyd]

The goal of multi-platform kernels is to remove the need for mach
directories and machine descriptors. To further that goal,
introduce CPU_METHOD_OF_DECLARE() to allow cpu hotplug/smp
support to be separated from the machine descriptors.
Implementers should specify an enable-method property in their
cpus node and then implement a matching set of smp_ops in their
hotplug/smp code, wiring it up with the CPU_METHOD_OF_DECLARE()
macro. When the kernel is compiled we'll collect all the
enable-method smp_ops into one section for use at boot.

At boot time we'll look for an enable-method in each cpu node and
try to match that against all known CPU enable methods in the
kernel. If there are no enable-methods in the cpu nodes we
fallback to the cpus node and try to use any enable-method found
there. If that doesn't work we fall back to the old way of using
the machine descriptor.

Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: <devicetree@vger.kernel.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
 arch/arm/include/asm/smp.h        |  9 +++++++++
 arch/arm/kernel/devtree.c         | 38 ++++++++++++++++++++++++++++++++++++++
 include/asm-generic/vmlinux.lds.h | 10 ++++++++++
 3 files changed, 57 insertions(+)

diff --git a/arch/arm/include/asm/smp.h b/arch/arm/include/asm/smp.h
index a8cae71c..c27ec55 100644
--- a/arch/arm/include/asm/smp.h
+++ b/arch/arm/include/asm/smp.h
@@ -112,6 +112,15 @@ struct smp_operations {
 #endif
 };
 
+struct of_cpu_method {
+	const char *method;
+	struct smp_operations *ops;
+};
+
+#define CPU_METHOD_OF_DECLARE(name, _method, _ops)			\
+	static const struct of_cpu_method __cpu_method_of_table_##name	\
+		__used __section(__cpu_method_of_table)			\
+		= { .method = _method, .ops = _ops }
 /*
  * set platform specific SMP operations
  */
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index f35906b..71a8592 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -25,6 +25,7 @@
 #include <asm/smp_plat.h>
 #include <asm/mach/arch.h>
 #include <asm/mach-types.h>
+#include <asm/smp.h>
 
 void __init early_init_dt_add_memory_arch(u64 base, u64 size)
 {
@@ -63,6 +64,36 @@ void __init arm_dt_memblock_reserve(void)
 	}
 }
 
+#ifdef CONFIG_SMP
+extern struct of_cpu_method __cpu_method_of_table[];
+
+static const struct of_cpu_method __cpu_method_of_table_sentinel
+	__used __section(__cpu_method_of_table_end);
+
+static int __init set_smp_ops_by_method(struct device_node *node)
+{
+	const char *method;
+	struct of_cpu_method *m = __cpu_method_of_table;
+
+	if (of_property_read_string(node, "enable-method", &method))
+		return 0;
+
+	for (; m != &__cpu_method_of_table_sentinel; m++)
+		if (!strcmp(m->method, method)) {
+			smp_set_ops(m->ops);
+			return 1;
+		}
+
+	return 0;
+}
+#else
+static inline int set_smp_ops_by_method(struct device_node *node)
+{
+	return 1;
+}
+#endif
+
+
 /*
  * arm_dt_init_cpu_maps - Function retrieves cpu nodes from the device tree
  * and builds the cpu logical map array containing MPIDR values related to
@@ -79,6 +110,7 @@ void __init arm_dt_init_cpu_maps(void)
 	 * read as 0.
 	 */
 	struct device_node *cpu, *cpus;
+	int found_method = 0;
 	u32 i, j, cpuidx = 1;
 	u32 mpidr = is_smp() ? read_cpuid_mpidr() & MPIDR_HWID_BITMASK : 0;
 
@@ -150,8 +182,14 @@ void __init arm_dt_init_cpu_maps(void)
 		}
 
 		tmp_map[i] = hwid;
+
+		if (!found_method)
+			found_method = set_smp_ops_by_method(cpu);
 	}
 
+	if (!found_method)
+		set_smp_ops_by_method(cpus);
+
 	if (!bootcpu_valid) {
 		pr_warn("DT missing boot CPU MPIDR[23:0], fall back to default cpu_logical_map\n");
 		return;
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 83e2c31..918b1b5 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -167,6 +167,15 @@
 #define CLK_OF_TABLES()
 #endif
 
+#ifdef CONFIG_SMP
+#define CPU_METHOD_OF_TABLES() . = ALIGN(8);				\
+			   VMLINUX_SYMBOL(__cpu_method_of_table) = .;	\
+			   *(__cpu_method_of_table)			\
+			   *(__cpu_method_of_table_end)
+#else
+#define CPU_METHOD_OF_TABLES()
+#endif
+
 #define KERNEL_DTB()							\
 	STRUCT_ALIGN();							\
 	VMLINUX_SYMBOL(__dtb_start) = .;				\
@@ -490,6 +499,7 @@
 	MEM_DISCARD(init.rodata)					\
 	CLK_OF_TABLES()							\
 	CLKSRC_OF_TABLES()						\
+	CPU_METHOD_OF_TABLES()						\
 	KERNEL_DTB()							\
 	IRQCHIP_OF_MATCH_TABLE()
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 05/11] ARM: Introduce CPU_METHOD_OF_DECLARE() for cpu hotplug/smp

[Kumar Gala]

On Nov 1, 2013, at 5:08 PM, Stephen Boyd wrote:

> The goal of multi-platform kernels is to remove the need for mach
> directories and machine descriptors. To further that goal,
> introduce CPU_METHOD_OF_DECLARE() to allow cpu hotplug/smp
> support to be separated from the machine descriptors.
> Implementers should specify an enable-method property in their
> cpus node and then implement a matching set of smp_ops in their
> hotplug/smp code, wiring it up with the CPU_METHOD_OF_DECLARE()
> macro. When the kernel is compiled we'll collect all the
> enable-method smp_ops into one section for use at boot.
> 
> At boot time we'll look for an enable-method in each cpu node and
> try to match that against all known CPU enable methods in the
> kernel. If there are no enable-methods in the cpu nodes we
> fallback to the cpus node and try to use any enable-method found
> there. If that doesn't work we fall back to the old way of using
> the machine descriptor.
> 
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: <devicetree@vger.kernel.org>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> arch/arm/include/asm/smp.h        |  9 +++++++++
> arch/arm/kernel/devtree.c         | 38 ++++++++++++++++++++++++++++++++++++++
> include/asm-generic/vmlinux.lds.h | 10 ++++++++++
> 3 files changed, 57 insertions(+)
> 
> diff --git a/arch/arm/include/asm/smp.h b/arch/arm/include/asm/smp.h
> index a8cae71c..c27ec55 100644
> --- a/arch/arm/include/asm/smp.h
> +++ b/arch/arm/include/asm/smp.h
> @@ -112,6 +112,15 @@ struct smp_operations {
> #endif
> };
> 
> +struct of_cpu_method {
> +	const char *method;
> +	struct smp_operations *ops;
> +};
> +
> +#define CPU_METHOD_OF_DECLARE(name, _method, _ops)			\
> +	static const struct of_cpu_method __cpu_method_of_table_##name	\
> +		__used __section(__cpu_method_of_table)			\
> +		= { .method = _method, .ops = _ops }
> /*
>  * set platform specific SMP operations
>  */
> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index f35906b..71a8592 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
> @@ -25,6 +25,7 @@
> #include <asm/smp_plat.h>
> #include <asm/mach/arch.h>
> #include <asm/mach-types.h>
> +#include <asm/smp.h>
> 
> void __init early_init_dt_add_memory_arch(u64 base, u64 size)
> {
> @@ -63,6 +64,36 @@ void __init arm_dt_memblock_reserve(void)
> 	}
> }
> 
> +#ifdef CONFIG_SMP
> +extern struct of_cpu_method __cpu_method_of_table[];
> +
> +static const struct of_cpu_method __cpu_method_of_table_sentinel
> +	__used __section(__cpu_method_of_table_end);
> +
> +static int __init set_smp_ops_by_method(struct device_node *node)
> +{
> +	const char *method;
> +	struct of_cpu_method *m = __cpu_method_of_table;
> +
> +	if (of_property_read_string(node, "enable-method", &method))
> +		return 0;
> +
> +	for (; m != &__cpu_method_of_table_sentinel; m++)
> +		if (!strcmp(m->method, method)) {
> +			smp_set_ops(m->ops);
> +			return 1;
> +		}
> +
> +	return 0;
> +}
> +#else
> +static inline int set_smp_ops_by_method(struct device_node *node)
> +{
> +	return 1;
> +}
> +#endif
> +
> +
> /*
>  * arm_dt_init_cpu_maps - Function retrieves cpu nodes from the device tree
>  * and builds the cpu logical map array containing MPIDR values related to
> @@ -79,6 +110,7 @@ void __init arm_dt_init_cpu_maps(void)
> 	 * read as 0.
> 	 */
> 	struct device_node *cpu, *cpus;
> +	int found_method = 0;
> 	u32 i, j, cpuidx = 1;
> 	u32 mpidr = is_smp() ? read_cpuid_mpidr() & MPIDR_HWID_BITMASK : 0;
> 
> @@ -150,8 +182,14 @@ void __init arm_dt_init_cpu_maps(void)
> 		}
> 
> 		tmp_map[i] = hwid;
> +
> +		if (!found_method)
> +			found_method = set_smp_ops_by_method(cpu);
> 	}
> 
> +	if (!found_method)
> +		set_smp_ops_by_method(cpus);
> +

I assume this if for the case that the enable method is in the cpus{ } container but not in a specific cpu node?

If so, the binding is not clear that we allow this.  Also a comment would probably be nice.

> 	if (!bootcpu_valid) {
> 		pr_warn("DT missing boot CPU MPIDR[23:0], fall back to default cpu_logical_map\n");
> 		return;

- k

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

[PATCH 05/11] ARM: Introduce CPU_METHOD_OF_DECLARE() for cpu hotplug/smp

[Stephen Boyd]

On 11/05/13 09:24, Kumar Gala wrote:
> On Nov 1, 2013, at 5:08 PM, Stephen Boyd wrote:
>
>> @@ -150,8 +182,14 @@ void __init arm_dt_init_cpu_maps(void)
>> 		}
>>
>> 		tmp_map[i] = hwid;
>> +
>> +		if (!found_method)
>> +			found_method = set_smp_ops_by_method(cpu);
>> 	}
>>
>> +	if (!found_method)
>> +		set_smp_ops_by_method(cpus);
>> +
> I assume this if for the case that the enable method is in the cpus{ } container but not in a specific cpu node?
>
> If so, the binding is not clear that we allow this.  Also a comment would probably be nice.

Sure I'll add a comment to that effect and clarify the binding.

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

[PATCH 05/11] ARM: Introduce CPU_METHOD_OF_DECLARE() for cpu hotplug/smp

[Josh Cartwright]

Hey Stephen-

Nit/suggestion below:

On Fri, Nov 01, 2013 at 03:08:53PM -0700, Stephen Boyd wrote:
[..]
> diff --git a/arch/arm/include/asm/smp.h b/arch/arm/include/asm/smp.h
> index a8cae71c..c27ec55 100644
> --- a/arch/arm/include/asm/smp.h
> +++ b/arch/arm/include/asm/smp.h
> @@ -112,6 +112,15 @@ struct smp_operations {
>  #endif
>  };
>  
> +struct of_cpu_method {
> +	const char *method;
> +	struct smp_operations *ops;
> +};
> +
> +#define CPU_METHOD_OF_DECLARE(name, _method, _ops)			\
> +	static const struct of_cpu_method __cpu_method_of_table_##name	\
> +		__used __section(__cpu_method_of_table)			\
> +		= { .method = _method, .ops = _ops }
>  /*
>   * set platform specific SMP operations
>   */
> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index f35906b..71a8592 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
> @@ -25,6 +25,7 @@
>  #include <asm/smp_plat.h>
>  #include <asm/mach/arch.h>
>  #include <asm/mach-types.h>
> +#include <asm/smp.h>
>  
>  void __init early_init_dt_add_memory_arch(u64 base, u64 size)
>  {
> @@ -63,6 +64,36 @@ void __init arm_dt_memblock_reserve(void)
>  	}
>  }
>  
> +#ifdef CONFIG_SMP
> +extern struct of_cpu_method __cpu_method_of_table[];
> +
> +static const struct of_cpu_method __cpu_method_of_table_sentinel
> +	__used __section(__cpu_method_of_table_end);

Having a sentinel allocated into the linked image makes a lot of sense
in other cases (IRQCHIP/CLOCKSOURCE_OF_DECLARE, etc), where it's used to
terminate an of_device_id table (as is expected by of_match_table and
friends).

In this case, however, you aren't building a match table, so having a
sentinel allocated isn't necessary.  I'd suggest bookending the table
with a VMLINUX_SYMBOL(__cpu_method_of_table_end) instead.

A whole 2 pointers worth of savings!

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

[PATCH 05/11] ARM: Introduce CPU_METHOD_OF_DECLARE() for cpu hotplug/smp

[Stephen Boyd]

On 11/06/13 17:50, Josh Cartwright wrote:
> On Fri, Nov 01, 2013 at 03:08:53PM -0700, Stephen Boyd wrote:
>> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
>> index f35906b..71a8592 100644
>> --- a/arch/arm/kernel/devtree.c
>> +++ b/arch/arm/kernel/devtree.c
>> @@ -25,6 +25,7 @@
>>  #include <asm/smp_plat.h>
>>  #include <asm/mach/arch.h>
>>  #include <asm/mach-types.h>
>> +#include <asm/smp.h>
>>  
>>  void __init early_init_dt_add_memory_arch(u64 base, u64 size)
>>  {
>> @@ -63,6 +64,36 @@ void __init arm_dt_memblock_reserve(void)
>>  	}
>>  }
>>  
>> +#ifdef CONFIG_SMP
>> +extern struct of_cpu_method __cpu_method_of_table[];
>> +
>> +static const struct of_cpu_method __cpu_method_of_table_sentinel
>> +	__used __section(__cpu_method_of_table_end);
> Having a sentinel allocated into the linked image makes a lot of sense
> in other cases (IRQCHIP/CLOCKSOURCE_OF_DECLARE, etc), where it's used to
> terminate an of_device_id table (as is expected by of_match_table and
> friends).
>
> In this case, however, you aren't building a match table, so having a
> sentinel allocated isn't necessary.  I'd suggest bookending the table
> with a VMLINUX_SYMBOL(__cpu_method_of_table_end) instead.
>
> A whole 2 pointers worth of savings!
>

Yes, will do. Thanks.

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

[PATCH 06/11] ARM: msm: Remove pen_release usage

[Stephen Boyd]

From: Rohit Vaswani <rvaswani@codeaurora.org>

pen_release is no longer required as the synchronization
is now managed by generic arm code.
This is done as suggested in https://lkml.org/lkml/2013/6/4/184

Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
 arch/arm/mach-msm/Makefile  |  2 +-
 arch/arm/mach-msm/headsmp.S | 39 ---------------------------------------
 arch/arm/mach-msm/hotplug.c | 31 ++++---------------------------
 arch/arm/mach-msm/platsmp.c | 35 +++--------------------------------
 4 files changed, 8 insertions(+), 99 deletions(-)
 delete mode 100644 arch/arm/mach-msm/headsmp.S

diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile
index 7ed4c1b..15562cf 100644
--- a/arch/arm/mach-msm/Makefile
+++ b/arch/arm/mach-msm/Makefile
@@ -19,7 +19,7 @@ obj-$(CONFIG_MSM_SCM) += scm.o scm-boot.o
 CFLAGS_scm.o :=$(call as-instr,.arch_extension sec,-DREQUIRES_SEC=1)
 
 obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
-obj-$(CONFIG_SMP) += headsmp.o platsmp.o
+obj-$(CONFIG_SMP) += platsmp.o
 
 obj-$(CONFIG_MACH_TROUT) += board-trout.o board-trout-gpio.o board-trout-mmc.o devices-msm7x00.o
 obj-$(CONFIG_MACH_TROUT) += board-trout.o board-trout-gpio.o board-trout-mmc.o board-trout-panel.o devices-msm7x00.o
diff --git a/arch/arm/mach-msm/headsmp.S b/arch/arm/mach-msm/headsmp.S
deleted file mode 100644
index 6c62c3f..0000000
--- a/arch/arm/mach-msm/headsmp.S
+++ /dev/null
@@ -1,39 +0,0 @@
-/*
- *  linux/arch/arm/mach-realview/headsmp.S
- *
- *  Copyright (c) 2003 ARM Limited
- *  All Rights Reserved
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#include <linux/linkage.h>
-#include <linux/init.h>
-
-/*
- * MSM specific entry point for secondary CPUs.  This provides
- * a "holding pen" into which all secondary cores are held until we're
- * ready for them to initialise.
- */
-ENTRY(msm_secondary_startup)
-	mrc	p15, 0, r0, c0, c0, 5
-	and	r0, r0, #15
-	adr	r4, 1f
-	ldmia	r4, {r5, r6}
-	sub	r4, r4, r5
-	add	r6, r6, r4
-pen:	ldr	r7, [r6]
-	cmp	r7, r0
-	bne	pen
-
-	/*
-	 * we've been released from the holding pen: secondary_stack
-	 * should now contain the SVC stack for this core
-	 */
-	b	secondary_startup
-ENDPROC(msm_secondary_startup)
-
-	.align
-1:	.long	.
-	.long	pen_release
diff --git a/arch/arm/mach-msm/hotplug.c b/arch/arm/mach-msm/hotplug.c
index 326a872..cea80fc 100644
--- a/arch/arm/mach-msm/hotplug.c
+++ b/arch/arm/mach-msm/hotplug.c
@@ -24,33 +24,10 @@ static inline void cpu_leave_lowpower(void)
 
 static inline void platform_do_lowpower(unsigned int cpu)
 {
-	/* Just enter wfi for now. TODO: Properly shut off the cpu. */
-	for (;;) {
-		/*
-		 * here's the WFI
-		 */
-		asm("wfi"
-		    :
-		    :
-		    : "memory", "cc");
-
-		if (pen_release == cpu_logical_map(cpu)) {
-			/*
-			 * OK, proper wakeup, we're done
-			 */
-			break;
-		}
-
-		/*
-		 * getting here, means that we have come out of WFI without
-		 * having been woken up - this shouldn't happen
-		 *
-		 * The trouble is, letting people know about this is not really
-		 * possible, since we are currently running incoherently, and
-		 * therefore cannot safely call printk() or anything else
-		 */
-		pr_debug("CPU%u: spurious wakeup call\n", cpu);
-	}
+	asm("wfi"
+	    :
+	    :
+	    : "memory", "cc");
 }
 
 /*
diff --git a/arch/arm/mach-msm/platsmp.c b/arch/arm/mach-msm/platsmp.c
index 3f06edc..5b481db 100644
--- a/arch/arm/mach-msm/platsmp.c
+++ b/arch/arm/mach-msm/platsmp.c
@@ -28,7 +28,7 @@
 #define SCSS_CPU1CORE_RESET 0xD80
 #define SCSS_DBG_STATUS_CORE_PWRDUP 0xE64
 
-extern void msm_secondary_startup(void);
+extern void secondary_startup(void);
 
 static DEFINE_SPINLOCK(boot_lock);
 
@@ -41,13 +41,6 @@ static inline int get_core_count(void)
 static void msm_secondary_init(unsigned int cpu)
 {
 	/*
-	 * let the primary processor know we're out of the
-	 * pen, then head off into the C entry point
-	 */
-	pen_release = -1;
-	smp_wmb();
-
-	/*
 	 * Synchronise with the boot thread.
 	 */
 	spin_lock(&boot_lock);
@@ -57,7 +50,7 @@ static void msm_secondary_init(unsigned int cpu)
 static void prepare_cold_cpu(unsigned int cpu)
 {
 	int ret;
-	ret = scm_set_boot_addr(virt_to_phys(msm_secondary_startup),
+	ret = scm_set_boot_addr(virt_to_phys(secondary_startup),
 				SCM_FLAG_COLDBOOT_CPU1);
 	if (ret == 0) {
 		void __iomem *sc1_base_ptr;
@@ -75,7 +68,6 @@ static void prepare_cold_cpu(unsigned int cpu)
 
 static int msm_boot_secondary(unsigned int cpu, struct task_struct *idle)
 {
-	unsigned long timeout;
 	static int cold_boot_done;
 
 	/* Only need to bring cpu out of reset this way once */
@@ -91,40 +83,19 @@ static int msm_boot_secondary(unsigned int cpu, struct task_struct *idle)
 	spin_lock(&boot_lock);
 
 	/*
-	 * The secondary processor is waiting to be released from
-	 * the holding pen - release it, then wait for it to flag
-	 * that it has been released by resetting pen_release.
-	 *
-	 * Note that "pen_release" is the hardware CPU ID, whereas
-	 * "cpu" is Linux's internal ID.
-	 */
-	pen_release = cpu_logical_map(cpu);
-	__cpuc_flush_dcache_area((void *)&pen_release, sizeof(pen_release));
-	outer_clean_range(__pa(&pen_release), __pa(&pen_release + 1));
-
-	/*
 	 * Send the secondary CPU a soft interrupt, thereby causing
 	 * the boot monitor to read the system wide flags register,
 	 * and branch to the address found there.
 	 */
 	arch_send_wakeup_ipi_mask(cpumask_of(cpu));
 
-	timeout = jiffies + (1 * HZ);
-	while (time_before(jiffies, timeout)) {
-		smp_rmb();
-		if (pen_release == -1)
-			break;
-
-		udelay(10);
-	}
-
 	/*
 	 * now the secondary core is starting up let it run its
 	 * calibrations, then wait for it to finish
 	 */
 	spin_unlock(&boot_lock);
 
-	return pen_release != -1 ? -ENOSYS : 0;
+	return 0;
 }
 
 /*
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 07/11] ARM: msm: Re-organize platsmp to make it extensible

[Stephen Boyd]

From: Rohit Vaswani <rvaswani@codeaurora.org>

This makes it easy to add SMP support for new devices by keying
on a device node for the release sequence. We add the
enable-method property for the cpus property to specify that we
want to use the mmio release sequence (which is going to look for
a device node to map some Scorpion specific power and control
registers). While at it, add the 8660 cpus bindings to make SMP
work.

Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
[sboyd: Port to CPU_METHOD_OF_DECLARE, replace if/else with match
table method]
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
 arch/arm/boot/dts/qcom-msm8660-surf.dts |  24 ++++++++
 arch/arm/mach-msm/board-dt.c            |  14 -----
 arch/arm/mach-msm/common.h              |   1 -
 arch/arm/mach-msm/platsmp.c             | 103 ++++++++++++++++++++++++--------
 4 files changed, 103 insertions(+), 39 deletions(-)

diff --git a/arch/arm/boot/dts/qcom-msm8660-surf.dts b/arch/arm/boot/dts/qcom-msm8660-surf.dts
index 386d428..ac5ea76 100644
--- a/arch/arm/boot/dts/qcom-msm8660-surf.dts
+++ b/arch/arm/boot/dts/qcom-msm8660-surf.dts
@@ -7,6 +7,23 @@
 	compatible = "qcom,msm8660-surf", "qcom,msm8660";
 	interrupt-parent = <&intc>;
 
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "qcom,scorpion";
+		enable-method = "qcom,mmio";
+
+		cpu at 0 {
+			device_type = "cpu";
+			reg = <0>;
+		};
+
+		cpu at 1 {
+			device_type = "cpu";
+			reg = <1>;
+		};
+	};
+
 	intc: interrupt-controller at 2080000 {
 		compatible = "qcom,msm-8660-qgic";
 		interrupt-controller;
@@ -37,6 +54,13 @@
 		#interrupt-cells = <2>;
 	};
 
+	clock-controller at 900000 {
+		compatible = "qcom,gcc-8660";
+		reg = <0x00900000 0x4000>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
 	serial at 19c40000 {
 		compatible = "qcom,msm-uartdm-v1.3", "qcom,msm-uartdm";
 		reg = <0x19c40000 0x1000>,
diff --git a/arch/arm/mach-msm/board-dt.c b/arch/arm/mach-msm/board-dt.c
index 1f11d93..1e3af2b 100644
--- a/arch/arm/mach-msm/board-dt.c
+++ b/arch/arm/mach-msm/board-dt.c
@@ -11,31 +11,17 @@
  */
 
 #include <linux/init.h>
-#include <linux/of.h>
-#include <linux/of_platform.h>
 
 #include <asm/mach/arch.h>
-#include <asm/mach/map.h>
-
-#include "common.h"
 
 static const char * const msm_dt_match[] __initconst = {
 	"qcom,msm8660-fluid",
 	"qcom,msm8660-surf",
 	"qcom,msm8960-cdp",
-	NULL
-};
-
-static const char * const apq8074_dt_match[] __initconst = {
 	"qcom,apq8074-dragonboard",
 	NULL
 };
 
 DT_MACHINE_START(MSM_DT, "Qualcomm MSM (Flattened Device Tree)")
-	.smp = smp_ops(msm_smp_ops),
 	.dt_compat = msm_dt_match,
 MACHINE_END
-
-DT_MACHINE_START(APQ_DT, "Qualcomm MSM (Flattened Device Tree)")
-	.dt_compat = apq8074_dt_match,
-MACHINE_END
diff --git a/arch/arm/mach-msm/common.h b/arch/arm/mach-msm/common.h
index 33c7725..1513f2c 100644
--- a/arch/arm/mach-msm/common.h
+++ b/arch/arm/mach-msm/common.h
@@ -23,7 +23,6 @@ extern void msm_map_qsd8x50_io(void);
 extern void __iomem *__msm_ioremap_caller(phys_addr_t phys_addr, size_t size,
 					  unsigned int mtype, void *caller);
 
-extern struct smp_operations msm_smp_ops;
 extern void msm_cpu_die(unsigned int cpu);
 
 struct msm_mmc_platform_data;
diff --git a/arch/arm/mach-msm/platsmp.c b/arch/arm/mach-msm/platsmp.c
index 5b481db..369d8f7 100644
--- a/arch/arm/mach-msm/platsmp.c
+++ b/arch/arm/mach-msm/platsmp.c
@@ -13,6 +13,8 @@
 #include <linux/delay.h>
 #include <linux/device.h>
 #include <linux/jiffies.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
 #include <linux/smp.h>
 #include <linux/io.h>
 
@@ -24,9 +26,9 @@
 #include "scm-boot.h"
 #include "common.h"
 
-#define VDD_SC1_ARRAY_CLAMP_GFS_CTL 0x15A0
-#define SCSS_CPU1CORE_RESET 0xD80
-#define SCSS_DBG_STATUS_CORE_PWRDUP 0xE64
+#define VDD_SC1_ARRAY_CLAMP_GFS_CTL	0x35a0
+#define SCSS_CPU1CORE_RESET		0x2d80
+#define SCSS_DBG_STATUS_CORE_PWRDUP	0x2e64
 
 extern void secondary_startup(void);
 
@@ -47,34 +49,62 @@ static void msm_secondary_init(unsigned int cpu)
 	spin_unlock(&boot_lock);
 }
 
-static void prepare_cold_cpu(unsigned int cpu)
+static int scss_release_secondary(struct device_node *node, unsigned int cpu)
+{
+	void __iomem *base;
+
+	base = of_iomap(node, 0);
+	if (!base)
+		return -ENOMEM;
+
+	writel_relaxed(0, base + VDD_SC1_ARRAY_CLAMP_GFS_CTL);
+	writel_relaxed(0, base + SCSS_CPU1CORE_RESET);
+	writel_relaxed(3, base + SCSS_DBG_STATUS_CORE_PWRDUP);
+	mb();
+	iounmap(base);
+
+	return 0;
+}
+
+static DEFINE_PER_CPU(int, cold_boot_done);
+
+static int boot_cold_cpu(unsigned int cpu)
 {
 	int ret;
-	ret = scm_set_boot_addr(virt_to_phys(secondary_startup),
-				SCM_FLAG_COLDBOOT_CPU1);
-	if (ret == 0) {
-		void __iomem *sc1_base_ptr;
-		sc1_base_ptr = ioremap_nocache(0x00902000, SZ_4K*2);
-		if (sc1_base_ptr) {
-			writel(0, sc1_base_ptr + VDD_SC1_ARRAY_CLAMP_GFS_CTL);
-			writel(0, sc1_base_ptr + SCSS_CPU1CORE_RESET);
-			writel(3, sc1_base_ptr + SCSS_DBG_STATUS_CORE_PWRDUP);
-			iounmap(sc1_base_ptr);
-		}
-	} else
-		printk(KERN_DEBUG "Failed to set secondary core boot "
-				  "address\n");
+	struct device_node *node;
+	const struct of_device_id *match;
+	const int (*func)(struct device_node *, int);
+#define M(c, f) { .compatible = c, .data = f }
+	static const struct of_device_id match_table[] = {
+		M("qcom,gcc-8660", scss_release_secondary),
+	};
+#undef M
+
+	if (per_cpu(cold_boot_done, cpu))
+		return 0;
+
+	node = of_find_matching_node_and_match(NULL, match_table, &match);
+	if (!node) {
+		pr_err("%s: can't find subsystem node\n", __func__);
+		return -ENXIO;
+	}
+
+	func = match->data;
+	ret = func(node, cpu);
+	if (!ret)
+		per_cpu(cold_boot_done, cpu) = true;
+	of_node_put(node);
+
+	return ret;
 }
 
 static int msm_boot_secondary(unsigned int cpu, struct task_struct *idle)
 {
-	static int cold_boot_done;
+	int ret;
 
-	/* Only need to bring cpu out of reset this way once */
-	if (cold_boot_done == false) {
-		prepare_cold_cpu(cpu);
-		cold_boot_done = true;
-	}
+	ret = boot_cold_cpu(cpu);
+	if (ret)
+		return ret;
 
 	/*
 	 * set synchronisation state between this boot processor
@@ -120,6 +150,30 @@ static void __init msm_smp_init_cpus(void)
 
 static void __init msm_smp_prepare_cpus(unsigned int max_cpus)
 {
+	int cpu, map;
+	unsigned int flags = 0;
+	static const int cold_boot_flags[] = {
+		0,
+		SCM_FLAG_COLDBOOT_CPU1,
+	};
+
+	for_each_present_cpu(cpu) {
+		map = cpu_logical_map(cpu);
+		if (WARN_ON(map >= ARRAY_SIZE(cold_boot_flags))) {
+			set_cpu_present(cpu, false);
+			continue;
+		}
+		flags |= cold_boot_flags[map];
+	}
+
+	if (scm_set_boot_addr(virt_to_phys(secondary_startup), flags)) {
+		for_each_present_cpu(cpu) {
+			if (cpu == smp_processor_id())
+				continue;
+			set_cpu_present(cpu, false);
+		}
+		pr_warn("Failed to set CPU boot address, disabling SMP\n");
+	}
 }
 
 struct smp_operations msm_smp_ops __initdata = {
@@ -131,3 +185,4 @@ struct smp_operations msm_smp_ops __initdata = {
 	.cpu_die		= msm_cpu_die,
 #endif
 };
+CPU_METHOD_OF_DECLARE(msm_smp, "qcom,mmio", &msm_smp_ops);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 07/11] ARM: msm: Re-organize platsmp to make it extensible

[Kumar Gala]

On Nov 1, 2013, at 5:08 PM, Stephen Boyd wrote:

> From: Rohit Vaswani <rvaswani@codeaurora.org>
> 
> This makes it easy to add SMP support for new devices by keying
> on a device node for the release sequence. We add the
> enable-method property for the cpus property to specify that we
> want to use the mmio release sequence (which is going to look for
> a device node to map some Scorpion specific power and control
> registers). While at it, add the 8660 cpus bindings to make SMP
> work.
> 
> Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
> [sboyd: Port to CPU_METHOD_OF_DECLARE, replace if/else with match
> table method]
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> arch/arm/boot/dts/qcom-msm8660-surf.dts |  24 ++++++++
> arch/arm/mach-msm/board-dt.c            |  14 -----
> arch/arm/mach-msm/common.h              |   1 -
> arch/arm/mach-msm/platsmp.c             | 103 ++++++++++++++++++++++++--------
> 4 files changed, 103 insertions(+), 39 deletions(-)

This feels like a few different patches munged together.

> diff --git a/arch/arm/boot/dts/qcom-msm8660-surf.dts b/arch/arm/boot/dts/qcom-msm8660-surf.dts
> index 386d428..ac5ea76 100644
> --- a/arch/arm/boot/dts/qcom-msm8660-surf.dts
> +++ b/arch/arm/boot/dts/qcom-msm8660-surf.dts
> @@ -7,6 +7,23 @@
> 	compatible = "qcom,msm8660-surf", "qcom,msm8660";
> 	interrupt-parent = <&intc>;
> 
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		compatible = "qcom,scorpion";
> +		enable-method = "qcom,mmio";
> +
> +		cpu at 0 {
> +			device_type = "cpu";
> +			reg = <0>;
> +		};
> +
> +		cpu at 1 {
> +			device_type = "cpu";
> +			reg = <1>;
> +		};
> +	};
> +
> 	intc: interrupt-controller at 2080000 {
> 		compatible = "qcom,msm-8660-qgic";
> 		interrupt-controller;
> @@ -37,6 +54,13 @@
> 		#interrupt-cells = <2>;
> 	};
> 
> +	clock-controller at 900000 {
> +		compatible = "qcom,gcc-8660";
> +		reg = <0x00900000 0x4000>;
> +		#clock-cells = <1>;
> +		#reset-cells = <1>;
> +	};
> +
> 	serial at 19c40000 {
> 		compatible = "qcom,msm-uartdm-v1.3", "qcom,msm-uartdm";
> 		reg = <0x19c40000 0x1000>,
> diff --git a/arch/arm/mach-msm/board-dt.c b/arch/arm/mach-msm/board-dt.c
> index 1f11d93..1e3af2b 100644
> --- a/arch/arm/mach-msm/board-dt.c
> +++ b/arch/arm/mach-msm/board-dt.c
> @@ -11,31 +11,17 @@
>  */
> 
> #include <linux/init.h>
> -#include <linux/of.h>
> -#include <linux/of_platform.h>
> 
> #include <asm/mach/arch.h>
> -#include <asm/mach/map.h>
> -
> -#include "common.h"
> 
> static const char * const msm_dt_match[] __initconst = {
> 	"qcom,msm8660-fluid",
> 	"qcom,msm8660-surf",
> 	"qcom,msm8960-cdp",
> -	NULL
> -};
> -
> -static const char * const apq8074_dt_match[] __initconst = {
> 	"qcom,apq8074-dragonboard",
> 	NULL
> };
> 
> DT_MACHINE_START(MSM_DT, "Qualcomm MSM (Flattened Device Tree)")
> -	.smp = smp_ops(msm_smp_ops),
> 	.dt_compat = msm_dt_match,
> MACHINE_END
> -
> -DT_MACHINE_START(APQ_DT, "Qualcomm MSM (Flattened Device Tree)")
> -	.dt_compat = apq8074_dt_match,
> -MACHINE_END
> diff --git a/arch/arm/mach-msm/common.h b/arch/arm/mach-msm/common.h
> index 33c7725..1513f2c 100644
> --- a/arch/arm/mach-msm/common.h
> +++ b/arch/arm/mach-msm/common.h
> @@ -23,7 +23,6 @@ extern void msm_map_qsd8x50_io(void);
> extern void __iomem *__msm_ioremap_caller(phys_addr_t phys_addr, size_t size,
> 					  unsigned int mtype, void *caller);
> 
> -extern struct smp_operations msm_smp_ops;
> extern void msm_cpu_die(unsigned int cpu);
> 
> struct msm_mmc_platform_data;
> diff --git a/arch/arm/mach-msm/platsmp.c b/arch/arm/mach-msm/platsmp.c
> index 5b481db..369d8f7 100644
> --- a/arch/arm/mach-msm/platsmp.c
> +++ b/arch/arm/mach-msm/platsmp.c
> @@ -13,6 +13,8 @@
> #include <linux/delay.h>
> #include <linux/device.h>
> #include <linux/jiffies.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> #include <linux/smp.h>
> #include <linux/io.h>
> 
> @@ -24,9 +26,9 @@
> #include "scm-boot.h"
> #include "common.h"
> 
> -#define VDD_SC1_ARRAY_CLAMP_GFS_CTL 0x15A0
> -#define SCSS_CPU1CORE_RESET 0xD80
> -#define SCSS_DBG_STATUS_CORE_PWRDUP 0xE64
> +#define VDD_SC1_ARRAY_CLAMP_GFS_CTL	0x35a0
> +#define SCSS_CPU1CORE_RESET		0x2d80
> +#define SCSS_DBG_STATUS_CORE_PWRDUP	0x2e64
> 
> extern void secondary_startup(void);
> 
> @@ -47,34 +49,62 @@ static void msm_secondary_init(unsigned int cpu)
> 	spin_unlock(&boot_lock);
> }
> 
> -static void prepare_cold_cpu(unsigned int cpu)
> +static int scss_release_secondary(struct device_node *node, unsigned int cpu)
> +{
> +	void __iomem *base;
> +
> +	base = of_iomap(node, 0);
> +	if (!base)
> +		return -ENOMEM;
> +
> +	writel_relaxed(0, base + VDD_SC1_ARRAY_CLAMP_GFS_CTL);
> +	writel_relaxed(0, base + SCSS_CPU1CORE_RESET);
> +	writel_relaxed(3, base + SCSS_DBG_STATUS_CORE_PWRDUP);
> +	mb();
> +	iounmap(base);
> +
> +	return 0;
> +}
> +
> +static DEFINE_PER_CPU(int, cold_boot_done);
> +
> +static int boot_cold_cpu(unsigned int cpu)
> {
> 	int ret;
> -	ret = scm_set_boot_addr(virt_to_phys(secondary_startup),
> -				SCM_FLAG_COLDBOOT_CPU1);
> -	if (ret == 0) {
> -		void __iomem *sc1_base_ptr;
> -		sc1_base_ptr = ioremap_nocache(0x00902000, SZ_4K*2);
> -		if (sc1_base_ptr) {
> -			writel(0, sc1_base_ptr + VDD_SC1_ARRAY_CLAMP_GFS_CTL);
> -			writel(0, sc1_base_ptr + SCSS_CPU1CORE_RESET);
> -			writel(3, sc1_base_ptr + SCSS_DBG_STATUS_CORE_PWRDUP);
> -			iounmap(sc1_base_ptr);
> -		}
> -	} else
> -		printk(KERN_DEBUG "Failed to set secondary core boot "
> -				  "address\n");
> +	struct device_node *node;
> +	const struct of_device_id *match;
> +	const int (*func)(struct device_node *, int);
> +#define M(c, f) { .compatible = c, .data = f }
> +	static const struct of_device_id match_table[] = {
> +		M("qcom,gcc-8660", scss_release_secondary),
> +	};
> +#undef M

Uughh..

Can't we just do a of_find_compatible_node(), however I think this will change based on my other comments.

> +
> +	if (per_cpu(cold_boot_done, cpu))
> +		return 0;
> +
> +	node = of_find_matching_node_and_match(NULL, match_table, &match);
> +	if (!node) {
> +		pr_err("%s: can't find subsystem node\n", __func__);
> +		return -ENXIO;
> +	}
> +
> +	func = match->data;
> +	ret = func(node, cpu);
> +	if (!ret)
> +		per_cpu(cold_boot_done, cpu) = true;
> +	of_node_put(node);
> +
> +	return ret;
> }
> 
> static int msm_boot_secondary(unsigned int cpu, struct task_struct *idle)
> {
> -	static int cold_boot_done;
> +	int ret;
> 
> -	/* Only need to bring cpu out of reset this way once */
> -	if (cold_boot_done == false) {
> -		prepare_cold_cpu(cpu);
> -		cold_boot_done = true;
> -	}
> +	ret = boot_cold_cpu(cpu);
> +	if (ret)
> +		return ret;
> 
> 	/*
> 	 * set synchronisation state between this boot processor
> @@ -120,6 +150,30 @@ static void __init msm_smp_init_cpus(void)
> 
> static void __init msm_smp_prepare_cpus(unsigned int max_cpus)
> {
> +	int cpu, map;
> +	unsigned int flags = 0;
> +	static const int cold_boot_flags[] = {
> +		0,
> +		SCM_FLAG_COLDBOOT_CPU1,
> +	};
> +
> +	for_each_present_cpu(cpu) {
> +		map = cpu_logical_map(cpu);
> +		if (WARN_ON(map >= ARRAY_SIZE(cold_boot_flags))) {
> +			set_cpu_present(cpu, false);
> +			continue;
> +		}
> +		flags |= cold_boot_flags[map];
> +	}
> +
> +	if (scm_set_boot_addr(virt_to_phys(secondary_startup), flags)) {
> +		for_each_present_cpu(cpu) {
> +			if (cpu == smp_processor_id())
> +				continue;
> +			set_cpu_present(cpu, false);
> +		}
> +		pr_warn("Failed to set CPU boot address, disabling SMP\n");
> +	}
> }
> 
> struct smp_operations msm_smp_ops __initdata = {
> @@ -131,3 +185,4 @@ struct smp_operations msm_smp_ops __initdata = {
> 	.cpu_die		= msm_cpu_die,
> #endif
> };
> +CPU_METHOD_OF_DECLARE(msm_smp, "qcom,mmio", &msm_smp_ops);
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[PATCH 08/11] ARM: msm: Add SMP support for KPSSv1

[Stephen Boyd]

From: Rohit Vaswani <rvaswani@codeaurora.org>

Implement support for the Krait CPU release sequence when the
CPUs are part of the first version of the krait processor
subsystem.

Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
 arch/arm/mach-msm/platsmp.c  | 56 ++++++++++++++++++++++++++++++++++++++++++++
 arch/arm/mach-msm/scm-boot.h |  8 ++++---
 2 files changed, 61 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-msm/platsmp.c b/arch/arm/mach-msm/platsmp.c
index 369d8f7..e187c6e 100644
--- a/arch/arm/mach-msm/platsmp.c
+++ b/arch/arm/mach-msm/platsmp.c
@@ -17,6 +17,7 @@
 #include <linux/of_address.h>
 #include <linux/smp.h>
 #include <linux/io.h>
+#include <linux/sizes.h>
 
 #include <asm/cacheflush.h>
 #include <asm/cputype.h>
@@ -30,6 +31,10 @@
 #define SCSS_CPU1CORE_RESET		0x2d80
 #define SCSS_DBG_STATUS_CORE_PWRDUP	0x2e64
 
+#define APCS_CPU_PWR_CTL	0x04
+
+#define APCS_SAW2_VCTL		0x14
+
 extern void secondary_startup(void);
 
 static DEFINE_SPINLOCK(boot_lock);
@@ -66,6 +71,54 @@ static int scss_release_secondary(struct device_node *node, unsigned int cpu)
 	return 0;
 }
 
+static int kpssv1_release_secondary(struct device_node *node, unsigned int cpu)
+{
+	u32 off;
+	struct resource res;
+	void __iomem *reg;
+
+	if (of_property_read_u32(node, "cpu-offset", &off))
+		return -EINVAL;
+
+	if (of_address_to_resource(node, 0, &res))
+		return -EINVAL;
+
+	/* The SAW base is always next to the ACC base so just map both */
+	reg = ioremap(res.start + off + (SZ_64K * cpu),
+			resource_size(&res) + SZ_4K);
+	if (!reg)
+		return -ENOMEM;
+
+	/* Turn on CPU rail */
+	writel_relaxed(0xA4, reg + SZ_4K + APCS_SAW2_VCTL);
+	mb();
+	udelay(512);
+
+	/* Krait bring-up sequence */
+	writel_relaxed(0x109, reg + APCS_CPU_PWR_CTL);
+	writel_relaxed(0x101, reg + APCS_CPU_PWR_CTL);
+	mb();
+	ndelay(300);
+
+	writel_relaxed(0x121, reg + APCS_CPU_PWR_CTL);
+	mb();
+	udelay(2);
+
+	writel_relaxed(0x120, reg + APCS_CPU_PWR_CTL);
+	mb();
+	udelay(2);
+
+	writel_relaxed(0x100, reg + APCS_CPU_PWR_CTL);
+	mb();
+	udelay(100);
+
+	writel_relaxed(0x180, reg + APCS_CPU_PWR_CTL);
+	mb();
+
+	iounmap(reg);
+	return 0;
+}
+
 static DEFINE_PER_CPU(int, cold_boot_done);
 
 static int boot_cold_cpu(unsigned int cpu)
@@ -77,6 +130,7 @@ static int boot_cold_cpu(unsigned int cpu)
 #define M(c, f) { .compatible = c, .data = f }
 	static const struct of_device_id match_table[] = {
 		M("qcom,gcc-8660", scss_release_secondary),
+		M("qcom,kpss-acc-v1", kpssv1_release_secondary),
 	};
 #undef M
 
@@ -155,6 +209,8 @@ static void __init msm_smp_prepare_cpus(unsigned int max_cpus)
 	static const int cold_boot_flags[] = {
 		0,
 		SCM_FLAG_COLDBOOT_CPU1,
+		SCM_FLAG_COLDBOOT_CPU2,
+		SCM_FLAG_COLDBOOT_CPU3,
 	};
 
 	for_each_present_cpu(cpu) {
diff --git a/arch/arm/mach-msm/scm-boot.h b/arch/arm/mach-msm/scm-boot.h
index 7be32ff..6aabb24 100644
--- a/arch/arm/mach-msm/scm-boot.h
+++ b/arch/arm/mach-msm/scm-boot.h
@@ -13,9 +13,11 @@
 #define __MACH_SCM_BOOT_H
 
 #define SCM_BOOT_ADDR			0x1
-#define SCM_FLAG_COLDBOOT_CPU1		0x1
-#define SCM_FLAG_WARMBOOT_CPU1		0x2
-#define SCM_FLAG_WARMBOOT_CPU0		0x4
+#define SCM_FLAG_COLDBOOT_CPU1		0x01
+#define SCM_FLAG_COLDBOOT_CPU2		0x08
+#define SCM_FLAG_COLDBOOT_CPU3		0x20
+#define SCM_FLAG_WARMBOOT_CPU0		0x04
+#define SCM_FLAG_WARMBOOT_CPU1		0x02
 
 int scm_set_boot_addr(phys_addr_t addr, int flags);
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 09/11] ARM: msm: Add SMP support for KPSSv2

[Stephen Boyd]

From: Rohit Vaswani <rvaswani@codeaurora.org>

Implement support for the Krait CPU release sequence when the
CPUs are part of the second version of the Krait processor
subsystem.

Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
 arch/arm/mach-msm/platsmp.c | 86 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 86 insertions(+)

diff --git a/arch/arm/mach-msm/platsmp.c b/arch/arm/mach-msm/platsmp.c
index e187c6e..87e4fdc 100644
--- a/arch/arm/mach-msm/platsmp.c
+++ b/arch/arm/mach-msm/platsmp.c
@@ -32,8 +32,10 @@
 #define SCSS_DBG_STATUS_CORE_PWRDUP	0x2e64
 
 #define APCS_CPU_PWR_CTL	0x04
+#define APC_PWR_GATE_CTL	0x14
 
 #define APCS_SAW2_VCTL		0x14
+#define L2_SAW2_VCTL		0x1c
 
 extern void secondary_startup(void);
 
@@ -119,6 +121,89 @@ static int kpssv1_release_secondary(struct device_node *node, unsigned int cpu)
 	return 0;
 }
 
+static int kpssv2_release_secondary(struct device_node *node, unsigned int cpu)
+{
+	u32 off;
+	struct resource res;
+	void __iomem *reg;
+	struct device_node *l2_node;
+	void __iomem *l2_saw_base;
+	unsigned reg_val;
+	int err;
+
+	if (of_property_read_u32(node, "cpu-offset", &off))
+		return -EINVAL;
+
+	if (of_address_to_resource(node, 0, &res))
+		return -EINVAL;
+
+	l2_node = of_find_compatible_node(NULL, NULL, "qcom,l2-saw2");
+	if (!l2_node)
+		return -ENODEV;
+
+	reg = ioremap(res.start + off + (SZ_64K * cpu), resource_size(&res));
+	if (!reg) {
+		err = -ENOMEM;
+		goto err_map;
+	}
+
+	l2_saw_base = of_iomap(l2_node, 0);
+	if (!l2_saw_base) {
+		err = -ENOMEM;
+		goto err_l2_map;
+	}
+
+	/* Turn on the BHS, turn off LDO Bypass and power down LDO */
+	reg_val =  0x403f0001;
+	writel_relaxed(reg_val, reg + APC_PWR_GATE_CTL);
+
+	/* complete the above write before the delay */
+	mb();
+	/* wait for the bhs to settle */
+	udelay(1);
+
+	/* Turn on BHS segments */
+	reg_val |= 0x3f << 1;
+	writel_relaxed(reg_val, reg + APC_PWR_GATE_CTL);
+
+	/* complete the above write before the delay */
+	mb();
+	 /* wait for the bhs to settle */
+	udelay(1);
+
+	/* Finally turn on the bypass so that BHS supplies power */
+	reg_val |= 0x3f << 8;
+	writel_relaxed(reg_val, reg + APC_PWR_GATE_CTL);
+
+	/* enable max phases */
+	writel_relaxed(0x10003, l2_saw_base + L2_SAW2_VCTL);
+	mb();
+	udelay(50);
+
+	iounmap(l2_saw_base);
+
+	writel_relaxed(0x021, reg + APCS_CPU_PWR_CTL);
+	mb();
+	udelay(2);
+
+	writel_relaxed(0x020, reg + APCS_CPU_PWR_CTL);
+	mb();
+	udelay(2);
+
+	writel_relaxed(0x000, reg + APCS_CPU_PWR_CTL);
+	mb();
+
+	writel_relaxed(0x080, reg + APCS_CPU_PWR_CTL);
+	mb();
+
+	err = 0;
+err_l2_map:
+	iounmap(reg);
+err_map:
+	of_node_put(l2_node);
+	return err;
+}
+
 static DEFINE_PER_CPU(int, cold_boot_done);
 
 static int boot_cold_cpu(unsigned int cpu)
@@ -131,6 +216,7 @@ static int boot_cold_cpu(unsigned int cpu)
 	static const struct of_device_id match_table[] = {
 		M("qcom,gcc-8660", scss_release_secondary),
 		M("qcom,kpss-acc-v1", kpssv1_release_secondary),
+		M("qcom,kpss-acc-v2", kpssv2_release_secondary),
 	};
 #undef M
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 09/11] ARM: msm: Add SMP support for KPSSv2

[Stephen Boyd]

On 11/01, Janakiram Sistla wrote:
> On 1 November 2013 15:08, Stephen Boyd <sboyd@codeaurora.org> wrote:
> > +               err = -ENOMEM;
> > +               goto err_map;
> > +       }
> > +
> > +       l2_saw_base = of_iomap(l2_node, 0);
> > +       if (!l2_saw_base) {
> > +               err = -ENOMEM;
> > +               goto err_l2_map;
> > +       }
> > +
> > +       /* Turn on the BHS, turn off LDO Bypass and power down LDO */
> > +       reg_val =  0x403f0001;
> >
> I think patch looks more nice if this hard coding is defined in terms of
> macros
> 
> > +       writel_relaxed(reg_val, reg + APC_PWR_GATE_CTL);
> > +
> > +       /* complete the above write before the delay */
> > +       mb();
> > +       /* wait for the bhs to settle */
> > +       udelay(1);
> > +
> > +       /* Turn on BHS segments */
> > +       reg_val |= 0x3f << 1;
> >
> same as above
> 

Ok. I'll see what I can do.

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

[PATCH 10/11] ARM: dts: msm: Add nodes necessary for SMP boot

[Stephen Boyd]

From: Rohit Vaswani <rvaswani@codeaurora.org>

Add the necessary nodes to support SMP on MSM8960 and
MSM8974/APQ8074. While we're here also add in the error
interrupts for the krait cache error detection.

Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
[sboyd: Split into separate patch, add error interrupts]
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
 arch/arm/boot/dts/qcom-msm8960-cdp.dts | 32 ++++++++++++++++++++++
 arch/arm/boot/dts/qcom-msm8974.dtsi    | 49 ++++++++++++++++++++++++++++++++++
 2 files changed, 81 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-msm8960-cdp.dts b/arch/arm/boot/dts/qcom-msm8960-cdp.dts
index 91efaec..0621037c 100644
--- a/arch/arm/boot/dts/qcom-msm8960-cdp.dts
+++ b/arch/arm/boot/dts/qcom-msm8960-cdp.dts
@@ -9,6 +9,32 @@
 	compatible = "qcom,msm8960-cdp", "qcom,msm8960";
 	interrupt-parent = <&intc>;
 
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		interrupts = <1 14 0x304>;
+		compatible = "qcom,krait";
+		enable-method = "qcom,mmio";
+
+		cpu at 0 {
+			device_type = "cpu";
+			reg = <0>;
+			next-level-cache = <&L2>;
+		};
+
+		cpu at 1 {
+			device_type = "cpu";
+			reg = <1>;
+			next-level-cache = <&L2>;
+		};
+
+		L2: l2-cache {
+			compatible = "cache";
+			cache-level = <2>;
+			interrupts = <0 2 0x4>;
+		};
+	};
+
 	intc: interrupt-controller at 2000000 {
 		compatible = "qcom,msm-qgic2";
 		interrupt-controller;
@@ -53,6 +79,12 @@
 		#reset-cells = <1>;
 	};
 
+	clock-controller at 2008000 {
+		compatible = "qcom,kpss-acc-v1";
+		reg = <0x02008000 0x1000>;
+		cpu-offset = <0x80000>;
+	};
+
 	serial at 16440000 {
 		compatible = "qcom,msm-uartdm-v1.3", "qcom,msm-uartdm";
 		reg = <0x16440000 0x1000>,
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 152879d..0eac2ea 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -9,6 +9,44 @@
 	compatible = "qcom,msm8974";
 	interrupt-parent = <&intc>;
 
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		interrupts = <1 9 0xf04>;
+		compatible = "qcom,krait";
+		enable-method = "qcom,mmio";
+
+		cpu at 0 {
+			device_type = "cpu";
+			reg = <0>;
+			next-level-cache = <&L2>;
+		};
+
+		cpu at 1 {
+			device_type = "cpu";
+			reg = <1>;
+			next-level-cache = <&L2>;
+		};
+
+		cpu at 2 {
+			device_type = "cpu";
+			reg = <2>;
+			next-level-cache = <&L2>;
+		};
+
+		cpu at 3 {
+			device_type = "cpu";
+			reg = <3>;
+			next-level-cache = <&L2>;
+		};
+
+		L2: l2-cache {
+			compatible = "cache";
+			cache-level = <2>;
+			interrupts = <0 2 0x4>;
+		};
+	};
+
 	soc: soc {
 		#address-cells = <1>;
 		#size-cells = <1>;
@@ -91,6 +129,17 @@
 			};
 		};
 
+		regulator at f9012000 {
+			compatible = "qcom,l2-saw2", "qcom,saw2";
+			reg = <0xf9012000 0x1000>;
+		};
+
+		clock-controller at f9008000 {
+			compatible = "qcom,kpss-acc-v2";
+			reg = <0xf9008000 0x1000>;
+			cpu-offset = <0x80000>;
+		};
+
 		restart at fc4ab000 {
 			compatible = "qcom,pshold";
 			reg = <0xfc4ab000 0x4>;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 11/11] ARM: msm: Remove nr_cpus detection logic

[Stephen Boyd]

All the SMP supported MSM devices are using devicetree and they
have a cpus node in DT. Given this we know that arm generic code
detects the number of cpus from the cpus node so we can drop
support for detecting the number of CPUs from the mpidr register
here.

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
 arch/arm/mach-msm/platsmp.c | 27 ---------------------------
 1 file changed, 27 deletions(-)

diff --git a/arch/arm/mach-msm/platsmp.c b/arch/arm/mach-msm/platsmp.c
index 87e4fdc..36b2294 100644
--- a/arch/arm/mach-msm/platsmp.c
+++ b/arch/arm/mach-msm/platsmp.c
@@ -41,12 +41,6 @@ extern void secondary_startup(void);
 
 static DEFINE_SPINLOCK(boot_lock);
 
-static inline int get_core_count(void)
-{
-	/* 1 + the PART[1:0] field of MIDR */
-	return ((read_cpuid_id() >> 4) & 3) + 1;
-}
-
 static void msm_secondary_init(unsigned int cpu)
 {
 	/*
@@ -268,26 +262,6 @@ static int msm_boot_secondary(unsigned int cpu, struct task_struct *idle)
 	return 0;
 }
 
-/*
- * Initialise the CPU possible map early - this describes the CPUs
- * which may be present or become present in the system. The msm8x60
- * does not support the ARM SCU, so just set the possible cpu mask to
- * NR_CPUS.
- */
-static void __init msm_smp_init_cpus(void)
-{
-	unsigned int i, ncores = get_core_count();
-
-	if (ncores > nr_cpu_ids) {
-		pr_warn("SMP: %u cores greater than maximum (%u), clipping\n",
-			ncores, nr_cpu_ids);
-		ncores = nr_cpu_ids;
-	}
-
-	for (i = 0; i < ncores; i++)
-		set_cpu_possible(i, true);
-}
-
 static void __init msm_smp_prepare_cpus(unsigned int max_cpus)
 {
 	int cpu, map;
@@ -319,7 +293,6 @@ static void __init msm_smp_prepare_cpus(unsigned int max_cpus)
 }
 
 struct smp_operations msm_smp_ops __initdata = {
-	.smp_init_cpus		= msm_smp_init_cpus,
 	.smp_prepare_cpus	= msm_smp_prepare_cpus,
 	.smp_secondary_init	= msm_secondary_init,
 	.smp_boot_secondary	= msm_boot_secondary,
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation