* [PATCH 00/11] CPU enable method based SMP/hotplug + MSM conversion
@ 2013-11-01 22:08 ` Stephen Boyd
0 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-01 22:08 UTC (permalink / raw)
To: linux-arm-kernel
Cc: David Brown, Rohit Vaswani, linux-kernel, linux-arm-msm,
devicetree, Mark Rutland, Russell King
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH 00/11] CPU enable method based SMP/hotplug + MSM conversion
@ 2013-11-01 22:08 ` Stephen Boyd
0 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-01 22:08 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH 01/11] devicetree: bindings: Document cpu enable-method for ARM CPUs
2013-11-01 22:08 ` Stephen Boyd
(?)
@ 2013-11-01 22:08 ` Stephen Boyd
-1 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-01 22:08 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-arm-msm, David Brown, Rohit Vaswani, devicetree, linux-kernel
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
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH 01/11] devicetree: bindings: Document cpu enable-method for ARM CPUs
@ 2013-11-01 22:08 ` Stephen Boyd
0 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-01 22:08 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Rohit Vaswani, David Brown, linux-kernel, linux-arm-msm, devicetree
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
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH 01/11] devicetree: bindings: Document cpu enable-method for ARM CPUs
@ 2013-11-01 22:08 ` Stephen Boyd
0 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-01 22:08 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method
2013-11-01 22:08 ` Stephen Boyd
(?)
@ 2013-11-01 22:08 ` Stephen Boyd
-1 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-01 22:08 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-arm-msm, David Brown, Rohit Vaswani, devicetree, linux-kernel
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
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method
@ 2013-11-01 22:08 ` Stephen Boyd
0 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-01 22:08 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Rohit Vaswani, David Brown, linux-kernel, linux-arm-msm, devicetree
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
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method
@ 2013-11-01 22:08 ` Stephen Boyd
0 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-01 22:08 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH 03/11] devicetree: bindings: Document qcom,kpss-acc
2013-11-01 22:08 ` Stephen Boyd
(?)
@ 2013-11-01 22:08 ` Stephen Boyd
-1 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-01 22:08 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-arm-msm, David Brown, Rohit Vaswani, devicetree, linux-kernel
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@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
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH 03/11] devicetree: bindings: Document qcom,kpss-acc
@ 2013-11-01 22:08 ` Stephen Boyd
0 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-01 22:08 UTC (permalink / raw)
To: linux-arm-kernel
Cc: David Brown, Rohit Vaswani, linux-kernel, linux-arm-msm, devicetree
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@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
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH 03/11] devicetree: bindings: Document qcom,kpss-acc
@ 2013-11-01 22:08 ` Stephen Boyd
0 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-01 22:08 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH 04/11] devicetree: bindings: Document qcom,saw2 node
2013-11-01 22:08 ` Stephen Boyd
(?)
@ 2013-11-01 22:08 ` Stephen Boyd
-1 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-01 22:08 UTC (permalink / raw)
To: linux-arm-kernel
Cc: David Brown, Rohit Vaswani, linux-kernel, linux-arm-msm, devicetree
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@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
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH 04/11] devicetree: bindings: Document qcom,saw2 node
@ 2013-11-01 22:08 ` Stephen Boyd
0 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-01 22:08 UTC (permalink / raw)
To: linux-arm-kernel
Cc: David Brown, Rohit Vaswani, linux-kernel, linux-arm-msm, devicetree
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@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
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH 04/11] devicetree: bindings: Document qcom,saw2 node
@ 2013-11-01 22:08 ` Stephen Boyd
0 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-01 22:08 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH 05/11] ARM: Introduce CPU_METHOD_OF_DECLARE() for cpu hotplug/smp
2013-11-01 22:08 ` Stephen Boyd
(?)
@ 2013-11-01 22:08 ` Stephen Boyd
-1 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-01 22:08 UTC (permalink / raw)
To: linux-arm-kernel
Cc: David Brown, Rohit Vaswani, linux-kernel, linux-arm-msm,
Mark Rutland, Russell King, devicetree
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
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH 05/11] ARM: Introduce CPU_METHOD_OF_DECLARE() for cpu hotplug/smp
@ 2013-11-01 22:08 ` Stephen Boyd
0 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-01 22:08 UTC (permalink / raw)
To: linux-arm-kernel
Cc: David Brown, Rohit Vaswani, linux-kernel, linux-arm-msm,
Mark Rutland, Russell King, devicetree
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
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH 05/11] ARM: Introduce CPU_METHOD_OF_DECLARE() for cpu hotplug/smp
@ 2013-11-01 22:08 ` Stephen Boyd
0 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-01 22:08 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH 06/11] ARM: msm: Remove pen_release usage
2013-11-01 22:08 ` Stephen Boyd
@ 2013-11-01 22:08 ` Stephen Boyd
-1 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-01 22:08 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Rohit Vaswani, David Brown, linux-kernel, linux-arm-msm, Russell King
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
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH 06/11] ARM: msm: Remove pen_release usage
@ 2013-11-01 22:08 ` Stephen Boyd
0 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-01 22:08 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH 07/11] ARM: msm: Re-organize platsmp to make it extensible
2013-11-01 22:08 ` Stephen Boyd
@ 2013-11-01 22:08 ` Stephen Boyd
-1 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-01 22:08 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: Rohit Vaswani, David Brown, linux-kernel, linux-arm-msm
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@0 {
+ device_type = "cpu";
+ reg = <0>;
+ };
+
+ cpu@1 {
+ device_type = "cpu";
+ reg = <1>;
+ };
+ };
+
intc: interrupt-controller@2080000 {
compatible = "qcom,msm-8660-qgic";
interrupt-controller;
@@ -37,6 +54,13 @@
#interrupt-cells = <2>;
};
+ clock-controller@900000 {
+ compatible = "qcom,gcc-8660";
+ reg = <0x00900000 0x4000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
serial@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
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH 07/11] ARM: msm: Re-organize platsmp to make it extensible
@ 2013-11-01 22:08 ` Stephen Boyd
0 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-01 22:08 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH 08/11] ARM: msm: Add SMP support for KPSSv1
2013-11-01 22:08 ` Stephen Boyd
@ 2013-11-01 22:08 ` Stephen Boyd
-1 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-01 22:08 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: Rohit Vaswani, David Brown, linux-kernel, linux-arm-msm
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
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH 08/11] ARM: msm: Add SMP support for KPSSv1
@ 2013-11-01 22:08 ` Stephen Boyd
0 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-01 22:08 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH 09/11] ARM: msm: Add SMP support for KPSSv2
2013-11-01 22:08 ` Stephen Boyd
@ 2013-11-01 22:08 ` Stephen Boyd
-1 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-01 22:08 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: Rohit Vaswani, David Brown, linux-kernel, linux-arm-msm
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
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH 09/11] ARM: msm: Add SMP support for KPSSv2
@ 2013-11-01 22:08 ` Stephen Boyd
0 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-01 22:08 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH 10/11] ARM: dts: msm: Add nodes necessary for SMP boot
2013-11-01 22:08 ` Stephen Boyd
@ 2013-11-01 22:08 ` Stephen Boyd
-1 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-01 22:08 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: Rohit Vaswani, David Brown, linux-kernel, linux-arm-msm
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@0 {
+ device_type = "cpu";
+ reg = <0>;
+ next-level-cache = <&L2>;
+ };
+
+ cpu@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@2000000 {
compatible = "qcom,msm-qgic2";
interrupt-controller;
@@ -53,6 +79,12 @@
#reset-cells = <1>;
};
+ clock-controller@2008000 {
+ compatible = "qcom,kpss-acc-v1";
+ reg = <0x02008000 0x1000>;
+ cpu-offset = <0x80000>;
+ };
+
serial@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@0 {
+ device_type = "cpu";
+ reg = <0>;
+ next-level-cache = <&L2>;
+ };
+
+ cpu@1 {
+ device_type = "cpu";
+ reg = <1>;
+ next-level-cache = <&L2>;
+ };
+
+ cpu@2 {
+ device_type = "cpu";
+ reg = <2>;
+ next-level-cache = <&L2>;
+ };
+
+ cpu@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@f9012000 {
+ compatible = "qcom,l2-saw2", "qcom,saw2";
+ reg = <0xf9012000 0x1000>;
+ };
+
+ clock-controller@f9008000 {
+ compatible = "qcom,kpss-acc-v2";
+ reg = <0xf9008000 0x1000>;
+ cpu-offset = <0x80000>;
+ };
+
restart@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
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH 10/11] ARM: dts: msm: Add nodes necessary for SMP boot
@ 2013-11-01 22:08 ` Stephen Boyd
0 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-01 22:08 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH 11/11] ARM: msm: Remove nr_cpus detection logic
2013-11-01 22:08 ` Stephen Boyd
@ 2013-11-01 22:08 ` Stephen Boyd
-1 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-01 22:08 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: David Brown, Rohit Vaswani, linux-kernel, linux-arm-msm
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
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH 11/11] ARM: msm: Remove nr_cpus detection logic
@ 2013-11-01 22:08 ` Stephen Boyd
0 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-01 22:08 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 83+ messages in thread
* Re: [PATCH 01/11] devicetree: bindings: Document cpu enable-method for ARM CPUs
2013-11-01 22:08 ` Stephen Boyd
(?)
@ 2013-11-02 1:00 ` Rob Herring
-1 siblings, 0 replies; 83+ messages in thread
From: Rob Herring @ 2013-11-02 1:00 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-arm-kernel, linux-arm-msm, David Brown, Rohit Vaswani,
devicetree, linux-kernel
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>
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH 01/11] devicetree: bindings: Document cpu enable-method for ARM CPUs
@ 2013-11-02 1:00 ` Rob Herring
0 siblings, 0 replies; 83+ messages in thread
From: Rob Herring @ 2013-11-02 1:00 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-arm-kernel, linux-arm-msm, David Brown, Rohit Vaswani,
devicetree, linux-kernel
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>
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH 01/11] devicetree: bindings: Document cpu enable-method for ARM CPUs
@ 2013-11-02 1:00 ` Rob Herring
0 siblings, 0 replies; 83+ messages in thread
From: Rob Herring @ 2013-11-02 1:00 UTC (permalink / raw)
To: linux-arm-kernel
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>
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method
2013-11-01 22:08 ` Stephen Boyd
(?)
@ 2013-11-02 1:04 ` Rob Herring
-1 siblings, 0 replies; 83+ messages in thread
From: Rob Herring @ 2013-11-02 1:04 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-arm-kernel, linux-arm-msm, David Brown, Rohit Vaswani,
devicetree, linux-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method
@ 2013-11-02 1:04 ` Rob Herring
0 siblings, 0 replies; 83+ messages in thread
From: Rob Herring @ 2013-11-02 1:04 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-arm-kernel, linux-arm-msm, David Brown, Rohit Vaswani,
devicetree, linux-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method
@ 2013-11-02 1:04 ` Rob Herring
0 siblings, 0 replies; 83+ messages in thread
From: Rob Herring @ 2013-11-02 1:04 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method
2013-11-02 1:04 ` Rob Herring
(?)
@ 2013-11-04 17:36 ` Stephen Boyd
-1 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-04 17:36 UTC (permalink / raw)
To: Rob Herring
Cc: linux-arm-kernel, linux-arm-msm, David Brown, Rohit Vaswani,
devicetree, linux-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method
@ 2013-11-04 17:36 ` Stephen Boyd
0 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-04 17:36 UTC (permalink / raw)
To: Rob Herring
Cc: linux-arm-kernel, linux-arm-msm, David Brown, Rohit Vaswani,
devicetree, linux-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method
@ 2013-11-04 17:36 ` Stephen Boyd
0 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-04 17:36 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH 09/11] ARM: msm: Add SMP support for KPSSv2
[not found] ` <CACqS6krDt=zDWNXKTu2PvCkMXQbbf-4G2RZtuCt1deU6H2SUxQ@mail.gmail.com>
@ 2013-11-04 18:03 ` Stephen Boyd
0 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-04 18:03 UTC (permalink / raw)
To: Janakiram Sistla
Cc: linux-arm-kernel, Rohit Vaswani, David Brown, List Linux Kernel,
linux-arm-msm
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH 09/11] ARM: msm: Add SMP support for KPSSv2
@ 2013-11-04 18:03 ` Stephen Boyd
0 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-04 18:03 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method
2013-11-04 17:36 ` Stephen Boyd
(?)
@ 2013-11-05 17:12 ` Kumar Gala
-1 siblings, 0 replies; 83+ messages in thread
From: Kumar Gala @ 2013-11-05 17:12 UTC (permalink / raw)
To: Stephen Boyd
Cc: Rob Herring, linux-arm-kernel, linux-arm-msm, David Brown,
Rohit Vaswani, devicetree, linux-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method
@ 2013-11-05 17:12 ` Kumar Gala
0 siblings, 0 replies; 83+ messages in thread
From: Kumar Gala @ 2013-11-05 17:12 UTC (permalink / raw)
To: Stephen Boyd
Cc: Rob Herring, linux-arm-kernel, linux-arm-msm, David Brown,
Rohit Vaswani, devicetree, linux-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method
@ 2013-11-05 17:12 ` Kumar Gala
0 siblings, 0 replies; 83+ messages in thread
From: Kumar Gala @ 2013-11-05 17:12 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH 03/11] devicetree: bindings: Document qcom,kpss-acc
2013-11-01 22:08 ` Stephen Boyd
(?)
@ 2013-11-05 17:13 ` Kumar Gala
-1 siblings, 0 replies; 83+ messages in thread
From: Kumar Gala @ 2013-11-05 17:13 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-arm-kernel, David Brown, Rohit Vaswani, linux-kernel,
linux-arm-msm, devicetree
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@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
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH 03/11] devicetree: bindings: Document qcom,kpss-acc
@ 2013-11-05 17:13 ` Kumar Gala
0 siblings, 0 replies; 83+ messages in thread
From: Kumar Gala @ 2013-11-05 17:13 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-arm-kernel, David Brown, Rohit Vaswani, linux-kernel,
linux-arm-msm, devicetree
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@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
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH 03/11] devicetree: bindings: Document qcom,kpss-acc
@ 2013-11-05 17:13 ` Kumar Gala
0 siblings, 0 replies; 83+ messages in thread
From: Kumar Gala @ 2013-11-05 17:13 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH 04/11] devicetree: bindings: Document qcom,saw2 node
2013-11-01 22:08 ` Stephen Boyd
(?)
@ 2013-11-05 17:16 ` Kumar Gala
-1 siblings, 0 replies; 83+ messages in thread
From: Kumar Gala @ 2013-11-05 17:16 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-arm-kernel, David Brown, Rohit Vaswani, linux-kernel,
linux-arm-msm, devicetree
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@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@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
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH 04/11] devicetree: bindings: Document qcom,saw2 node
@ 2013-11-05 17:16 ` Kumar Gala
0 siblings, 0 replies; 83+ messages in thread
From: Kumar Gala @ 2013-11-05 17:16 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-arm-kernel, David Brown, Rohit Vaswani, linux-kernel,
linux-arm-msm, devicetree
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@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@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
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH 04/11] devicetree: bindings: Document qcom,saw2 node
@ 2013-11-05 17:16 ` Kumar Gala
0 siblings, 0 replies; 83+ messages in thread
From: Kumar Gala @ 2013-11-05 17:16 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH 05/11] ARM: Introduce CPU_METHOD_OF_DECLARE() for cpu hotplug/smp
2013-11-01 22:08 ` Stephen Boyd
(?)
@ 2013-11-05 17:24 ` Kumar Gala
-1 siblings, 0 replies; 83+ messages in thread
From: Kumar Gala @ 2013-11-05 17:24 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-arm-kernel, David Brown, Rohit Vaswani, linux-kernel,
linux-arm-msm, Mark Rutland, Russell King, devicetree
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH 05/11] ARM: Introduce CPU_METHOD_OF_DECLARE() for cpu hotplug/smp
@ 2013-11-05 17:24 ` Kumar Gala
0 siblings, 0 replies; 83+ messages in thread
From: Kumar Gala @ 2013-11-05 17:24 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-arm-kernel, David Brown, Rohit Vaswani, linux-kernel,
linux-arm-msm, Mark Rutland, Russell King, devicetree
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH 05/11] ARM: Introduce CPU_METHOD_OF_DECLARE() for cpu hotplug/smp
@ 2013-11-05 17:24 ` Kumar Gala
0 siblings, 0 replies; 83+ messages in thread
From: Kumar Gala @ 2013-11-05 17:24 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH 05/11] ARM: Introduce CPU_METHOD_OF_DECLARE() for cpu hotplug/smp
2013-11-05 17:24 ` Kumar Gala
@ 2013-11-05 17:27 ` Stephen Boyd
-1 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-05 17:27 UTC (permalink / raw)
To: Kumar Gala
Cc: linux-arm-kernel, David Brown, Rohit Vaswani, linux-kernel,
linux-arm-msm, Mark Rutland, Russell King, devicetree
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH 05/11] ARM: Introduce CPU_METHOD_OF_DECLARE() for cpu hotplug/smp
@ 2013-11-05 17:27 ` Stephen Boyd
0 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-05 17:27 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH 07/11] ARM: msm: Re-organize platsmp to make it extensible
2013-11-01 22:08 ` Stephen Boyd
@ 2013-11-05 17:32 ` Kumar Gala
-1 siblings, 0 replies; 83+ messages in thread
From: Kumar Gala @ 2013-11-05 17:32 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-arm-kernel, Rohit Vaswani, David Brown, linux-kernel,
linux-arm-msm
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@0 {
> + device_type = "cpu";
> + reg = <0>;
> + };
> +
> + cpu@1 {
> + device_type = "cpu";
> + reg = <1>;
> + };
> + };
> +
> intc: interrupt-controller@2080000 {
> compatible = "qcom,msm-8660-qgic";
> interrupt-controller;
> @@ -37,6 +54,13 @@
> #interrupt-cells = <2>;
> };
>
> + clock-controller@900000 {
> + compatible = "qcom,gcc-8660";
> + reg = <0x00900000 0x4000>;
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
> +
> serial@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@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
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH 07/11] ARM: msm: Re-organize platsmp to make it extensible
@ 2013-11-05 17:32 ` Kumar Gala
0 siblings, 0 replies; 83+ messages in thread
From: Kumar Gala @ 2013-11-05 17:32 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method
2013-11-05 17:12 ` Kumar Gala
(?)
@ 2013-11-05 17:35 ` Stephen Boyd
-1 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-05 17:35 UTC (permalink / raw)
To: Kumar Gala
Cc: Rob Herring, linux-arm-kernel, linux-arm-msm, David Brown,
Rohit Vaswani, devicetree, linux-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method
@ 2013-11-05 17:35 ` Stephen Boyd
0 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-05 17:35 UTC (permalink / raw)
To: Kumar Gala
Cc: Rob Herring, linux-arm-kernel, linux-arm-msm, David Brown,
Rohit Vaswani, devicetree, linux-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method
@ 2013-11-05 17:35 ` Stephen Boyd
0 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-05 17:35 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method
2013-11-05 17:35 ` Stephen Boyd
(?)
@ 2013-11-05 17:43 ` Kumar Gala
-1 siblings, 0 replies; 83+ messages in thread
From: Kumar Gala @ 2013-11-05 17:43 UTC (permalink / raw)
To: Stephen Boyd
Cc: Rob Herring, linux-arm-kernel, linux-arm-msm, David Brown,
Rohit Vaswani, devicetree, linux-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method
@ 2013-11-05 17:43 ` Kumar Gala
0 siblings, 0 replies; 83+ messages in thread
From: Kumar Gala @ 2013-11-05 17:43 UTC (permalink / raw)
To: Stephen Boyd
Cc: Rob Herring, linux-arm-kernel, linux-arm-msm, David Brown,
Rohit Vaswani, devicetree, linux-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method
@ 2013-11-05 17:43 ` Kumar Gala
0 siblings, 0 replies; 83+ messages in thread
From: Kumar Gala @ 2013-11-05 17:43 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH 03/11] devicetree: bindings: Document qcom,kpss-acc
2013-11-05 17:13 ` Kumar Gala
@ 2013-11-05 17:44 ` Stephen Boyd
-1 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-05 17:44 UTC (permalink / raw)
To: Kumar Gala
Cc: linux-arm-kernel, David Brown, Rohit Vaswani, linux-kernel,
linux-arm-msm, devicetree
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@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
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH 03/11] devicetree: bindings: Document qcom,kpss-acc
@ 2013-11-05 17:44 ` Stephen Boyd
0 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-05 17:44 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method
2013-11-05 17:43 ` Kumar Gala
(?)
@ 2013-11-05 17:46 ` Stephen Boyd
-1 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-05 17:46 UTC (permalink / raw)
To: Kumar Gala
Cc: Rob Herring, linux-arm-kernel, linux-arm-msm, David Brown,
Rohit Vaswani, devicetree, linux-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method
@ 2013-11-05 17:46 ` Stephen Boyd
0 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-05 17:46 UTC (permalink / raw)
To: Kumar Gala
Cc: Rob Herring, linux-arm-kernel, linux-arm-msm, David Brown,
Rohit Vaswani, devicetree, linux-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method
@ 2013-11-05 17:46 ` Stephen Boyd
0 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-05 17:46 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH 03/11] devicetree: bindings: Document qcom,kpss-acc
2013-11-05 17:44 ` Stephen Boyd
@ 2013-11-05 17:51 ` Kumar Gala
-1 siblings, 0 replies; 83+ messages in thread
From: Kumar Gala @ 2013-11-05 17:51 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-arm-kernel, David Brown, Rohit Vaswani, linux-kernel,
linux-arm-msm, devicetree
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@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
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH 03/11] devicetree: bindings: Document qcom,kpss-acc
@ 2013-11-05 17:51 ` Kumar Gala
0 siblings, 0 replies; 83+ messages in thread
From: Kumar Gala @ 2013-11-05 17:51 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method
2013-11-05 17:46 ` Stephen Boyd
(?)
@ 2013-11-05 18:12 ` Kumar Gala
-1 siblings, 0 replies; 83+ messages in thread
From: Kumar Gala @ 2013-11-05 18:12 UTC (permalink / raw)
To: Stephen Boyd
Cc: Rob Herring, linux-arm-kernel, linux-arm-msm, David Brown,
Rohit Vaswani, devicetree, linux-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method
@ 2013-11-05 18:12 ` Kumar Gala
0 siblings, 0 replies; 83+ messages in thread
From: Kumar Gala @ 2013-11-05 18:12 UTC (permalink / raw)
To: Stephen Boyd
Cc: Rob Herring, linux-arm-kernel, linux-arm-msm, David Brown,
Rohit Vaswani, devicetree, linux-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method
@ 2013-11-05 18:12 ` Kumar Gala
0 siblings, 0 replies; 83+ messages in thread
From: Kumar Gala @ 2013-11-05 18:12 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH 05/11] ARM: Introduce CPU_METHOD_OF_DECLARE() for cpu hotplug/smp
2013-11-01 22:08 ` Stephen Boyd
(?)
@ 2013-11-07 1:50 ` Josh Cartwright
-1 siblings, 0 replies; 83+ messages in thread
From: Josh Cartwright @ 2013-11-07 1:50 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, Rohit Vaswani,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, David Brown
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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH 05/11] ARM: Introduce CPU_METHOD_OF_DECLARE() for cpu hotplug/smp
@ 2013-11-07 1:50 ` Josh Cartwright
0 siblings, 0 replies; 83+ messages in thread
From: Josh Cartwright @ 2013-11-07 1:50 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-arm-kernel, Mark Rutland, devicetree, Russell King,
linux-arm-msm, Rohit Vaswani, linux-kernel, David Brown
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH 05/11] ARM: Introduce CPU_METHOD_OF_DECLARE() for cpu hotplug/smp
@ 2013-11-07 1:50 ` Josh Cartwright
0 siblings, 0 replies; 83+ messages in thread
From: Josh Cartwright @ 2013-11-07 1:50 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH 05/11] ARM: Introduce CPU_METHOD_OF_DECLARE() for cpu hotplug/smp
2013-11-07 1:50 ` Josh Cartwright
@ 2013-11-07 22:34 ` Stephen Boyd
-1 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-07 22:34 UTC (permalink / raw)
To: Josh Cartwright
Cc: linux-arm-kernel, Mark Rutland, devicetree, Russell King,
linux-arm-msm, Rohit Vaswani, linux-kernel, David Brown
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH 05/11] ARM: Introduce CPU_METHOD_OF_DECLARE() for cpu hotplug/smp
@ 2013-11-07 22:34 ` Stephen Boyd
0 siblings, 0 replies; 83+ messages in thread
From: Stephen Boyd @ 2013-11-07 22:34 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH 03/11] devicetree: bindings: Document qcom,kpss-acc
2013-11-05 17:51 ` Kumar Gala
@ 2013-11-08 9:10 ` Tomasz Figa
-1 siblings, 0 replies; 83+ messages in thread
From: Tomasz Figa @ 2013-11-08 9:10 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Kumar Gala, Stephen Boyd, devicetree, linux-arm-msm,
Rohit Vaswani, linux-kernel, David Brown
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@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
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH 03/11] devicetree: bindings: Document qcom,kpss-acc
@ 2013-11-08 9:10 ` Tomasz Figa
0 siblings, 0 replies; 83+ messages in thread
From: Tomasz Figa @ 2013-11-08 9:10 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH 01/11] devicetree: bindings: Document cpu enable-method for ARM CPUs
2013-11-01 22:08 ` Stephen Boyd
@ 2013-11-08 9:12 ` Tomasz Figa
-1 siblings, 0 replies; 83+ messages in thread
From: Tomasz Figa @ 2013-11-08 9:12 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Stephen Boyd, linux-arm-msm, David Brown, Rohit Vaswani,
devicetree, linux-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH 01/11] devicetree: bindings: Document cpu enable-method for ARM CPUs
@ 2013-11-08 9:12 ` Tomasz Figa
0 siblings, 0 replies; 83+ messages in thread
From: Tomasz Figa @ 2013-11-08 9:12 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH 03/11] devicetree: bindings: Document qcom,kpss-acc
2013-11-08 9:10 ` Tomasz Figa
@ 2013-11-08 14:30 ` Kumar Gala
-1 siblings, 0 replies; 83+ messages in thread
From: Kumar Gala @ 2013-11-08 14:30 UTC (permalink / raw)
To: Tomasz Figa
Cc: linux-arm-kernel, Stephen Boyd, devicetree, linux-arm-msm,
Rohit Vaswani, linux-kernel, David Brown
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@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
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH 03/11] devicetree: bindings: Document qcom,kpss-acc
@ 2013-11-08 14:30 ` Kumar Gala
0 siblings, 0 replies; 83+ messages in thread
From: Kumar Gala @ 2013-11-08 14:30 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 83+ messages in thread
end of thread, other threads:[~2013-11-08 14:30 UTC | newest]
Thread overview: 83+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-11-01 22:08 [PATCH 00/11] CPU enable method based SMP/hotplug + MSM conversion Stephen Boyd
2013-11-01 22:08 ` Stephen Boyd
2013-11-01 22:08 ` [PATCH 01/11] devicetree: bindings: Document cpu enable-method for ARM CPUs Stephen Boyd
2013-11-01 22:08 ` Stephen Boyd
2013-11-01 22:08 ` Stephen Boyd
2013-11-02 1:00 ` Rob Herring
2013-11-02 1:00 ` Rob Herring
2013-11-02 1:00 ` Rob Herring
2013-11-08 9:12 ` Tomasz Figa
2013-11-08 9:12 ` Tomasz Figa
2013-11-01 22:08 ` [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method Stephen Boyd
2013-11-01 22:08 ` Stephen Boyd
2013-11-01 22:08 ` Stephen Boyd
2013-11-02 1:04 ` Rob Herring
2013-11-02 1:04 ` Rob Herring
2013-11-02 1:04 ` Rob Herring
2013-11-04 17:36 ` Stephen Boyd
2013-11-04 17:36 ` Stephen Boyd
2013-11-04 17:36 ` Stephen Boyd
2013-11-05 17:12 ` Kumar Gala
2013-11-05 17:12 ` Kumar Gala
2013-11-05 17:12 ` Kumar Gala
2013-11-05 17:35 ` Stephen Boyd
2013-11-05 17:35 ` Stephen Boyd
2013-11-05 17:35 ` Stephen Boyd
2013-11-05 17:43 ` Kumar Gala
2013-11-05 17:43 ` Kumar Gala
2013-11-05 17:43 ` Kumar Gala
2013-11-05 17:46 ` Stephen Boyd
2013-11-05 17:46 ` Stephen Boyd
2013-11-05 17:46 ` Stephen Boyd
2013-11-05 18:12 ` Kumar Gala
2013-11-05 18:12 ` Kumar Gala
2013-11-05 18:12 ` Kumar Gala
2013-11-01 22:08 ` [PATCH 03/11] devicetree: bindings: Document qcom,kpss-acc Stephen Boyd
2013-11-01 22:08 ` Stephen Boyd
2013-11-01 22:08 ` Stephen Boyd
2013-11-05 17:13 ` Kumar Gala
2013-11-05 17:13 ` Kumar Gala
2013-11-05 17:13 ` Kumar Gala
2013-11-05 17:44 ` Stephen Boyd
2013-11-05 17:44 ` Stephen Boyd
2013-11-05 17:51 ` Kumar Gala
2013-11-05 17:51 ` Kumar Gala
2013-11-08 9:10 ` Tomasz Figa
2013-11-08 9:10 ` Tomasz Figa
2013-11-08 14:30 ` Kumar Gala
2013-11-08 14:30 ` Kumar Gala
2013-11-01 22:08 ` [PATCH 04/11] devicetree: bindings: Document qcom,saw2 node Stephen Boyd
2013-11-01 22:08 ` Stephen Boyd
2013-11-01 22:08 ` Stephen Boyd
2013-11-05 17:16 ` Kumar Gala
2013-11-05 17:16 ` Kumar Gala
2013-11-05 17:16 ` Kumar Gala
2013-11-01 22:08 ` [PATCH 05/11] ARM: Introduce CPU_METHOD_OF_DECLARE() for cpu hotplug/smp Stephen Boyd
2013-11-01 22:08 ` Stephen Boyd
2013-11-01 22:08 ` Stephen Boyd
2013-11-05 17:24 ` Kumar Gala
2013-11-05 17:24 ` Kumar Gala
2013-11-05 17:24 ` Kumar Gala
2013-11-05 17:27 ` Stephen Boyd
2013-11-05 17:27 ` Stephen Boyd
[not found] ` <1383343739-23080-6-git-send-email-sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2013-11-07 1:50 ` Josh Cartwright
2013-11-07 1:50 ` Josh Cartwright
2013-11-07 1:50 ` Josh Cartwright
2013-11-07 22:34 ` Stephen Boyd
2013-11-07 22:34 ` Stephen Boyd
2013-11-01 22:08 ` [PATCH 06/11] ARM: msm: Remove pen_release usage Stephen Boyd
2013-11-01 22:08 ` Stephen Boyd
2013-11-01 22:08 ` [PATCH 07/11] ARM: msm: Re-organize platsmp to make it extensible Stephen Boyd
2013-11-01 22:08 ` Stephen Boyd
2013-11-05 17:32 ` Kumar Gala
2013-11-05 17:32 ` Kumar Gala
2013-11-01 22:08 ` [PATCH 08/11] ARM: msm: Add SMP support for KPSSv1 Stephen Boyd
2013-11-01 22:08 ` Stephen Boyd
2013-11-01 22:08 ` [PATCH 09/11] ARM: msm: Add SMP support for KPSSv2 Stephen Boyd
2013-11-01 22:08 ` Stephen Boyd
[not found] ` <CACqS6krDt=zDWNXKTu2PvCkMXQbbf-4G2RZtuCt1deU6H2SUxQ@mail.gmail.com>
2013-11-04 18:03 ` Stephen Boyd
2013-11-04 18:03 ` Stephen Boyd
2013-11-01 22:08 ` [PATCH 10/11] ARM: dts: msm: Add nodes necessary for SMP boot Stephen Boyd
2013-11-01 22:08 ` Stephen Boyd
2013-11-01 22:08 ` [PATCH 11/11] ARM: msm: Remove nr_cpus detection logic Stephen Boyd
2013-11-01 22:08 ` Stephen Boyd
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.