| Message ID | 1526995765-29693-1-git-send-email-geert+renesas@glider.be (mailing list archive) |
|---|---|
| State | RFC |
| Delegated to: | Simon Horman |
| Headers | show |
On Tue, May 22, 2018 at 03:29:25PM +0200, Geert Uytterhoeven wrote: > According to Documentation/devicetree/bindings/arm/cpus.txt, the > "enable-method" property should be a property of the individual CPU > nodes, not of the parent "cpus" node. However, on R-Car M2-W (and on > several other arm32 SoCs), the property is tied to the "cpus" node > instead. > > Secondary CPU bringup and CPU hot (un)plug work regardless, as > arm_dt_init_cpu_maps() falls back to looking in the "cpus" node. > > The cpuidle code does not have such a fallback, so it does not detect > the enable-method. Note that cpuidle does not support the > "renesas,apmu" enable-method yet, so for now this does not make any > difference. Is the implication that if we keep the current binding for cpu nodes then at some point we will need to update the cpuidle binding? > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> > --- > Arm64 and powerpc do not have such a fallback, but SH has, like arm32. > > This is marked RFC, as the alternative is to update the DT bindings to > keep the status quo. > --- > arch/arm/boot/dts/r8a7791.dtsi | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi > index d568bd22d6cbd855..b214cb8f52e47109 100644 > --- a/arch/arm/boot/dts/r8a7791.dtsi > +++ b/arch/arm/boot/dts/r8a7791.dtsi > @@ -71,7 +71,6 @@ > cpus { > #address-cells = <1>; > #size-cells = <0>; > - enable-method = "renesas,apmu"; > > cpu0: cpu@0 { > device_type = "cpu"; > @@ -83,6 +82,7 @@ > clock-latency = <300000>; /* 300 us */ > power-domains = <&sysc R8A7791_PD_CA15_CPU0>; > next-level-cache = <&L2_CA15>; > + enable-method = "renesas,apmu"; > > /* kHz - uV - OPPs unknown yet */ > operating-points = <1500000 1000000>, > @@ -101,6 +101,7 @@ > clocks = <&cpg CPG_CORE R8A7791_CLK_Z>; > power-domains = <&sysc R8A7791_PD_CA15_CPU1>; > next-level-cache = <&L2_CA15>; > + enable-method = "renesas,apmu"; > }; > > L2_CA15: cache-controller-0 { > -- > 2.7.4 >
Hi Simon, On Wed, May 23, 2018 at 10:37 AM, Simon Horman <horms@verge.net.au> wrote: > On Tue, May 22, 2018 at 03:29:25PM +0200, Geert Uytterhoeven wrote: >> According to Documentation/devicetree/bindings/arm/cpus.txt, the >> "enable-method" property should be a property of the individual CPU >> nodes, not of the parent "cpus" node. However, on R-Car M2-W (and on >> several other arm32 SoCs), the property is tied to the "cpus" node >> instead. >> >> Secondary CPU bringup and CPU hot (un)plug work regardless, as >> arm_dt_init_cpu_maps() falls back to looking in the "cpus" node. >> >> The cpuidle code does not have such a fallback, so it does not detect >> the enable-method. Note that cpuidle does not support the >> "renesas,apmu" enable-method yet, so for now this does not make any >> difference. > > Is the implication that if we keep the current binding for cpu nodes > then at some point we will need to update the cpuidle binding? If we keep the current binding for cpu nodes, we indeed have to update (common) Documentation/devicetree/bindings/arm/cpus.txt. In addition, if we want to add renesas,apmu-based cpuidle support later, we will have to update the common cpuidle code to look in /cpus, too. >> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> >> --- >> Arm64 and powerpc do not have such a fallback, but SH has, like arm32. >> >> This is marked RFC, as the alternative is to update the DT bindings to >> keep the status quo. >> --- >> arch/arm/boot/dts/r8a7791.dtsi | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi >> index d568bd22d6cbd855..b214cb8f52e47109 100644 >> --- a/arch/arm/boot/dts/r8a7791.dtsi >> +++ b/arch/arm/boot/dts/r8a7791.dtsi >> @@ -71,7 +71,6 @@ >> cpus { >> #address-cells = <1>; >> #size-cells = <0>; >> - enable-method = "renesas,apmu"; >> >> cpu0: cpu@0 { >> device_type = "cpu"; >> @@ -83,6 +82,7 @@ >> clock-latency = <300000>; /* 300 us */ >> power-domains = <&sysc R8A7791_PD_CA15_CPU0>; >> next-level-cache = <&L2_CA15>; >> + enable-method = "renesas,apmu"; >> >> /* kHz - uV - OPPs unknown yet */ >> operating-points = <1500000 1000000>, >> @@ -101,6 +101,7 @@ >> clocks = <&cpg CPG_CORE R8A7791_CLK_Z>; >> power-domains = <&sysc R8A7791_PD_CA15_CPU1>; >> next-level-cache = <&L2_CA15>; >> + enable-method = "renesas,apmu"; >> }; >> >> L2_CA15: cache-controller-0 { Gr{oetje,eeting}s, Geert
On Wed, May 23, 2018 at 10:50 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > On Wed, May 23, 2018 at 10:37 AM, Simon Horman <horms@verge.net.au> wrote: > > On Tue, May 22, 2018 at 03:29:25PM +0200, Geert Uytterhoeven wrote: > >> According to Documentation/devicetree/bindings/arm/cpus.txt, the > >> "enable-method" property should be a property of the individual CPU > >> nodes, not of the parent "cpus" node. However, on R-Car M2-W (and on > >> several other arm32 SoCs), the property is tied to the "cpus" node > >> instead. > >> > >> Secondary CPU bringup and CPU hot (un)plug work regardless, as > >> arm_dt_init_cpu_maps() falls back to looking in the "cpus" node. > >> > >> The cpuidle code does not have such a fallback, so it does not detect > >> the enable-method. Note that cpuidle does not support the > >> "renesas,apmu" enable-method yet, so for now this does not make any > >> difference. > > > > Is the implication that if we keep the current binding for cpu nodes > > then at some point we will need to update the cpuidle binding? > > If we keep the current binding for cpu nodes, we indeed have to update > (common) Documentation/devicetree/bindings/arm/cpus.txt. > > In addition, if we want to add renesas,apmu-based cpuidle support later, > we will have to update the common cpuidle code to look in /cpus, too. Any comments from the DT/ARM people? Thanks! > >> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> > >> --- > >> Arm64 and powerpc do not have such a fallback, but SH has, like arm32. > >> > >> This is marked RFC, as the alternative is to update the DT bindings to > >> keep the status quo. > >> --- > >> arch/arm/boot/dts/r8a7791.dtsi | 3 ++- > >> 1 file changed, 2 insertions(+), 1 deletion(-) > >> > >> diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi > >> index d568bd22d6cbd855..b214cb8f52e47109 100644 > >> --- a/arch/arm/boot/dts/r8a7791.dtsi > >> +++ b/arch/arm/boot/dts/r8a7791.dtsi > >> @@ -71,7 +71,6 @@ > >> cpus { > >> #address-cells = <1>; > >> #size-cells = <0>; > >> - enable-method = "renesas,apmu"; > >> > >> cpu0: cpu@0 { > >> device_type = "cpu"; > >> @@ -83,6 +82,7 @@ > >> clock-latency = <300000>; /* 300 us */ > >> power-domains = <&sysc R8A7791_PD_CA15_CPU0>; > >> next-level-cache = <&L2_CA15>; > >> + enable-method = "renesas,apmu"; > >> > >> /* kHz - uV - OPPs unknown yet */ > >> operating-points = <1500000 1000000>, > >> @@ -101,6 +101,7 @@ > >> clocks = <&cpg CPG_CORE R8A7791_CLK_Z>; > >> power-domains = <&sysc R8A7791_PD_CA15_CPU1>; > >> next-level-cache = <&L2_CA15>; > >> + enable-method = "renesas,apmu"; > >> }; > >> > >> L2_CA15: cache-controller-0 { Gr{oetje,eeting}s, Geert
diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi index d568bd22d6cbd855..b214cb8f52e47109 100644 --- a/arch/arm/boot/dts/r8a7791.dtsi +++ b/arch/arm/boot/dts/r8a7791.dtsi @@ -71,7 +71,6 @@ cpus { #address-cells = <1>; #size-cells = <0>; - enable-method = "renesas,apmu"; cpu0: cpu@0 { device_type = "cpu"; @@ -83,6 +82,7 @@ clock-latency = <300000>; /* 300 us */ power-domains = <&sysc R8A7791_PD_CA15_CPU0>; next-level-cache = <&L2_CA15>; + enable-method = "renesas,apmu"; /* kHz - uV - OPPs unknown yet */ operating-points = <1500000 1000000>, @@ -101,6 +101,7 @@ clocks = <&cpg CPG_CORE R8A7791_CLK_Z>; power-domains = <&sysc R8A7791_PD_CA15_CPU1>; next-level-cache = <&L2_CA15>; + enable-method = "renesas,apmu"; }; L2_CA15: cache-controller-0 {
According to Documentation/devicetree/bindings/arm/cpus.txt, the "enable-method" property should be a property of the individual CPU nodes, not of the parent "cpus" node. However, on R-Car M2-W (and on several other arm32 SoCs), the property is tied to the "cpus" node instead. Secondary CPU bringup and CPU hot (un)plug work regardless, as arm_dt_init_cpu_maps() falls back to looking in the "cpus" node. The cpuidle code does not have such a fallback, so it does not detect the enable-method. Note that cpuidle does not support the "renesas,apmu" enable-method yet, so for now this does not make any difference. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> --- Arm64 and powerpc do not have such a fallback, but SH has, like arm32. This is marked RFC, as the alternative is to update the DT bindings to keep the status quo. --- arch/arm/boot/dts/r8a7791.dtsi | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)