| Message ID | 1396512496-8030-3-git-send-email-antoine.tenart@free-electrons.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
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.
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
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.
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
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
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
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"
Signed-off-by: Antoine Ténart <antoine.tenart@free-electrons.com> --- Documentation/devicetree/bindings/arm/cpus.txt | 2 ++ 1 file changed, 2 insertions(+)