diff mbox

[2/3] ARM: dts: document the berlin enable-method property

Message ID 1396512496-8030-3-git-send-email-antoine.tenart@free-electrons.com
State Superseded, archived
Headers show

Commit Message

Antoine Tenart April 3, 2014, 8:08 a.m. UTC
Signed-off-by: Antoine Ténart <antoine.tenart@free-electrons.com>
---
 Documentation/devicetree/bindings/arm/cpus.txt | 2 ++
 1 file changed, 2 insertions(+)

Comments

Jisheng Zhang April 3, 2014, 8:22 a.m. UTC | #1
Hi,

On Thu, 3 Apr 2014 01:08:15 -0700
Antoine Ténart <antoine.tenart@free-electrons.com> wrote:

> Signed-off-by: Antoine Ténart <antoine.tenart@free-electrons.com>
> ---
>  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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Alexandre Belloni April 3, 2014, 8:29 a.m. UTC | #2
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 <antoine.tenart@free-electrons.com>
> ---
>  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.
Antoine Tenart April 3, 2014, 8:54 a.m. UTC | #3
Jisheng,

On 03/04/2014 10:22, Jisheng Zhang wrote:
> Hi,
>
> On Thu, 3 Apr 2014 01:08:15 -0700
> Antoine Ténart <antoine.tenart@free-electrons.com> wrote:
>
>> Signed-off-by: Antoine Ténart <antoine.tenart@free-electrons.com>
>> ---
>>   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
Mark Rutland April 3, 2014, 9:02 a.m. UTC | #4
On Thu, Apr 03, 2014 at 09:08:15AM +0100, Antoine Ténart wrote:
> Signed-off-by: Antoine Ténart <antoine.tenart@free-electrons.com>
> ---
>  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.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jisheng Zhang April 3, 2014, 9:14 a.m. UTC | #5
Hi Antoine,

On Thu, 3 Apr 2014 01:54:07 -0700
Antoine Ténart <antoine.tenart@free-electrons.com> wrote:

> Jisheng,
> 
> On 03/04/2014 10:22, Jisheng Zhang wrote:
> > Hi,
> >
> > On Thu, 3 Apr 2014 01:08:15 -0700
> > Antoine Ténart <antoine.tenart@free-electrons.com> wrote:
> >
> >> Signed-off-by: Antoine Ténart <antoine.tenart@free-electrons.com>
> >> ---
> >>   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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Antoine Tenart April 3, 2014, 9:14 a.m. UTC | #6
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 <antoine.tenart@free-electrons.com> wrote:
>>
>>> Signed-off-by: Antoine Ténart <antoine.tenart@free-electrons.com>
>>> ---
>>>   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
Sebastian Hesselbarth April 3, 2014, 9:40 a.m. UTC | #7
On 04/03/2014 09:14 AM, Antoine Ténart wrote:
> On 03/04/2014 10:54, Antoine Ténart wrote:
>> On 03/04/2014 10:22, Jisheng Zhang wrote:
>>> On Thu, 3 Apr 2014 01:08:15 -0700
>>> Antoine Ténart <antoine.tenart@free-electrons.com> wrote:
>>>
>>>> Signed-off-by: Antoine Ténart <antoine.tenart@free-electrons.com>
>>>> ---
>>>>   Documentation/devicetree/bindings/arm/cpus.txt | 2 ++
>>>>   1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
>>>> b/Documentation/devicetree/bindings/arm/cpus.txt index
>>>> 333f4aea3029..a9e42a2dbc99 100644 ---
>>>> a/Documentation/devicetree/bindings/arm/cpus.txt +++
>>>> b/Documentation/devicetree/bindings/arm/cpus.txt @@ -185,6 +185,8 @@
>>>> nodes
>>>> to be present and contain the properties described below.
>>>> "qcom,gcc-msm8660"
>>>>                   "qcom,kpss-acc-v1"
>>>>                   "qcom,kpss-acc-v2"
>>>> +                "marvell,88de31-smp" - cpu-core handling for
>>>
>>> why not "marvell,berlin-smp"?
>>
>> We have SMP on the BG2 and the BG2Q currently. Future boards may not be
>> compatible with this method (BG3 ?), I think "marvell,berlin-smp" is too
>> generic.
>>
>> We could use "marvell,88de31xx-smp" as Alexandre suggested.
>
> "marvell,88de31xx-smp" is not a good choice too, since futur SoC may
> match the "xx" and not use this method. A better way should be to use
> the first SoC implementing the feature, so "marvell,88de3100".

Never introduce the SoC numbers, we have chosen to stick with
berlin2{,cd,q} so use that.

Given the comment from Mark Rutland and Russell King here[1], I'd rather
concentrate on a proper SMP implementation. Unfortunately, I haven't
found a good documentation about the requirements nor call sequence -
but I haven't looked hard.

Having said that, can we postpone the DT enable method patches until
we agreed on a better SMP implementation?

Sebastian

[1] http://www.spinics.net/lists/arm-kernel/msg318585.html

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

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"