The newly introduced CPU_METHOD_OF_DECLARE (6c3ff8b11a16) [1] allows to
get rid of the board file reference to smp ops. This serie converts the
Berlin SoC smp to use this and allows to set the enable-method in the
device tree.
This serie applies on top of Sebastian's topic/smp-bg3-bg2q branch [2]
rebased on top of linux-next.
Tested on the Berlin BG2Q.
[1] https://patchwork.kernel.org/patch/3399311/
[2] https://github.com/shesselba/linux-berlin/tree/topic/smp-bg2-bg2q
Antoine Ténart (3):
ARM: berlin: use CPU_METHOD_OF_DECLARE for smp
ARM: dts: document the berlin enable-method property
ARM: dts: berlin: add enable-method property in cpus node for smp
Documentation/devicetree/bindings/arm/cpus.txt | 2 ++
arch/arm/boot/dts/berlin2.dtsi | 1 +
arch/arm/boot/dts/berlin2q.dtsi | 1 +
arch/arm/mach-berlin/berlin.c | 1 -
arch/arm/mach-berlin/common.h | 2 --
arch/arm/mach-berlin/platsmp.c | 3 ++-
6 files changed, 6 insertions(+), 4 deletions(-)
--
1.8.3.2
Signed-off-by: Antoine Ténart <[email protected]>
---
Documentation/devicetree/bindings/arm/cpus.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
index 333f4aea3029..a9e42a2dbc99 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -185,6 +185,8 @@ nodes to be present and contain the properties described below.
"qcom,gcc-msm8660"
"qcom,kpss-acc-v1"
"qcom,kpss-acc-v2"
+ "marvell,88de31-smp" - cpu-core handling for Berlin
+ SoC from Marvell starting with 88de31
- cpu-release-addr
Usage: required for systems that have an "enable-method"
--
1.8.3.2
Get rid of the smp ops in the machine descriptor and select the cpu
enable method in the device tree.
Signed-off-by: Antoine Ténart <[email protected]>
---
arch/arm/mach-berlin/berlin.c | 1 -
arch/arm/mach-berlin/common.h | 2 --
arch/arm/mach-berlin/platsmp.c | 3 ++-
3 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-berlin/berlin.c b/arch/arm/mach-berlin/berlin.c
index 1bbca793174d..3cc3e706719e 100644
--- a/arch/arm/mach-berlin/berlin.c
+++ b/arch/arm/mach-berlin/berlin.c
@@ -38,5 +38,4 @@ static const char * const berlin_dt_compat[] = {
DT_MACHINE_START(BERLIN_DT, "Marvell Berlin")
.dt_compat = berlin_dt_compat,
.init_machine = berlin_init_machine,
- .smp = smp_ops(berlin_smp_ops),
MACHINE_END
diff --git a/arch/arm/mach-berlin/common.h b/arch/arm/mach-berlin/common.h
index 57c97669af0a..8d585e2481f9 100644
--- a/arch/arm/mach-berlin/common.h
+++ b/arch/arm/mach-berlin/common.h
@@ -13,6 +13,4 @@
extern void berlin_secondary_startup(void);
-extern struct smp_operations berlin_smp_ops;
-
#endif
diff --git a/arch/arm/mach-berlin/platsmp.c b/arch/arm/mach-berlin/platsmp.c
index 5c83941b0918..86fe697577fd 100644
--- a/arch/arm/mach-berlin/platsmp.c
+++ b/arch/arm/mach-berlin/platsmp.c
@@ -132,8 +132,9 @@ static void __init berlin_smp_prepare_cpus(unsigned int max_cpus)
iounmap(gpr_base);
}
-struct smp_operations berlin_smp_ops __initdata = {
+static struct smp_operations berlin_smp_ops __initdata = {
.smp_prepare_cpus = berlin_smp_prepare_cpus,
.smp_secondary_init = berlin_secondary_init,
.smp_boot_secondary = berlin_boot_secondary,
};
+CPU_METHOD_OF_DECLARE(berlin_smp, "marvell,88de31-smp", &berlin_smp_ops);
--
1.8.3.2
Signed-off-by: Antoine Ténart <[email protected]>
---
arch/arm/boot/dts/berlin2.dtsi | 1 +
arch/arm/boot/dts/berlin2q.dtsi | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/berlin2.dtsi b/arch/arm/boot/dts/berlin2.dtsi
index 4d85312dc17a..596f6bd07677 100644
--- a/arch/arm/boot/dts/berlin2.dtsi
+++ b/arch/arm/boot/dts/berlin2.dtsi
@@ -21,6 +21,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "marvell,88de31-smp";
cpu@0 {
compatible = "marvell,pj4b";
diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
index 86d8a2c49f38..5e8161aa21a3 100644
--- a/arch/arm/boot/dts/berlin2q.dtsi
+++ b/arch/arm/boot/dts/berlin2q.dtsi
@@ -17,6 +17,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "marvell,88de31-smp";
cpu@0 {
compatible = "arm,cortex-a9";
--
1.8.3.2
Hi,
On Thu, 3 Apr 2014 01:08:15 -0700
Antoine Ténart <[email protected]> wrote:
> Signed-off-by: Antoine Ténart <[email protected]>
> ---
> Documentation/devicetree/bindings/arm/cpus.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
> b/Documentation/devicetree/bindings/arm/cpus.txt index
> 333f4aea3029..a9e42a2dbc99 100644 ---
> a/Documentation/devicetree/bindings/arm/cpus.txt +++
> b/Documentation/devicetree/bindings/arm/cpus.txt @@ -185,6 +185,8 @@ nodes
> to be present and contain the properties described below. "qcom,gcc-msm8660"
> "qcom,kpss-acc-v1"
> "qcom,kpss-acc-v2"
> + "marvell,88de31-smp" - cpu-core handling for
why not "marvell,berlin-smp"?
Thanks
On 03/04/2014 at 10:08:15 +0200, Antoine T?nart wrote :
Please write a quick commit message.
> Signed-off-by: Antoine T?nart <[email protected]>
> ---
> Documentation/devicetree/bindings/arm/cpus.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
> index 333f4aea3029..a9e42a2dbc99 100644
> --- a/Documentation/devicetree/bindings/arm/cpus.txt
> +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> @@ -185,6 +185,8 @@ nodes to be present and contain the properties described below.
> "qcom,gcc-msm8660"
> "qcom,kpss-acc-v1"
> "qcom,kpss-acc-v2"
> + "marvell,88de31-smp" - cpu-core handling for Berlin
> + SoC from Marvell starting with 88de31
I would also go for something else, marvell,88de31xx-smp or marvell,berlin-smp.
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
Jisheng,
On 03/04/2014 10:22, Jisheng Zhang wrote:
> Hi,
>
> On Thu, 3 Apr 2014 01:08:15 -0700
> Antoine Ténart <[email protected]> wrote:
>
>> Signed-off-by: Antoine Ténart <[email protected]>
>> ---
>> Documentation/devicetree/bindings/arm/cpus.txt | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
>> b/Documentation/devicetree/bindings/arm/cpus.txt index
>> 333f4aea3029..a9e42a2dbc99 100644 ---
>> a/Documentation/devicetree/bindings/arm/cpus.txt +++
>> b/Documentation/devicetree/bindings/arm/cpus.txt @@ -185,6 +185,8 @@ nodes
>> to be present and contain the properties described below. "qcom,gcc-msm8660"
>> "qcom,kpss-acc-v1"
>> "qcom,kpss-acc-v2"
>> + "marvell,88de31-smp" - cpu-core handling for
>
> why not "marvell,berlin-smp"?
We have SMP on the BG2 and the BG2Q currently. Future boards may not be
compatible with this method (BG3 ?), I think "marvell,berlin-smp" is too
generic.
We could use "marvell,88de31xx-smp" as Alexandre suggested.
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
On Thu, Apr 03, 2014 at 09:08:15AM +0100, Antoine Ténart wrote:
> Signed-off-by: Antoine Ténart <[email protected]>
> ---
> Documentation/devicetree/bindings/arm/cpus.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
> index 333f4aea3029..a9e42a2dbc99 100644
> --- a/Documentation/devicetree/bindings/arm/cpus.txt
> +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> @@ -185,6 +185,8 @@ nodes to be present and contain the properties described below.
> "qcom,gcc-msm8660"
> "qcom,kpss-acc-v1"
> "qcom,kpss-acc-v2"
> + "marvell,88de31-smp" - cpu-core handling for Berlin
> + SoC from Marvell starting with 88de31
It would probably be best to add an enable-method directory and document
what each of these mean (what's expected of the platform, what steps an
OS should make to bring up and/or tear down CPUs).
While it's nice to factor this out of the kernel, I'd like this to be
better-defined such that it's clear what the expectations of each
enable-method are. That ways it iss possible for OSs other than Linux to
make use of the enable-method information (as it won't be an opaque
reference to Linux internals), and we can have a clear definition of
each enable-method independent of any implementation details.
Going forward I would like to see fewer implementation-specific
protocols for bringing up secondaries, and a move to fewer more
standardised mechanisms like PSCI. I realise that might not be possible
in all cases, but it would be nice to avoid a proliferation of
enable-methods with single users.
Cheers,
Mark.
On 03/04/2014 10:54, Antoine Ténart wrote:
> Jisheng,
>
> On 03/04/2014 10:22, Jisheng Zhang wrote:
>> Hi,
>>
>> On Thu, 3 Apr 2014 01:08:15 -0700
>> Antoine Ténart <[email protected]> wrote:
>>
>>> Signed-off-by: Antoine Ténart <[email protected]>
>>> ---
>>> Documentation/devicetree/bindings/arm/cpus.txt | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
>>> b/Documentation/devicetree/bindings/arm/cpus.txt index
>>> 333f4aea3029..a9e42a2dbc99 100644 ---
>>> a/Documentation/devicetree/bindings/arm/cpus.txt +++
>>> b/Documentation/devicetree/bindings/arm/cpus.txt @@ -185,6 +185,8 @@
>>> nodes
>>> to be present and contain the properties described below.
>>> "qcom,gcc-msm8660"
>>> "qcom,kpss-acc-v1"
>>> "qcom,kpss-acc-v2"
>>> + "marvell,88de31-smp" - cpu-core handling for
>>
>> why not "marvell,berlin-smp"?
>
> We have SMP on the BG2 and the BG2Q currently. Future boards may not be
> compatible with this method (BG3 ?), I think "marvell,berlin-smp" is too
> generic.
>
> We could use "marvell,88de31xx-smp" as Alexandre suggested.
"marvell,88de31xx-smp" is not a good choice too, since futur SoC may
match the "xx" and not use this method. A better way should be to use
the first SoC implementing the feature, so "marvell,88de3100".
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
Hi Antoine,
On Thu, 3 Apr 2014 01:54:07 -0700
Antoine Ténart <[email protected]> wrote:
> Jisheng,
>
> On 03/04/2014 10:22, Jisheng Zhang wrote:
> > Hi,
> >
> > On Thu, 3 Apr 2014 01:08:15 -0700
> > Antoine Ténart <[email protected]> wrote:
> >
> >> Signed-off-by: Antoine Ténart <[email protected]>
> >> ---
> >> Documentation/devicetree/bindings/arm/cpus.txt | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
> >> b/Documentation/devicetree/bindings/arm/cpus.txt index
> >> 333f4aea3029..a9e42a2dbc99 100644 ---
> >> a/Documentation/devicetree/bindings/arm/cpus.txt +++
> >> b/Documentation/devicetree/bindings/arm/cpus.txt @@ -185,6 +185,8 @@
> >> nodes to be present and contain the properties described below.
> >> "qcom,gcc-msm8660" "qcom,kpss-acc-v1"
> >> "qcom,kpss-acc-v2"
> >> + "marvell,88de31-smp" - cpu-core handling for
> >
> > why not "marvell,berlin-smp"?
>
> We have SMP on the BG2 and the BG2Q currently. Future boards may not be
> compatible with this method (BG3 ?), I think "marvell,berlin-smp" is too
Yes. It's not compatible. But it will be PSCI. FWICT, current smp method
would be only used for BG2/BG2CT.
Thanks
On 04/03/2014 09:14 AM, Antoine Ténart wrote:
> On 03/04/2014 10:54, Antoine Ténart wrote:
>> On 03/04/2014 10:22, Jisheng Zhang wrote:
>>> On Thu, 3 Apr 2014 01:08:15 -0700
>>> Antoine Ténart <[email protected]> wrote:
>>>
>>>> Signed-off-by: Antoine Ténart <[email protected]>
>>>> ---
>>>> Documentation/devicetree/bindings/arm/cpus.txt | 2 ++
>>>> 1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
>>>> b/Documentation/devicetree/bindings/arm/cpus.txt index
>>>> 333f4aea3029..a9e42a2dbc99 100644 ---
>>>> a/Documentation/devicetree/bindings/arm/cpus.txt +++
>>>> b/Documentation/devicetree/bindings/arm/cpus.txt @@ -185,6 +185,8 @@
>>>> nodes
>>>> to be present and contain the properties described below.
>>>> "qcom,gcc-msm8660"
>>>> "qcom,kpss-acc-v1"
>>>> "qcom,kpss-acc-v2"
>>>> + "marvell,88de31-smp" - cpu-core handling for
>>>
>>> why not "marvell,berlin-smp"?
>>
>> We have SMP on the BG2 and the BG2Q currently. Future boards may not be
>> compatible with this method (BG3 ?), I think "marvell,berlin-smp" is too
>> generic.
>>
>> We could use "marvell,88de31xx-smp" as Alexandre suggested.
>
> "marvell,88de31xx-smp" is not a good choice too, since futur SoC may
> match the "xx" and not use this method. A better way should be to use
> the first SoC implementing the feature, so "marvell,88de3100".
Never introduce the SoC numbers, we have chosen to stick with
berlin2{,cd,q} so use that.
Given the comment from Mark Rutland and Russell King here[1], I'd rather
concentrate on a proper SMP implementation. Unfortunately, I haven't
found a good documentation about the requirements nor call sequence -
but I haven't looked hard.
Having said that, can we postpone the DT enable method patches until
we agreed on a better SMP implementation?
Sebastian
[1] http://www.spinics.net/lists/arm-kernel/msg318585.html