[PATCH 00/15] arm: dts: Fix OPP and cooling device properties

[PATCH 00/15] arm: dts: Fix OPP and cooling device properties

[Viresh Kumar]

This fixes missing OPP and cooling device properties for CPUs for the
ARM 32 bit platforms. This is build tested by the zero day testing
infrastructure as well.

Individual maintainers can pick the patches to their SoC trees or I will
ask ARM SoC maintainers to pick them up later.

--
viresh

Viresh Kumar (15):
  arm: dts: armada: Fix "#cooling-cells" property's name
  arm: dts: ls1021a: Add missing cooling device properties for CPUs
  arm: dts: mediatek: Add missing cooling device properties for CPUs
  arm: dts: rk322x: Add missing cooling device properties for CPUs
  arm: dts: uniphier: Add missing cooling device properties for CPUs
  arm: dts: sun: Add missing cooling device properties for CPUs
  arm: dts: exynos: Add missing cooling device properties for CPUs
  arm: dts: dra74x: Add missing cooling device properties for CPUs
  arm: dts: omap: Add missing cooling device properties for CPUs
  arm: dts: rk3288: Add missing cooling device properties for CPUs
  arm: dts: berlin: Add missing OPP properties for CPUs
  arm: dts: highbank: Add missing OPP properties for CPUs
  arm: dts: r8a7743: Add missing OPP properties for CPUs
  arm: dts: qcom: Add missing OPP properties for CPUs
  arm: dts: imx: Add missing OPP properties for CPUs

 arch/arm/boot/dts/armada-385-synology-ds116.dts |  2 +-
 arch/arm/boot/dts/berlin2.dtsi                  | 10 +++
 arch/arm/boot/dts/berlin2q.dtsi                 | 33 ++++++++++
 arch/arm/boot/dts/dra74x.dtsi                   | 10 +++
 arch/arm/boot/dts/exynos3250.dtsi               | 16 +++++
 arch/arm/boot/dts/exynos4210.dtsi               | 13 ++++
 arch/arm/boot/dts/exynos4412.dtsi               |  9 +++
 arch/arm/boot/dts/exynos5250.dtsi               | 23 +++++++
 arch/arm/boot/dts/highbank.dts                  | 30 +++++++++
 arch/arm/boot/dts/imx6dl.dtsi                   | 23 +++++++
 arch/arm/boot/dts/imx6q-cm-fx6.dts              | 66 +++++++++++++++++++
 arch/arm/boot/dts/imx6q.dtsi                    | 87 ++++++++++++++++++++++++-
 arch/arm/boot/dts/imx7d.dtsi                    |  5 ++
 arch/arm/boot/dts/ls1021a.dtsi                  |  1 +
 arch/arm/boot/dts/mt7623.dtsi                   |  3 +
 arch/arm/boot/dts/omap5.dtsi                    | 14 ++++
 arch/arm/boot/dts/qcom-ipq4019.dtsi             | 24 +++++++
 arch/arm/boot/dts/r8a7743.dtsi                  |  9 +++
 arch/arm/boot/dts/rk322x.dtsi                   |  3 +
 arch/arm/boot/dts/rk3288.dtsi                   | 54 +++++++++++++++
 arch/arm/boot/dts/sun6i-a31.dtsi                | 30 +++++++++
 arch/arm/boot/dts/sun7i-a20.dtsi                | 13 ++++
 arch/arm/boot/dts/sun8i-a33.dtsi                |  9 +++
 arch/arm/boot/dts/sun8i-h3.dtsi                 |  9 +++
 arch/arm/boot/dts/uniphier-pxs2.dtsi            |  3 +
 25 files changed, 495 insertions(+), 4 deletions(-)

-- 
2.15.0.194.g9af6a3dea062

[PATCH 01/15] arm: dts: armada: Fix "#cooling-cells" property's name

[Viresh Kumar]

It should be "#cooling-cells" instead of "cooling-cells". Fix it.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 arch/arm/boot/dts/armada-385-synology-ds116.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/armada-385-synology-ds116.dts b/arch/arm/boot/dts/armada-385-synology-ds116.dts
index 6782ce481ac9..d8769956cbfc 100644
--- a/arch/arm/boot/dts/armada-385-synology-ds116.dts
+++ b/arch/arm/boot/dts/armada-385-synology-ds116.dts
@@ -139,7 +139,7 @@
 					      3700 5
 					      3900 6
 					      4000 7>;
-			cooling-cells = <2>;
+			#cooling-cells = <2>;
 		};
 
 		gpio-leds {
-- 
2.15.0.194.g9af6a3dea062

[PATCH 03/15] arm: dts: mediatek: Add missing cooling device properties for CPUs

[Viresh Kumar]

The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.

Add such missing properties.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 arch/arm/boot/dts/mt7623.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
index d1eb123bc73b..1cdc346a05e8 100644
--- a/arch/arm/boot/dts/mt7623.dtsi
+++ b/arch/arm/boot/dts/mt7623.dtsi
@@ -92,6 +92,7 @@
 				 <&apmixedsys CLK_APMIXED_MAINPLL>;
 			clock-names = "cpu", "intermediate";
 			operating-points-v2 = <&cpu_opp_table>;
+			#cooling-cells = <2>;
 			clock-frequency = <1300000000>;
 		};
 
@@ -103,6 +104,7 @@
 				 <&apmixedsys CLK_APMIXED_MAINPLL>;
 			clock-names = "cpu", "intermediate";
 			operating-points-v2 = <&cpu_opp_table>;
+			#cooling-cells = <2>;
 			clock-frequency = <1300000000>;
 		};
 
@@ -114,6 +116,7 @@
 				 <&apmixedsys CLK_APMIXED_MAINPLL>;
 			clock-names = "cpu", "intermediate";
 			operating-points-v2 = <&cpu_opp_table>;
+			#cooling-cells = <2>;
 			clock-frequency = <1300000000>;
 		};
 	};
-- 
2.15.0.194.g9af6a3dea062

[PATCH 04/15] arm: dts: rk322x: Add missing cooling device properties for CPUs

[Viresh Kumar]

The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.

Add such missing properties.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 arch/arm/boot/dts/rk322x.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/rk322x.dtsi b/arch/arm/boot/dts/rk322x.dtsi
index be80e9a2c9af..ef414e39bf3a 100644
--- a/arch/arm/boot/dts/rk322x.dtsi
+++ b/arch/arm/boot/dts/rk322x.dtsi
@@ -80,6 +80,7 @@
 			reg = <0xf01>;
 			resets = <&cru SRST_CORE1>;
 			operating-points-v2 = <&cpu0_opp_table>;
+			#cooling-cells = <2>; /* min followed by max */
 			enable-method = "psci";
 		};
 
@@ -89,6 +90,7 @@
 			reg = <0xf02>;
 			resets = <&cru SRST_CORE2>;
 			operating-points-v2 = <&cpu0_opp_table>;
+			#cooling-cells = <2>; /* min followed by max */
 			enable-method = "psci";
 		};
 
@@ -98,6 +100,7 @@
 			reg = <0xf03>;
 			resets = <&cru SRST_CORE3>;
 			operating-points-v2 = <&cpu0_opp_table>;
+			#cooling-cells = <2>; /* min followed by max */
 			enable-method = "psci";
 		};
 	};
-- 
2.15.0.194.g9af6a3dea062

[PATCH 05/15] arm: dts: uniphier: Add missing cooling device properties for CPUs

[Viresh Kumar]

The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.

Add such missing properties.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 arch/arm/boot/dts/uniphier-pxs2.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/uniphier-pxs2.dtsi b/arch/arm/boot/dts/uniphier-pxs2.dtsi
index debcbd15c24b..40ed15465095 100644
--- a/arch/arm/boot/dts/uniphier-pxs2.dtsi
+++ b/arch/arm/boot/dts/uniphier-pxs2.dtsi
@@ -36,6 +36,7 @@
 			enable-method = "psci";
 			next-level-cache = <&l2>;
 			operating-points-v2 = <&cpu_opp>;
+			#cooling-cells = <2>;
 		};
 
 		cpu2: cpu at 2 {
@@ -46,6 +47,7 @@
 			enable-method = "psci";
 			next-level-cache = <&l2>;
 			operating-points-v2 = <&cpu_opp>;
+			#cooling-cells = <2>;
 		};
 
 		cpu3: cpu at 3 {
@@ -56,6 +58,7 @@
 			enable-method = "psci";
 			next-level-cache = <&l2>;
 			operating-points-v2 = <&cpu_opp>;
+			#cooling-cells = <2>;
 		};
 	};
 
-- 
2.15.0.194.g9af6a3dea062

[PATCH 06/15] arm: dts: sun: Add missing cooling device properties for CPUs

[Viresh Kumar]

The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.

Add such missing properties.

Fix other missing properties (clocks, OPP, clock latency) as well to
make it all work.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 arch/arm/boot/dts/sun6i-a31.dtsi | 30 ++++++++++++++++++++++++++++++
 arch/arm/boot/dts/sun7i-a20.dtsi | 13 +++++++++++++
 arch/arm/boot/dts/sun8i-a33.dtsi |  9 +++++++++
 arch/arm/boot/dts/sun8i-h3.dtsi  |  9 +++++++++
 4 files changed, 61 insertions(+)

diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index c72992556a86..debc0bf22ea3 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -119,18 +119,48 @@
 			compatible = "arm,cortex-a7";
 			device_type = "cpu";
 			reg = <1>;
+			clocks = <&ccu CLK_CPU>;
+			clock-latency = <244144>; /* 8 32k periods */
+			operating-points = <
+				/* kHz	  uV */
+				1008000	1200000
+				864000	1200000
+				720000	1100000
+				480000	1000000
+				>;
+			#cooling-cells = <2>;
 		};
 
 		cpu at 2 {
 			compatible = "arm,cortex-a7";
 			device_type = "cpu";
 			reg = <2>;
+			clocks = <&ccu CLK_CPU>;
+			clock-latency = <244144>; /* 8 32k periods */
+			operating-points = <
+				/* kHz	  uV */
+				1008000	1200000
+				864000	1200000
+				720000	1100000
+				480000	1000000
+				>;
+			#cooling-cells = <2>;
 		};
 
 		cpu at 3 {
 			compatible = "arm,cortex-a7";
 			device_type = "cpu";
 			reg = <3>;
+			clocks = <&ccu CLK_CPU>;
+			clock-latency = <244144>; /* 8 32k periods */
+			operating-points = <
+				/* kHz	  uV */
+				1008000	1200000
+				864000	1200000
+				720000	1100000
+				480000	1000000
+				>;
+			#cooling-cells = <2>;
 		};
 	};
 
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index e529e4ff2174..35372a0cfc8d 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -122,6 +122,19 @@
 			compatible = "arm,cortex-a7";
 			device_type = "cpu";
 			reg = <1>;
+			clocks = <&ccu CLK_CPU>;
+			clock-latency = <244144>; /* 8 32k periods */
+			operating-points = <
+				/* kHz	  uV */
+				960000	1400000
+				912000	1400000
+				864000	1300000
+				720000	1200000
+				528000	1100000
+				312000	1000000
+				144000	1000000
+				>;
+			#cooling-cells = <2>;
 		};
 	};
 
diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index 8d278ee001e9..4e92741b24a7 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -132,21 +132,30 @@
 		};
 
 		cpu at 1 {
+			clocks = <&ccu CLK_CPUX>;
+			clock-names = "cpu";
 			operating-points-v2 = <&cpu0_opp_table>;
+			#cooling-cells = <2>;
 		};
 
 		cpu at 2 {
 			compatible = "arm,cortex-a7";
 			device_type = "cpu";
 			reg = <2>;
+			clocks = <&ccu CLK_CPUX>;
+			clock-names = "cpu";
 			operating-points-v2 = <&cpu0_opp_table>;
+			#cooling-cells = <2>;
 		};
 
 		cpu at 3 {
 			compatible = "arm,cortex-a7";
 			device_type = "cpu";
 			reg = <3>;
+			clocks = <&ccu CLK_CPUX>;
+			clock-names = "cpu";
 			operating-points-v2 = <&cpu0_opp_table>;
+			#cooling-cells = <2>;
 		};
 	};
 
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 41d57c76f290..9dff6887923c 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -84,21 +84,30 @@
 			compatible = "arm,cortex-a7";
 			device_type = "cpu";
 			reg = <1>;
+			clocks = <&ccu CLK_CPUX>;
+			clock-names = "cpu";
 			operating-points-v2 = <&cpu0_opp_table>;
+			#cooling-cells = <2>;
 		};
 
 		cpu at 2 {
 			compatible = "arm,cortex-a7";
 			device_type = "cpu";
 			reg = <2>;
+			clocks = <&ccu CLK_CPUX>;
+			clock-names = "cpu";
 			operating-points-v2 = <&cpu0_opp_table>;
+			#cooling-cells = <2>;
 		};
 
 		cpu at 3 {
 			compatible = "arm,cortex-a7";
 			device_type = "cpu";
 			reg = <3>;
+			clocks = <&ccu CLK_CPUX>;
+			clock-names = "cpu";
 			operating-points-v2 = <&cpu0_opp_table>;
+			#cooling-cells = <2>;
 		};
 	};
 
-- 
2.15.0.194.g9af6a3dea062

[PATCH 07/15] arm: dts: exynos: Add missing cooling device properties for CPUs

[Viresh Kumar]

The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.

Add such missing properties.

Fix other missing properties (clocks, OPP, clock latency) as well to
make it all work.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 arch/arm/boot/dts/exynos3250.dtsi | 16 ++++++++++++++++
 arch/arm/boot/dts/exynos4210.dtsi | 13 +++++++++++++
 arch/arm/boot/dts/exynos4412.dtsi |  9 +++++++++
 arch/arm/boot/dts/exynos5250.dtsi | 23 +++++++++++++++++++++++
 4 files changed, 61 insertions(+)

diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi
index 962af97c1883..aff5d66ae058 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -78,6 +78,22 @@
 			compatible = "arm,cortex-a7";
 			reg = <1>;
 			clock-frequency = <1000000000>;
+			clocks = <&cmu CLK_ARM_CLK>;
+			clock-names = "cpu";
+			#cooling-cells = <2>;
+
+			operating-points = <
+				1000000 1150000
+				900000  1112500
+				800000  1075000
+				700000  1037500
+				600000  1000000
+				500000  962500
+				400000  925000
+				300000  887500
+				200000  850000
+				100000  850000
+			>;
 		};
 	};
 
diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
index 88fb47cef9a8..b6091c27f155 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -55,6 +55,19 @@
 			device_type = "cpu";
 			compatible = "arm,cortex-a9";
 			reg = <0x901>;
+			clocks = <&clock CLK_ARM_CLK>;
+			clock-names = "cpu";
+			clock-latency = <160000>;
+
+			operating-points = <
+				1200000 1250000
+				1000000 1150000
+				800000	1075000
+				500000	975000
+				400000	975000
+				200000	950000
+			>;
+			#cooling-cells = <2>; /* min followed by max */
 		};
 	};
 
diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
index 7b43c10c510b..51f72f0327e5 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -49,21 +49,30 @@
 			device_type = "cpu";
 			compatible = "arm,cortex-a9";
 			reg = <0xA01>;
+			clocks = <&clock CLK_ARM_CLK>;
+			clock-names = "cpu";
 			operating-points-v2 = <&cpu0_opp_table>;
+			#cooling-cells = <2>; /* min followed by max */
 		};
 
 		cpu at a02 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a9";
 			reg = <0xA02>;
+			clocks = <&clock CLK_ARM_CLK>;
+			clock-names = "cpu";
 			operating-points-v2 = <&cpu0_opp_table>;
+			#cooling-cells = <2>; /* min followed by max */
 		};
 
 		cpu at a03 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a9";
 			reg = <0xA03>;
+			clocks = <&clock CLK_ARM_CLK>;
+			clock-names = "cpu";
 			operating-points-v2 = <&cpu0_opp_table>;
+			#cooling-cells = <2>; /* min followed by max */
 		};
 	};
 
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index 2daf505b3d08..69648f83b8b4 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -84,6 +84,29 @@
 			compatible = "arm,cortex-a15";
 			reg = <1>;
 			clock-frequency = <1700000000>;
+			clocks = <&clock CLK_ARM_CLK>;
+			clock-names = "cpu";
+			clock-latency = <140000>;
+
+			operating-points = <
+				1700000 1300000
+				1600000 1250000
+				1500000 1225000
+				1400000 1200000
+				1300000 1150000
+				1200000 1125000
+				1100000 1100000
+				1000000 1075000
+				 900000 1050000
+				 800000 1025000
+				 700000 1012500
+				 600000 1000000
+				 500000  975000
+				 400000  950000
+				 300000  937500
+				 200000  925000
+			>;
+			#cooling-cells = <2>; /* min followed by max */
 		};
 	};
 
-- 
2.15.0.194.g9af6a3dea062

[PATCH 10/15] arm: dts: rk3288: Add missing cooling device properties for CPUs

[Viresh Kumar]

The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.

Add such missing properties.

Fix other missing properties (clocks, OPP, clock latency) as well to
make it all work.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 arch/arm/boot/dts/rk3288.dtsi | 54 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 54 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index d7e49d29ace5..752a892847dd 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -122,18 +122,72 @@
 			compatible = "arm,cortex-a12";
 			reg = <0x501>;
 			resets = <&cru SRST_CORE1>;
+			operating-points = <
+				/* KHz    uV */
+				1608000 1350000
+				1512000 1300000
+				1416000 1200000
+				1200000 1100000
+				1008000 1050000
+				 816000 1000000
+				 696000  950000
+				 600000  900000
+				 408000  900000
+				 312000  900000
+				 216000  900000
+				 126000  900000
+			>;
+			#cooling-cells = <2>; /* min followed by max */
+			clock-latency = <40000>;
+			clocks = <&cru ARMCLK>;
 		};
 		cpu2: cpu at 502 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a12";
 			reg = <0x502>;
 			resets = <&cru SRST_CORE2>;
+			operating-points = <
+				/* KHz    uV */
+				1608000 1350000
+				1512000 1300000
+				1416000 1200000
+				1200000 1100000
+				1008000 1050000
+				 816000 1000000
+				 696000  950000
+				 600000  900000
+				 408000  900000
+				 312000  900000
+				 216000  900000
+				 126000  900000
+			>;
+			#cooling-cells = <2>; /* min followed by max */
+			clock-latency = <40000>;
+			clocks = <&cru ARMCLK>;
 		};
 		cpu3: cpu at 503 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a12";
 			reg = <0x503>;
 			resets = <&cru SRST_CORE3>;
+			operating-points = <
+				/* KHz    uV */
+				1608000 1350000
+				1512000 1300000
+				1416000 1200000
+				1200000 1100000
+				1008000 1050000
+				 816000 1000000
+				 696000  950000
+				 600000  900000
+				 408000  900000
+				 312000  900000
+				 216000  900000
+				 126000  900000
+			>;
+			#cooling-cells = <2>; /* min followed by max */
+			clock-latency = <40000>;
+			clocks = <&cru ARMCLK>;
 		};
 	};
 
-- 
2.15.0.194.g9af6a3dea062

[PATCH 11/15] arm: dts: berlin: Add missing OPP properties for CPUs

[Viresh Kumar]

The OPP properties, like "operating-points", should either be present
for all the CPUs of a cluster or none. If these are present only for a
subset of CPUs of a cluster then things will start falling apart as soon
as the CPUs are brought online in a different order. For example, this
will happen because the operating system looks for such properties in
the CPU node it is trying to bring up, so that it can create an OPP
table.

Add such missing properties.

Fix other missing properties (clocks, clock latency) as well to
make it all work.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 arch/arm/boot/dts/berlin2.dtsi  | 10 ++++++++++
 arch/arm/boot/dts/berlin2q.dtsi | 33 +++++++++++++++++++++++++++++++++
 2 files changed, 43 insertions(+)

diff --git a/arch/arm/boot/dts/berlin2.dtsi b/arch/arm/boot/dts/berlin2.dtsi
index d575823c5750..487e9de53244 100644
--- a/arch/arm/boot/dts/berlin2.dtsi
+++ b/arch/arm/boot/dts/berlin2.dtsi
@@ -81,6 +81,16 @@
 			device_type = "cpu";
 			next-level-cache = <&l2>;
 			reg = <1>;
+
+			clocks = <&chip_clk CLKID_CPU>;
+			clock-latency = <100000>;
+			operating-points = <
+				/* kHz    uV */
+				1200000 1200000
+				1000000 1200000
+				800000  1200000
+				600000  1200000
+			>;
 		};
 	};
 
diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
index bf3a6c9a1d34..9cd00ab53f2d 100644
--- a/arch/arm/boot/dts/berlin2q.dtsi
+++ b/arch/arm/boot/dts/berlin2q.dtsi
@@ -76,6 +76,17 @@
 			device_type = "cpu";
 			next-level-cache = <&l2>;
 			reg = <1>;
+
+			clocks = <&chip_clk CLKID_CPU>;
+			clock-latency = <100000>;
+			/* Can be modified by the bootloader */
+			operating-points = <
+				/* kHz    uV */
+				1200000 1200000
+				1000000 1200000
+				800000  1200000
+				600000  1200000
+			>;
 		};
 
 		cpu at 2 {
@@ -83,6 +94,17 @@
 			device_type = "cpu";
 			next-level-cache = <&l2>;
 			reg = <2>;
+
+			clocks = <&chip_clk CLKID_CPU>;
+			clock-latency = <100000>;
+			/* Can be modified by the bootloader */
+			operating-points = <
+				/* kHz    uV */
+				1200000 1200000
+				1000000 1200000
+				800000  1200000
+				600000  1200000
+			>;
 		};
 
 		cpu at 3 {
@@ -90,6 +112,17 @@
 			device_type = "cpu";
 			next-level-cache = <&l2>;
 			reg = <3>;
+
+			clocks = <&chip_clk CLKID_CPU>;
+			clock-latency = <100000>;
+			/* Can be modified by the bootloader */
+			operating-points = <
+				/* kHz    uV */
+				1200000 1200000
+				1000000 1200000
+				800000  1200000
+				600000  1200000
+			>;
 		};
 	};
 
-- 
2.15.0.194.g9af6a3dea062

[PATCH 12/15] arm: dts: highbank: Add missing OPP properties for CPUs

[Viresh Kumar]

The OPP properties, like "operating-points", should either be present
for all the CPUs of a cluster or none. If these are present only for a
subset of CPUs of a cluster then things will start falling apart as soon
as the CPUs are brought online in a different order. For example, this
will happen because the operating system looks for such properties in
the CPU node it is trying to bring up, so that it can create an OPP
table.

Add such missing properties.

Fix other missing property (clock latency) as well to make it all
work.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 arch/arm/boot/dts/highbank.dts | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/highbank.dts b/arch/arm/boot/dts/highbank.dts
index ed14aeac0566..50278715de76 100644
--- a/arch/arm/boot/dts/highbank.dts
+++ b/arch/arm/boot/dts/highbank.dts
@@ -56,6 +56,16 @@
 			next-level-cache = <&L2>;
 			clocks = <&a9pll>;
 			clock-names = "cpu";
+			operating-points = <
+				/* kHz    ignored */
+				 1300000  1000000
+				 1200000  1000000
+				 1100000  1000000
+				  800000  1000000
+				  400000  1000000
+				  200000  1000000
+			>;
+			clock-latency = <100000>;
 		};
 
 		cpu at 902 {
@@ -65,6 +75,16 @@
 			next-level-cache = <&L2>;
 			clocks = <&a9pll>;
 			clock-names = "cpu";
+			operating-points = <
+				/* kHz    ignored */
+				 1300000  1000000
+				 1200000  1000000
+				 1100000  1000000
+				  800000  1000000
+				  400000  1000000
+				  200000  1000000
+			>;
+			clock-latency = <100000>;
 		};
 
 		cpu at 903 {
@@ -74,6 +94,16 @@
 			next-level-cache = <&L2>;
 			clocks = <&a9pll>;
 			clock-names = "cpu";
+			operating-points = <
+				/* kHz    ignored */
+				 1300000  1000000
+				 1200000  1000000
+				 1100000  1000000
+				  800000  1000000
+				  400000  1000000
+				  200000  1000000
+			>;
+			clock-latency = <100000>;
 		};
 	};
 
-- 
2.15.0.194.g9af6a3dea062

[PATCH 15/15] arm: dts: imx: Add missing OPP properties for CPUs

[Viresh Kumar]

The OPP properties, like "operating-points", should either be present
for all the CPUs of a cluster or none. If these are present only for a
subset of CPUs of a cluster then things will start falling apart as soon
as the CPUs are brought online in a different order. For example, this
will happen because the operating system looks for such properties in
the CPU node it is trying to bring up, so that it can create an OPP
table.

Add such missing properties.

Fix other missing properties (like clocks, supply, clock latency) as
well to make it all work.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 arch/arm/boot/dts/imx6dl.dtsi      | 23 ++++++++++
 arch/arm/boot/dts/imx6q-cm-fx6.dts | 66 +++++++++++++++++++++++++++++
 arch/arm/boot/dts/imx6q.dtsi       | 87 ++++++++++++++++++++++++++++++++++++--
 arch/arm/boot/dts/imx7d.dtsi       |  5 +++
 4 files changed, 178 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index b384913c34dd..cc8ffc42d128 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -50,6 +50,29 @@
 			device_type = "cpu";
 			reg = <1>;
 			next-level-cache = <&L2>;
+			operating-points = <
+				/* kHz    uV */
+				996000  1250000
+				792000  1175000
+				396000  1150000
+			>;
+			fsl,soc-operating-points = <
+				/* ARM kHz  SOC-PU uV */
+				996000	1175000
+				792000	1175000
+				396000	1175000
+			>;
+			clock-latency = <61036>; /* two CLK32 periods */
+			clocks = <&clks IMX6QDL_CLK_ARM>,
+				 <&clks IMX6QDL_CLK_PLL2_PFD2_396M>,
+				 <&clks IMX6QDL_CLK_STEP>,
+				 <&clks IMX6QDL_CLK_PLL1_SW>,
+				 <&clks IMX6QDL_CLK_PLL1_SYS>;
+			clock-names = "arm", "pll2_pfd2_396m", "step",
+				      "pll1_sw", "pll1_sys";
+			arm-supply = <&reg_arm>;
+			pu-supply = <&reg_pu>;
+			soc-supply = <&reg_soc>;
 		};
 	};
 
diff --git a/arch/arm/boot/dts/imx6q-cm-fx6.dts b/arch/arm/boot/dts/imx6q-cm-fx6.dts
index 65ef4cacbc71..18ae4f3be6e3 100644
--- a/arch/arm/boot/dts/imx6q-cm-fx6.dts
+++ b/arch/arm/boot/dts/imx6q-cm-fx6.dts
@@ -187,6 +187,72 @@
 	>;
 };
 
+&cpu1 {
+	/*
+	 * Although the imx6q fuse indicates that 1.2GHz operation is possible,
+	 * the module behaves unstable at this frequency. Hence, remove the
+	 * 1.2GHz operation point here.
+	 */
+	operating-points = <
+		/* kHz	uV */
+		996000	1250000
+		852000	1250000
+		792000	1175000
+		396000	975000
+	>;
+	fsl,soc-operating-points = <
+		/* ARM kHz	SOC-PU uV */
+		996000		1250000
+		852000		1250000
+		792000		1175000
+		396000		1175000
+	>;
+};
+
+&cpu2 {
+	/*
+	 * Although the imx6q fuse indicates that 1.2GHz operation is possible,
+	 * the module behaves unstable at this frequency. Hence, remove the
+	 * 1.2GHz operation point here.
+	 */
+	operating-points = <
+		/* kHz	uV */
+		996000	1250000
+		852000	1250000
+		792000	1175000
+		396000	975000
+	>;
+	fsl,soc-operating-points = <
+		/* ARM kHz	SOC-PU uV */
+		996000		1250000
+		852000		1250000
+		792000		1175000
+		396000		1175000
+	>;
+};
+
+&cpu3 {
+	/*
+	 * Although the imx6q fuse indicates that 1.2GHz operation is possible,
+	 * the module behaves unstable at this frequency. Hence, remove the
+	 * 1.2GHz operation point here.
+	 */
+	operating-points = <
+		/* kHz	uV */
+		996000	1250000
+		852000	1250000
+		792000	1175000
+		396000	975000
+	>;
+	fsl,soc-operating-points = <
+		/* ARM kHz	SOC-PU uV */
+		996000		1250000
+		852000		1250000
+		792000		1175000
+		396000		1175000
+	>;
+};
+
 &ecspi1 {
 	cs-gpios = <&gpio2 30 GPIO_ACTIVE_HIGH>, <&gpio3 19 GPIO_ACTIVE_HIGH>;
 	pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index 70483ce72ba6..78b89bb1bfed 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -50,25 +50,106 @@
 			soc-supply = <&reg_soc>;
 		};
 
-		cpu at 1 {
+		cpu1: cpu at 1 {
 			compatible = "arm,cortex-a9";
 			device_type = "cpu";
 			reg = <1>;
 			next-level-cache = <&L2>;
+			operating-points = <
+				/* kHz    uV */
+				1200000 1275000
+				996000  1250000
+				852000  1250000
+				792000  1175000
+				396000  975000
+			>;
+			fsl,soc-operating-points = <
+				/* ARM kHz  SOC-PU uV */
+				1200000 1275000
+				996000	1250000
+				852000	1250000
+				792000	1175000
+				396000	1175000
+			>;
+			clock-latency = <61036>; /* two CLK32 periods */
+			clocks = <&clks IMX6QDL_CLK_ARM>,
+				 <&clks IMX6QDL_CLK_PLL2_PFD2_396M>,
+				 <&clks IMX6QDL_CLK_STEP>,
+				 <&clks IMX6QDL_CLK_PLL1_SW>,
+				 <&clks IMX6QDL_CLK_PLL1_SYS>;
+			clock-names = "arm", "pll2_pfd2_396m", "step",
+				      "pll1_sw", "pll1_sys";
+			arm-supply = <&reg_arm>;
+			pu-supply = <&reg_pu>;
+			soc-supply = <&reg_soc>;
 		};
 
-		cpu at 2 {
+		cpu2: cpu at 2 {
 			compatible = "arm,cortex-a9";
 			device_type = "cpu";
 			reg = <2>;
 			next-level-cache = <&L2>;
+			operating-points = <
+				/* kHz    uV */
+				1200000 1275000
+				996000  1250000
+				852000  1250000
+				792000  1175000
+				396000  975000
+			>;
+			fsl,soc-operating-points = <
+				/* ARM kHz  SOC-PU uV */
+				1200000 1275000
+				996000	1250000
+				852000	1250000
+				792000	1175000
+				396000	1175000
+			>;
+			clock-latency = <61036>; /* two CLK32 periods */
+			clocks = <&clks IMX6QDL_CLK_ARM>,
+				 <&clks IMX6QDL_CLK_PLL2_PFD2_396M>,
+				 <&clks IMX6QDL_CLK_STEP>,
+				 <&clks IMX6QDL_CLK_PLL1_SW>,
+				 <&clks IMX6QDL_CLK_PLL1_SYS>;
+			clock-names = "arm", "pll2_pfd2_396m", "step",
+				      "pll1_sw", "pll1_sys";
+			arm-supply = <&reg_arm>;
+			pu-supply = <&reg_pu>;
+			soc-supply = <&reg_soc>;
 		};
 
-		cpu at 3 {
+		cpu3: cpu at 3 {
 			compatible = "arm,cortex-a9";
 			device_type = "cpu";
 			reg = <3>;
 			next-level-cache = <&L2>;
+			operating-points = <
+				/* kHz    uV */
+				1200000 1275000
+				996000  1250000
+				852000  1250000
+				792000  1175000
+				396000  975000
+			>;
+			fsl,soc-operating-points = <
+				/* ARM kHz  SOC-PU uV */
+				1200000 1275000
+				996000	1250000
+				852000	1250000
+				792000	1175000
+				396000	1175000
+			>;
+			clock-latency = <61036>; /* two CLK32 periods */
+			clocks = <&clks IMX6QDL_CLK_ARM>,
+				 <&clks IMX6QDL_CLK_PLL2_PFD2_396M>,
+				 <&clks IMX6QDL_CLK_STEP>,
+				 <&clks IMX6QDL_CLK_PLL1_SW>,
+				 <&clks IMX6QDL_CLK_PLL1_SYS>;
+			clock-names = "arm", "pll2_pfd2_396m", "step",
+				      "pll1_sw", "pll1_sys";
+			arm-supply = <&reg_arm>;
+			pu-supply = <&reg_pu>;
+			soc-supply = <&reg_soc>;
 		};
 	};
 
diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
index 4c9877ec29f2..5434a8aa5602 100644
--- a/arch/arm/boot/dts/imx7d.dtsi
+++ b/arch/arm/boot/dts/imx7d.dtsi
@@ -21,6 +21,11 @@
 			compatible = "arm,cortex-a7";
 			device_type = "cpu";
 			reg = <1>;
+			operating-points = <
+				/* KHz	uV */
+				996000	1075000
+				792000	975000
+			>;
 			clock-frequency = <996000000>;
 		};
 	};
-- 
2.15.0.194.g9af6a3dea062

[PATCH 15/15] arm: dts: imx: Add missing OPP properties for CPUs

[Lucas Stach]

Hi Viresh,

Am Freitag, den 25.05.2018, 16:02 +0530 schrieb Viresh Kumar:
> The OPP properties, like "operating-points", should either be present
> for all the CPUs of a cluster or none. If these are present only for a
> subset of CPUs of a cluster then things will start falling apart as soon
> as the CPUs are brought online in a different order. For example, this
> will happen because the operating system looks for such properties in
> the CPU node it is trying to bring up, so that it can create an OPP
> table.
> 
> Add such missing properties.
> 
> Fix other missing properties (like clocks, supply, clock latency) as
> well to make it all work.

This is a lot of duplicate information for what is effectively a shared
 cluster wide thing. This does absolutely not _feel_ right.

What problem are you solving here? Why do we need all this duplicate
information? Why can't we fix it by falling back to looking at cpu0 if
needed?

Regards,
Lucas

> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> ?arch/arm/boot/dts/imx6dl.dtsi??????| 23 ++++++++++
> ?arch/arm/boot/dts/imx6q-cm-fx6.dts | 66 +++++++++++++++++++++++++++++
> ?arch/arm/boot/dts/imx6q.dtsi???????| 87 ++++++++++++++++++++++++++++++++++++--
> ?arch/arm/boot/dts/imx7d.dtsi???????|??5 +++
> ?4 files changed, 178 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
> index b384913c34dd..cc8ffc42d128 100644
> --- a/arch/arm/boot/dts/imx6dl.dtsi
> +++ b/arch/arm/boot/dts/imx6dl.dtsi
> @@ -50,6 +50,29 @@
> > ?			device_type = "cpu";
> > ?			reg = <1>;
> > ?			next-level-cache = <&L2>;
> > +			operating-points = <
> > +				/* kHz????uV */
> > +				996000??1250000
> > +				792000??1175000
> > +				396000??1150000
> > +			>;
> > +			fsl,soc-operating-points = <
> > +				/* ARM kHz??SOC-PU uV */
> > > +				996000	1175000
> > > +				792000	1175000
> > > +				396000	1175000
> > +			>;
> > +			clock-latency = <61036>; /* two CLK32 periods */
> > +			clocks = <&clks IMX6QDL_CLK_ARM>,
> > +				?<&clks IMX6QDL_CLK_PLL2_PFD2_396M>,
> > +				?<&clks IMX6QDL_CLK_STEP>,
> > +				?<&clks IMX6QDL_CLK_PLL1_SW>,
> > +				?<&clks IMX6QDL_CLK_PLL1_SYS>;
> > +			clock-names = "arm", "pll2_pfd2_396m", "step",
> > +				??????"pll1_sw", "pll1_sys";
> > +			arm-supply = <&reg_arm>;
> > +			pu-supply = <&reg_pu>;
> > +			soc-supply = <&reg_soc>;
> > ?		};
> > ?	};
> ?
> diff --git a/arch/arm/boot/dts/imx6q-cm-fx6.dts b/arch/arm/boot/dts/imx6q-cm-fx6.dts
> index 65ef4cacbc71..18ae4f3be6e3 100644
> --- a/arch/arm/boot/dts/imx6q-cm-fx6.dts
> +++ b/arch/arm/boot/dts/imx6q-cm-fx6.dts
> @@ -187,6 +187,72 @@
> > ?	>;
> ?};
> ?
> +&cpu1 {
> > +	/*
> > +	?* Although the imx6q fuse indicates that 1.2GHz operation is possible,
> > +	?* the module behaves unstable at this frequency. Hence, remove the
> > +	?* 1.2GHz operation point here.
> > +	?*/
> > +	operating-points = <
> > > +		/* kHz	uV */
> > > +		996000	1250000
> > > +		852000	1250000
> > > +		792000	1175000
> > > +		396000	975000
> > +	>;
> > +	fsl,soc-operating-points = <
> > > +		/* ARM kHz	SOC-PU uV */
> > > +		996000		1250000
> > > +		852000		1250000
> > > +		792000		1175000
> > > +		396000		1175000
> > +	>;
> +};
> +
> +&cpu2 {
> > +	/*
> > +	?* Although the imx6q fuse indicates that 1.2GHz operation is possible,
> > +	?* the module behaves unstable at this frequency. Hence, remove the
> > +	?* 1.2GHz operation point here.
> > +	?*/
> > +	operating-points = <
> > > +		/* kHz	uV */
> > > +		996000	1250000
> > > +		852000	1250000
> > > +		792000	1175000
> > > +		396000	975000
> > +	>;
> > +	fsl,soc-operating-points = <
> > > +		/* ARM kHz	SOC-PU uV */
> > > +		996000		1250000
> > > +		852000		1250000
> > > +		792000		1175000
> > > +		396000		1175000
> > +	>;
> +};
> +
> +&cpu3 {
> > +	/*
> > +	?* Although the imx6q fuse indicates that 1.2GHz operation is possible,
> > +	?* the module behaves unstable at this frequency. Hence, remove the
> > +	?* 1.2GHz operation point here.
> > +	?*/
> > +	operating-points = <
> > > +		/* kHz	uV */
> > > +		996000	1250000
> > > +		852000	1250000
> > > +		792000	1175000
> > > +		396000	975000
> > +	>;
> > +	fsl,soc-operating-points = <
> > > +		/* ARM kHz	SOC-PU uV */
> > > +		996000		1250000
> > > +		852000		1250000
> > > +		792000		1175000
> > > +		396000		1175000
> > +	>;
> +};
> +
> ?&ecspi1 {
> > ?	cs-gpios = <&gpio2 30 GPIO_ACTIVE_HIGH>, <&gpio3 19 GPIO_ACTIVE_HIGH>;
> > ?	pinctrl-names = "default";
> diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
> index 70483ce72ba6..78b89bb1bfed 100644
> --- a/arch/arm/boot/dts/imx6q.dtsi
> +++ b/arch/arm/boot/dts/imx6q.dtsi
> @@ -50,25 +50,106 @@
> > ?			soc-supply = <&reg_soc>;
> > ?		};
> ?
> > -		cpu at 1 {
> > > +		cpu1: cpu at 1 {
> > ?			compatible = "arm,cortex-a9";
> > ?			device_type = "cpu";
> > ?			reg = <1>;
> > ?			next-level-cache = <&L2>;
> > +			operating-points = <
> > +				/* kHz????uV */
> > +				1200000 1275000
> > +				996000??1250000
> > +				852000??1250000
> > +				792000??1175000
> > +				396000??975000
> > +			>;
> > +			fsl,soc-operating-points = <
> > +				/* ARM kHz??SOC-PU uV */
> > +				1200000 1275000
> > > +				996000	1250000
> > > +				852000	1250000
> > > +				792000	1175000
> > > +				396000	1175000
> > +			>;
> > +			clock-latency = <61036>; /* two CLK32 periods */
> > +			clocks = <&clks IMX6QDL_CLK_ARM>,
> > +				?<&clks IMX6QDL_CLK_PLL2_PFD2_396M>,
> > +				?<&clks IMX6QDL_CLK_STEP>,
> > +				?<&clks IMX6QDL_CLK_PLL1_SW>,
> > +				?<&clks IMX6QDL_CLK_PLL1_SYS>;
> > +			clock-names = "arm", "pll2_pfd2_396m", "step",
> > +				??????"pll1_sw", "pll1_sys";
> > +			arm-supply = <&reg_arm>;
> > +			pu-supply = <&reg_pu>;
> > +			soc-supply = <&reg_soc>;
> > ?		};
> ?
> > -		cpu at 2 {
> > > +		cpu2: cpu at 2 {
> > ?			compatible = "arm,cortex-a9";
> > ?			device_type = "cpu";
> > ?			reg = <2>;
> > ?			next-level-cache = <&L2>;
> > +			operating-points = <
> > +				/* kHz????uV */
> > +				1200000 1275000
> > +				996000??1250000
> > +				852000??1250000
> > +				792000??1175000
> > +				396000??975000
> > +			>;
> > +			fsl,soc-operating-points = <
> > +				/* ARM kHz??SOC-PU uV */
> > +				1200000 1275000
> > > +				996000	1250000
> > > +				852000	1250000
> > > +				792000	1175000
> > > +				396000	1175000
> > +			>;
> > +			clock-latency = <61036>; /* two CLK32 periods */
> > +			clocks = <&clks IMX6QDL_CLK_ARM>,
> > +				?<&clks IMX6QDL_CLK_PLL2_PFD2_396M>,
> > +				?<&clks IMX6QDL_CLK_STEP>,
> > +				?<&clks IMX6QDL_CLK_PLL1_SW>,
> > +				?<&clks IMX6QDL_CLK_PLL1_SYS>;
> > +			clock-names = "arm", "pll2_pfd2_396m", "step",
> > +				??????"pll1_sw", "pll1_sys";
> > +			arm-supply = <&reg_arm>;
> > +			pu-supply = <&reg_pu>;
> > +			soc-supply = <&reg_soc>;
> > ?		};
> ?
> > -		cpu at 3 {
> > > +		cpu3: cpu at 3 {
> > ?			compatible = "arm,cortex-a9";
> > ?			device_type = "cpu";
> > ?			reg = <3>;
> > ?			next-level-cache = <&L2>;
> > +			operating-points = <
> > +				/* kHz????uV */
> > +				1200000 1275000
> > +				996000??1250000
> > +				852000??1250000
> > +				792000??1175000
> > +				396000??975000
> > +			>;
> > +			fsl,soc-operating-points = <
> > +				/* ARM kHz??SOC-PU uV */
> > +				1200000 1275000
> > > +				996000	1250000
> > > +				852000	1250000
> > > +				792000	1175000
> > > +				396000	1175000
> > +			>;
> > +			clock-latency = <61036>; /* two CLK32 periods */
> > +			clocks = <&clks IMX6QDL_CLK_ARM>,
> > +				?<&clks IMX6QDL_CLK_PLL2_PFD2_396M>,
> > +				?<&clks IMX6QDL_CLK_STEP>,
> > +				?<&clks IMX6QDL_CLK_PLL1_SW>,
> > +				?<&clks IMX6QDL_CLK_PLL1_SYS>;
> > +			clock-names = "arm", "pll2_pfd2_396m", "step",
> > +				??????"pll1_sw", "pll1_sys";
> > +			arm-supply = <&reg_arm>;
> > +			pu-supply = <&reg_pu>;
> > +			soc-supply = <&reg_soc>;
> > ?		};
> > ?	};
> ?
> diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
> index 4c9877ec29f2..5434a8aa5602 100644
> --- a/arch/arm/boot/dts/imx7d.dtsi
> +++ b/arch/arm/boot/dts/imx7d.dtsi
> @@ -21,6 +21,11 @@
> > ?			compatible = "arm,cortex-a7";
> > ?			device_type = "cpu";
> > ?			reg = <1>;
> > +			operating-points = <
> > > +				/* KHz	uV */
> > > +				996000	1075000
> > > +				792000	975000
> > +			>;
> > ?			clock-frequency = <996000000>;
> > ?		};
> > ?	};

[PATCH 06/15] arm: dts: sun: Add missing cooling device properties for CPUs

[Maxime Ripard]

Hi,

On Fri, May 25, 2018 at 04:01:52PM +0530, Viresh Kumar wrote:
> The cooling device properties, like "#cooling-cells" and
> "dynamic-power-coefficient", should either be present for all the CPUs
> of a cluster or none. If these are present only for a subset of CPUs of
> a cluster then things will start falling apart as soon as the CPUs are
> brought online in a different order. For example, this will happen
> because the operating system looks for such properties in the CPU node
> it is trying to bring up, so that it can register a cooling device.
> 
> Add such missing properties.
> 
> Fix other missing properties (clocks, OPP, clock latency) as well to
> make it all work.
> 
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>

The prefix should be sunxi and not sun, but it looks good to me
otherwise.

Let me know what your preferred merge method is.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180528/a2bdcdbe/attachment.sig>

[PATCH 06/15] arm: dts: sun: Add missing cooling device properties for CPUs

[Viresh Kumar]

On 28-05-18, 10:44, Maxime Ripard wrote:
> Hi,
> 
> On Fri, May 25, 2018 at 04:01:52PM +0530, Viresh Kumar wrote:
> > The cooling device properties, like "#cooling-cells" and
> > "dynamic-power-coefficient", should either be present for all the CPUs
> > of a cluster or none. If these are present only for a subset of CPUs of
> > a cluster then things will start falling apart as soon as the CPUs are
> > brought online in a different order. For example, this will happen
> > because the operating system looks for such properties in the CPU node
> > it is trying to bring up, so that it can register a cooling device.
> > 
> > Add such missing properties.
> > 
> > Fix other missing properties (clocks, OPP, clock latency) as well to
> > make it all work.
> > 
> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> 
> The prefix should be sunxi and not sun, but it looks good to me
> otherwise.
> 
> Let me know what your preferred merge method is.

Please pick it up directly and send it as part of your pull request.
Do you want me to resend or can you fix the $subject ?

Thanks.

-- 
viresh

[PATCH 15/15] arm: dts: imx: Add missing OPP properties for CPUs

[Viresh Kumar]

Hi Lucas,

On 25-05-18, 13:46, Lucas Stach wrote:
> This is a lot of duplicate information for what is effectively a shared
>  cluster wide thing. This does absolutely not _feel_ right.

I cannot agree more :)

> What problem are you solving here? Why do we need all this duplicate
> information? Why can't we fix it by falling back to looking at cpu0 if
> needed?

Let me try explaining one of the problem scenarios to you as your
platform is a single cluster one. Make cpufreq driver as module, don't
insert it, hotplug out CPU0 and now insert the cpufreq driver. The
cpufreq core will try adding the cpufreq policy for CPU1 but wouldn't
find the required information in the DT node of CPU1 and so will fail
or behave incorrectly.

We can't look at CPU0 as we don't know they are related at all.
Nothing tells that to us. The right solution to fix the duplication is
to move to OPP-v2 bindings, which allow us to create a single OPP
table node and refer to it from all the CPU nodes. Because in case of
imx platforms getting updated here, we use the old and some platforms
specific frequency tables, we have to duplicate it everywhere.

But looking from DT otherwise, all the device should anyway have all
the information required right in their node. That can be simplified
with things like phandle to opp-v2 node, but still everything needs to
be there. We shouldn't really rely on other CPU nodes to make it work.
That would be an incomplete definition of the hardware IMHO.

-- 
viresh

[PATCH 01/15] arm: dts: armada: Fix "#cooling-cells" property's name

[Gregory CLEMENT]

Hi Viresh,
 
 On ven., mai 25 2018, Viresh Kumar <viresh.kumar@linaro.org> wrote:

> It should be "#cooling-cells" instead of "cooling-cells". Fix it.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>


Applied on mvebu/fixes

Thanks,

Gregory

> ---
>  arch/arm/boot/dts/armada-385-synology-ds116.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/armada-385-synology-ds116.dts b/arch/arm/boot/dts/armada-385-synology-ds116.dts
> index 6782ce481ac9..d8769956cbfc 100644
> --- a/arch/arm/boot/dts/armada-385-synology-ds116.dts
> +++ b/arch/arm/boot/dts/armada-385-synology-ds116.dts
> @@ -139,7 +139,7 @@
>  					      3700 5
>  					      3900 6
>  					      4000 7>;
> -			cooling-cells = <2>;
> +			#cooling-cells = <2>;
>  		};
>  
>  		gpio-leds {
> -- 
> 2.15.0.194.g9af6a3dea062
>

-- 
Gregory Clement, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

[PATCH 07/15] arm: dts: exynos: Add missing cooling device properties for CPUs

[Krzysztof Kozlowski]

On Fri, May 25, 2018 at 12:31 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> The cooling device properties, like "#cooling-cells" and
> "dynamic-power-coefficient", should either be present for all the CPUs
> of a cluster or none. If these are present only for a subset of CPUs of
> a cluster then things will start falling apart as soon as the CPUs are
> brought online in a different order.

Thanks for the patch.

In case of Exynos, the booting CPU always has these information in DT
and the booting CPU cannot be changed (chosen by firmware/hardware
configuration). Therefore there is no real risk of falling although
for correctness of DT your change makes sense.

It is too late for this cycle for me so I'll pick it up after merge window.
Alternatively, arm-soc guys can pick it up directly with my tag:
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>

Best regards,
Krzysztof


> For example, this will happen
> because the operating system looks for such properties in the CPU node
> it is trying to bring up, so that it can register a cooling device.
>
> Add such missing properties.
>
> Fix other missing properties (clocks, OPP, clock latency) as well to
> make it all work.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
>  arch/arm/boot/dts/exynos3250.dtsi | 16 ++++++++++++++++
>  arch/arm/boot/dts/exynos4210.dtsi | 13 +++++++++++++
>  arch/arm/boot/dts/exynos4412.dtsi |  9 +++++++++
>  arch/arm/boot/dts/exynos5250.dtsi | 23 +++++++++++++++++++++++
>  4 files changed, 61 insertions(+)
>

[PATCH 07/15] arm: dts: exynos: Add missing cooling device properties for CPUs

[Viresh Kumar]

On 29-05-18, 15:18, Krzysztof Kozlowski wrote:
> Thanks for the patch.
> 
> In case of Exynos, the booting CPU always has these information in DT
> and the booting CPU cannot be changed (chosen by firmware/hardware
> configuration).

But can the booting CPU be offlined ?

If yes, then this is how things are broken right now.

Build cpufreq driver as module, boot kernel, hotplug out CPU0, insert
cpufreq driver and that will try to find these properties in CPU1.

> Therefore there is no real risk of falling although
> for correctness of DT your change makes sense.
> 
> It is too late for this cycle for me so I'll pick it up after merge window.
> Alternatively, arm-soc guys can pick it up directly with my tag:
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>

No worries, you can pick it up later on.

-- 
viresh

[PATCH 07/15] arm: dts: exynos: Add missing cooling device properties for CPUs

[Krzysztof Kozlowski]

On Wed, May 30, 2018 at 6:38 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 29-05-18, 15:18, Krzysztof Kozlowski wrote:
>> Thanks for the patch.
>>
>> In case of Exynos, the booting CPU always has these information in DT
>> and the booting CPU cannot be changed (chosen by firmware/hardware
>> configuration).
>
> But can the booting CPU be offlined ?
>
> If yes, then this is how things are broken right now.
>
> Build cpufreq driver as module, boot kernel, hotplug out CPU0, insert
> cpufreq driver and that will try to find these properties in CPU1.

OK, I see the possibility although it is still far away from use
cases. You cannot hotplug booting CPU (CPU0) on Exynos kernels. It
never worked. Strictly speaking - offlining will work. But bringing it
online will likely hang the system.

Best regards,
Krzysztof

[PATCH 07/15] arm: dts: exynos: Add missing cooling device properties for CPUs

[Viresh Kumar]

On 30-05-18, 14:32, Krzysztof Kozlowski wrote:
> OK, I see the possibility although it is still far away from use
> cases. You cannot hotplug booting CPU (CPU0) on Exynos kernels. It
> never worked. Strictly speaking - offlining will work. But bringing it
> online will likely hang the system.

True and I used the following out of tree patch for a long time for my
dual A15 exynos to make hotplug work.

https://git.linaro.org/people/vireshk/backup/linux.git/commit/?h=bkp/exynos/hotplug&id=aab8a906a70b8f1fb15a4b7bd2ee27e6dcabf79d

-- 
viresh

[PATCH 05/15] arm: dts: uniphier: Add missing cooling device properties for CPUs

[Masahiro Yamada]

2018-05-25 19:31 GMT+09:00 Viresh Kumar <viresh.kumar@linaro.org>:
> The cooling device properties, like "#cooling-cells" and
> "dynamic-power-coefficient", should either be present for all the CPUs
> of a cluster or none. If these are present only for a subset of CPUs of
> a cluster then things will start falling apart as soon as the CPUs are
> brought online in a different order. For example, this will happen
> because the operating system looks for such properties in the CPU node
> it is trying to bring up, so that it can register a cooling device.
>
> Add such missing properties.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>


Applied to linux-uniphier.

I had already sent a PR for v4.18-rc1 before I received this patch.
Please wait for v4.19-rc1.

Thanks.


> ---
>  arch/arm/boot/dts/uniphier-pxs2.dtsi | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/boot/dts/uniphier-pxs2.dtsi b/arch/arm/boot/dts/uniphier-pxs2.dtsi
> index debcbd15c24b..40ed15465095 100644
> --- a/arch/arm/boot/dts/uniphier-pxs2.dtsi
> +++ b/arch/arm/boot/dts/uniphier-pxs2.dtsi
> @@ -36,6 +36,7 @@
>                         enable-method = "psci";
>                         next-level-cache = <&l2>;
>                         operating-points-v2 = <&cpu_opp>;
> +                       #cooling-cells = <2>;
>                 };
>
>                 cpu2: cpu at 2 {
> @@ -46,6 +47,7 @@
>                         enable-method = "psci";
>                         next-level-cache = <&l2>;
>                         operating-points-v2 = <&cpu_opp>;
> +                       #cooling-cells = <2>;
>                 };
>
>                 cpu3: cpu at 3 {
> @@ -56,6 +58,7 @@
>                         enable-method = "psci";
>                         next-level-cache = <&l2>;
>                         operating-points-v2 = <&cpu_opp>;
> +                       #cooling-cells = <2>;
>                 };
>         };
>
> --
> 2.15.0.194.g9af6a3dea062
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best Regards
Masahiro Yamada

[PATCH 06/15] arm: dts: sun: Add missing cooling device properties for CPUs

[Maxime Ripard]

Hi,

On Mon, May 28, 2018 at 04:27:34PM +0530, Viresh Kumar wrote:
> On 28-05-18, 10:44, Maxime Ripard wrote:
> > Hi,
> > 
> > On Fri, May 25, 2018 at 04:01:52PM +0530, Viresh Kumar wrote:
> > > The cooling device properties, like "#cooling-cells" and
> > > "dynamic-power-coefficient", should either be present for all the CPUs
> > > of a cluster or none. If these are present only for a subset of CPUs of
> > > a cluster then things will start falling apart as soon as the CPUs are
> > > brought online in a different order. For example, this will happen
> > > because the operating system looks for such properties in the CPU node
> > > it is trying to bring up, so that it can register a cooling device.
> > > 
> > > Add such missing properties.
> > > 
> > > Fix other missing properties (clocks, OPP, clock latency) as well to
> > > make it all work.
> > > 
> > > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> > 
> > The prefix should be sunxi and not sun, but it looks good to me
> > otherwise.
> > 
> > Let me know what your preferred merge method is.
> 
> Please pick it up directly and send it as part of your pull request.
> Do you want me to resend or can you fix the $subject ?

I just tried to apply it, and it failed. We have usually two different
PR for the H3 SoCs and the others. Could you split the H3 in a
separate patch (and fix the subject in the process?)

Thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180601/68b1a4e3/attachment.sig>

[PATCH V2 1/2] arm: dts: sun8i-h3: Add missing cooling device properties for CPUs

[Viresh Kumar]

The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.

Add such missing properties.

Fix other missing properties (clocks, clock-names) as well to make it all
work.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
V2: Separated patch for h3.

 arch/arm/boot/dts/sun8i-h3.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 41d57c76f290..9dff6887923c 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -84,21 +84,30 @@
 			compatible = "arm,cortex-a7";
 			device_type = "cpu";
 			reg = <1>;
+			clocks = <&ccu CLK_CPUX>;
+			clock-names = "cpu";
 			operating-points-v2 = <&cpu0_opp_table>;
+			#cooling-cells = <2>;
 		};
 
 		cpu at 2 {
 			compatible = "arm,cortex-a7";
 			device_type = "cpu";
 			reg = <2>;
+			clocks = <&ccu CLK_CPUX>;
+			clock-names = "cpu";
 			operating-points-v2 = <&cpu0_opp_table>;
+			#cooling-cells = <2>;
 		};
 
 		cpu at 3 {
 			compatible = "arm,cortex-a7";
 			device_type = "cpu";
 			reg = <3>;
+			clocks = <&ccu CLK_CPUX>;
+			clock-names = "cpu";
 			operating-points-v2 = <&cpu0_opp_table>;
+			#cooling-cells = <2>;
 		};
 	};
 
-- 
2.15.0.194.g9af6a3dea062

[PATCH V2 2/2] arm: dts: sunxi: Add missing cooling device properties for CPUs

[Viresh Kumar]

The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.

Add such missing properties.

Fix other missing properties (clocks, OPP, clock latency) as well to
make it all work.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
V2:
- Separated patch for h3
- Fixed subject s/sun/sunxi/

 arch/arm/boot/dts/sun6i-a31.dtsi | 30 ++++++++++++++++++++++++++++++
 arch/arm/boot/dts/sun7i-a20.dtsi | 13 +++++++++++++
 arch/arm/boot/dts/sun8i-a33.dtsi |  9 +++++++++
 3 files changed, 52 insertions(+)

diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index c72992556a86..debc0bf22ea3 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -119,18 +119,48 @@
 			compatible = "arm,cortex-a7";
 			device_type = "cpu";
 			reg = <1>;
+			clocks = <&ccu CLK_CPU>;
+			clock-latency = <244144>; /* 8 32k periods */
+			operating-points = <
+				/* kHz	  uV */
+				1008000	1200000
+				864000	1200000
+				720000	1100000
+				480000	1000000
+				>;
+			#cooling-cells = <2>;
 		};
 
 		cpu at 2 {
 			compatible = "arm,cortex-a7";
 			device_type = "cpu";
 			reg = <2>;
+			clocks = <&ccu CLK_CPU>;
+			clock-latency = <244144>; /* 8 32k periods */
+			operating-points = <
+				/* kHz	  uV */
+				1008000	1200000
+				864000	1200000
+				720000	1100000
+				480000	1000000
+				>;
+			#cooling-cells = <2>;
 		};
 
 		cpu at 3 {
 			compatible = "arm,cortex-a7";
 			device_type = "cpu";
 			reg = <3>;
+			clocks = <&ccu CLK_CPU>;
+			clock-latency = <244144>; /* 8 32k periods */
+			operating-points = <
+				/* kHz	  uV */
+				1008000	1200000
+				864000	1200000
+				720000	1100000
+				480000	1000000
+				>;
+			#cooling-cells = <2>;
 		};
 	};
 
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index e529e4ff2174..35372a0cfc8d 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -122,6 +122,19 @@
 			compatible = "arm,cortex-a7";
 			device_type = "cpu";
 			reg = <1>;
+			clocks = <&ccu CLK_CPU>;
+			clock-latency = <244144>; /* 8 32k periods */
+			operating-points = <
+				/* kHz	  uV */
+				960000	1400000
+				912000	1400000
+				864000	1300000
+				720000	1200000
+				528000	1100000
+				312000	1000000
+				144000	1000000
+				>;
+			#cooling-cells = <2>;
 		};
 	};
 
diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index 8d278ee001e9..4e92741b24a7 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -132,21 +132,30 @@
 		};
 
 		cpu at 1 {
+			clocks = <&ccu CLK_CPUX>;
+			clock-names = "cpu";
 			operating-points-v2 = <&cpu0_opp_table>;
+			#cooling-cells = <2>;
 		};
 
 		cpu at 2 {
 			compatible = "arm,cortex-a7";
 			device_type = "cpu";
 			reg = <2>;
+			clocks = <&ccu CLK_CPUX>;
+			clock-names = "cpu";
 			operating-points-v2 = <&cpu0_opp_table>;
+			#cooling-cells = <2>;
 		};
 
 		cpu at 3 {
 			compatible = "arm,cortex-a7";
 			device_type = "cpu";
 			reg = <3>;
+			clocks = <&ccu CLK_CPUX>;
+			clock-names = "cpu";
 			operating-points-v2 = <&cpu0_opp_table>;
+			#cooling-cells = <2>;
 		};
 	};
 
-- 
2.15.0.194.g9af6a3dea062

[PATCH V2 2/2] arm: dts: sunxi: Add missing cooling device properties for CPUs

[Maxime Ripard]

On Tue, Jun 05, 2018 at 10:17:49AM +0530, Viresh Kumar wrote:
> The cooling device properties, like "#cooling-cells" and
> "dynamic-power-coefficient", should either be present for all the CPUs
> of a cluster or none. If these are present only for a subset of CPUs of
> a cluster then things will start falling apart as soon as the CPUs are
> brought online in a different order. For example, this will happen
> because the operating system looks for such properties in the CPU node
> it is trying to bring up, so that it can register a cooling device.
> 
> Add such missing properties.
> 
> Fix other missing properties (clocks, OPP, clock latency) as well to
> make it all work.
> 
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>

Applied both, thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180605/15dccabc/attachment.sig>

[PATCH V2 2/2] arm: dts: sunxi: Add missing cooling device properties for CPUs

[Chen-Yu Tsai]

On Tue, Jun 5, 2018 at 3:11 PM, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> On Tue, Jun 05, 2018 at 10:17:49AM +0530, Viresh Kumar wrote:
>> The cooling device properties, like "#cooling-cells" and
>> "dynamic-power-coefficient", should either be present for all the CPUs
>> of a cluster or none. If these are present only for a subset of CPUs of
>> a cluster then things will start falling apart as soon as the CPUs are
>> brought online in a different order. For example, this will happen
>> because the operating system looks for such properties in the CPU node
>> it is trying to bring up, so that it can register a cooling device.
>>
>> Add such missing properties.
>>
>> Fix other missing properties (clocks, OPP, clock latency) as well to
>> make it all work.
>>
>> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
>
> Applied both, thanks!

Please fix the "ARM" prefix when applying. :)

ChenYu

[PATCH V2 2/2] arm: dts: sunxi: Add missing cooling device properties for CPUs

[Maxime Ripard]

On Wed, Jun 06, 2018 at 12:02:20AM +0800, Chen-Yu Tsai wrote:
> On Tue, Jun 5, 2018 at 3:11 PM, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > On Tue, Jun 05, 2018 at 10:17:49AM +0530, Viresh Kumar wrote:
> >> The cooling device properties, like "#cooling-cells" and
> >> "dynamic-power-coefficient", should either be present for all the CPUs
> >> of a cluster or none. If these are present only for a subset of CPUs of
> >> a cluster then things will start falling apart as soon as the CPUs are
> >> brought online in a different order. For example, this will happen
> >> because the operating system looks for such properties in the CPU node
> >> it is trying to bring up, so that it can register a cooling device.
> >>
> >> Add such missing properties.
> >>
> >> Fix other missing properties (clocks, OPP, clock latency) as well to
> >> make it all work.
> >>
> >> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> >
> > Applied both, thanks!
> 
> Please fix the "ARM" prefix when applying. :)

Done, thanks for the reminder :)

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180606/7503a1f4/attachment-0001.sig>

[PATCH 04/15] arm: dts: rk322x: Add missing cooling device properties for CPUs

[Heiko Stuebner]

Am Freitag, 25. Mai 2018, 12:31:50 CEST schrieb Viresh Kumar:
> The cooling device properties, like "#cooling-cells" and
> "dynamic-power-coefficient", should either be present for all the CPUs
> of a cluster or none. If these are present only for a subset of CPUs of
> a cluster then things will start falling apart as soon as the CPUs are
> brought online in a different order. For example, this will happen
> because the operating system looks for such properties in the CPU node
> it is trying to bring up, so that it can register a cooling device.
> 
> Add such missing properties.
> 
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>

applied for 4.19

Thanks
Heiko

[PATCH 10/15] arm: dts: rk3288: Add missing cooling device properties for CPUs

[Heiko Stuebner]

Am Freitag, 25. Mai 2018, 12:31:56 CEST schrieb Viresh Kumar:
> The cooling device properties, like "#cooling-cells" and
> "dynamic-power-coefficient", should either be present for all the CPUs
> of a cluster or none. If these are present only for a subset of CPUs of
> a cluster then things will start falling apart as soon as the CPUs are
> brought online in a different order. For example, this will happen
> because the operating system looks for such properties in the CPU node
> it is trying to bring up, so that it can register a cooling device.
> 
> Add such missing properties.
> 
> Fix other missing properties (clocks, OPP, clock latency) as well to
> make it all work.
> 
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>

applied for 4.19, after adapting the patch to the opp-v2 conversion
I Cc'ed you on [for your reference].


Thanks
Heiko

[PATCH 07/15] arm: dts: exynos: Add missing cooling device properties for CPUs

[Krzysztof Kozlowski]

On Fri, May 25, 2018 at 04:01:53PM +0530, Viresh Kumar wrote:
> The cooling device properties, like "#cooling-cells" and
> "dynamic-power-coefficient", should either be present for all the CPUs
> of a cluster or none. If these are present only for a subset of CPUs of
> a cluster then things will start falling apart as soon as the CPUs are
> brought online in a different order. For example, this will happen
> because the operating system looks for such properties in the CPU node
> it is trying to bring up, so that it can register a cooling device.
> 
> Add such missing properties.
> 
> Fix other missing properties (clocks, OPP, clock latency) as well to
> make it all work.
> 
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
>  arch/arm/boot/dts/exynos3250.dtsi | 16 ++++++++++++++++
>  arch/arm/boot/dts/exynos4210.dtsi | 13 +++++++++++++
>  arch/arm/boot/dts/exynos4412.dtsi |  9 +++++++++
>  arch/arm/boot/dts/exynos5250.dtsi | 23 +++++++++++++++++++++++
>  4 files changed, 61 insertions(+)
> 

Thanks, applied.

Best regards,
Krzysztof

[PATCH 03/15] arm: dts: mediatek: Add missing cooling device properties for CPUs

[Matthias Brugger]

On 25/05/18 12:31, Viresh Kumar wrote:
> The cooling device properties, like "#cooling-cells" and
> "dynamic-power-coefficient", should either be present for all the CPUs
> of a cluster or none. If these are present only for a subset of CPUs of
> a cluster then things will start falling apart as soon as the CPUs are
> brought online in a different order. For example, this will happen
> because the operating system looks for such properties in the CPU node
> it is trying to bring up, so that it can register a cooling device.
> 
> Add such missing properties.
> 
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>

pushed to v4.18-next/dts32

Thanks

> ---
>  arch/arm/boot/dts/mt7623.dtsi | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
> index d1eb123bc73b..1cdc346a05e8 100644
> --- a/arch/arm/boot/dts/mt7623.dtsi
> +++ b/arch/arm/boot/dts/mt7623.dtsi
> @@ -92,6 +92,7 @@
>  				 <&apmixedsys CLK_APMIXED_MAINPLL>;
>  			clock-names = "cpu", "intermediate";
>  			operating-points-v2 = <&cpu_opp_table>;
> +			#cooling-cells = <2>;
>  			clock-frequency = <1300000000>;
>  		};
>  
> @@ -103,6 +104,7 @@
>  				 <&apmixedsys CLK_APMIXED_MAINPLL>;
>  			clock-names = "cpu", "intermediate";
>  			operating-points-v2 = <&cpu_opp_table>;
> +			#cooling-cells = <2>;
>  			clock-frequency = <1300000000>;
>  		};
>  
> @@ -114,6 +116,7 @@
>  				 <&apmixedsys CLK_APMIXED_MAINPLL>;
>  			clock-names = "cpu", "intermediate";
>  			operating-points-v2 = <&cpu_opp_table>;
> +			#cooling-cells = <2>;
>  			clock-frequency = <1300000000>;
>  		};
>  	};
> 

[PATCH 12/15] arm: dts: highbank: Add missing OPP properties for CPUs

[Rob Herring]

On Fri, May 25, 2018 at 4:32 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> The OPP properties, like "operating-points", should either be present
> for all the CPUs of a cluster or none. If these are present only for a
> subset of CPUs of a cluster then things will start falling apart as soon
> as the CPUs are brought online in a different order. For example, this
> will happen because the operating system looks for such properties in
> the CPU node it is trying to bring up, so that it can create an OPP
> table.
>
> Add such missing properties.
>
> Fix other missing property (clock latency) as well to make it all
> work.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
>  arch/arm/boot/dts/highbank.dts | 30 ++++++++++++++++++++++++++++++
>  1 file changed, 30 insertions(+)

Acked-by: Rob Herring <robh@kernel.org>

ARM-SOC maintainers, Please apply this.

Rob

[PATCH 12/15] arm: dts: highbank: Add missing OPP properties for CPUs

[Olof Johansson]

On Mon, Jul 02, 2018 at 02:25:40PM -0600, Rob Herring wrote:
> On Fri, May 25, 2018 at 4:32 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
> >
> > The OPP properties, like "operating-points", should either be present
> > for all the CPUs of a cluster or none. If these are present only for a
> > subset of CPUs of a cluster then things will start falling apart as soon
> > as the CPUs are brought online in a different order. For example, this
> > will happen because the operating system looks for such properties in
> > the CPU node it is trying to bring up, so that it can create an OPP
> > table.
> >
> > Add such missing properties.
> >
> > Fix other missing property (clock latency) as well to make it all
> > work.
> >
> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> > ---
> >  arch/arm/boot/dts/highbank.dts | 30 ++++++++++++++++++++++++++++++
> >  1 file changed, 30 insertions(+)
> 
> Acked-by: Rob Herring <robh@kernel.org>
> 
> ARM-SOC maintainers, Please apply this.

Applied to next/dt.


-Olof

[PATCH 12/15] arm: dts: highbank: Add missing OPP properties for CPUs

[Viresh Kumar]

On 02-07-18, 16:27, Olof Johansson wrote:
> On Mon, Jul 02, 2018 at 02:25:40PM -0600, Rob Herring wrote:
> > On Fri, May 25, 2018 at 4:32 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > >
> > > The OPP properties, like "operating-points", should either be present
> > > for all the CPUs of a cluster or none. If these are present only for a
> > > subset of CPUs of a cluster then things will start falling apart as soon
> > > as the CPUs are brought online in a different order. For example, this
> > > will happen because the operating system looks for such properties in
> > > the CPU node it is trying to bring up, so that it can create an OPP
> > > table.
> > >
> > > Add such missing properties.
> > >
> > > Fix other missing property (clock latency) as well to make it all
> > > work.
> > >
> > > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> > > ---
> > >  arch/arm/boot/dts/highbank.dts | 30 ++++++++++++++++++++++++++++++
> > >  1 file changed, 30 insertions(+)
> > 
> > Acked-by: Rob Herring <robh@kernel.org>
> > 
> > ARM-SOC maintainers, Please apply this.
> 
> Applied to next/dt.

Thanks Olof.

Can you also apply other patches in this series, that haven't been
applied yet by SoC maintainers ? And same for the arm64 series..

-- 
viresh

[PATCH 15/15] arm: dts: imx: Add missing OPP properties for CPUs

[Shawn Guo]

On Mon, May 28, 2018 at 04:37:39PM +0530, Viresh Kumar wrote:
> Hi Lucas,
> 
> On 25-05-18, 13:46, Lucas Stach wrote:
> > This is a lot of duplicate information for what is effectively a shared
> >  cluster wide thing. This does absolutely not _feel_ right.
> 
> I cannot agree more :)
> 
> > What problem are you solving here? Why do we need all this duplicate
> > information? Why can't we fix it by falling back to looking at cpu0 if
> > needed?
> 
> Let me try explaining one of the problem scenarios to you as your
> platform is a single cluster one. Make cpufreq driver as module, don't
> insert it, hotplug out CPU0 and now insert the cpufreq driver. The
> cpufreq core will try adding the cpufreq policy for CPU1 but wouldn't
> find the required information in the DT node of CPU1 and so will fail
> or behave incorrectly.
> 
> We can't look at CPU0 as we don't know they are related at all.
> Nothing tells that to us. The right solution to fix the duplication is
> to move to OPP-v2 bindings, which allow us to create a single OPP
> table node and refer to it from all the CPU nodes. Because in case of
> imx platforms getting updated here, we use the old and some platforms
> specific frequency tables, we have to duplicate it everywhere.
> 
> But looking from DT otherwise, all the device should anyway have all
> the information required right in their node. That can be simplified
> with things like phandle to opp-v2 node, but still everything needs to
> be there. We shouldn't really rely on other CPU nodes to make it work.
> That would be an incomplete definition of the hardware IMHO.

Lucas,

Are you fine with the patch now considering the respond from Viresh?

Shawn

[PATCH 15/15] arm: dts: imx: Add missing OPP properties for CPUs

[Lucas Stach]

Hi Shawn,

Am Dienstag, den 03.07.2018, 15:12 +0800 schrieb Shawn Guo:
> On Mon, May 28, 2018 at 04:37:39PM +0530, Viresh Kumar wrote:
> > Hi Lucas,
> > 
> > On 25-05-18, 13:46, Lucas Stach wrote:
> > > This is a lot of duplicate information for what is effectively a shared
> > > ?cluster wide thing. This does absolutely not _feel_ right.
> > 
> > I cannot agree more :)
> > 
> > > What problem are you solving here? Why do we need all this duplicate
> > > information? Why can't we fix it by falling back to looking at cpu0 if
> > > needed?
> > 
> > Let me try explaining one of the problem scenarios to you as your
> > platform is a single cluster one. Make cpufreq driver as module, don't
> > insert it, hotplug out CPU0 and now insert the cpufreq driver. The
> > cpufreq core will try adding the cpufreq policy for CPU1 but wouldn't
> > find the required information in the DT node of CPU1 and so will fail
> > or behave incorrectly.
> > 
> > We can't look at CPU0 as we don't know they are related at all.
> > Nothing tells that to us. The right solution to fix the duplication is
> > to move to OPP-v2 bindings, which allow us to create a single OPP
> > table node and refer to it from all the CPU nodes. Because in case of
> > imx platforms getting updated here, we use the old and some platforms
> > specific frequency tables, we have to duplicate it everywhere.
> > 
> > But looking from DT otherwise, all the device should anyway have all
> > the information required right in their node. That can be simplified
> > with things like phandle to opp-v2 node, but still everything needs to
> > be there. We shouldn't really rely on other CPU nodes to make it work.
> > That would be an incomplete definition of the hardware IMHO.
> 
> Lucas,
> 
> Are you fine with the patch now considering the respond from Viresh?

I still don't like the huge duplication of information in the DT, but I
agree that it's currently necessary for correctness. Long term I hope
we can get away from cpufreq-imx6 and the custom SoC OPPs, which would
allow us to switch over to OPPv2.

So patch is:
Reluctantly-acked-by: Lucas Stach <l.stach@pengutronix.de>

Regards,
Lucas

[PATCH 15/15] arm: dts: imx: Add missing OPP properties for CPUs

[Shawn Guo]

On Fri, May 25, 2018 at 04:02:01PM +0530, Viresh Kumar wrote:
> The OPP properties, like "operating-points", should either be present
> for all the CPUs of a cluster or none. If these are present only for a
> subset of CPUs of a cluster then things will start falling apart as soon
> as the CPUs are brought online in a different order. For example, this
> will happen because the operating system looks for such properties in
> the CPU node it is trying to bring up, so that it can create an OPP
> table.
> 
> Add such missing properties.
> 
> Fix other missing properties (like clocks, supply, clock latency) as
> well to make it all work.
> 
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>

Applied, thanks.

[PATCH 12/15] arm: dts: highbank: Add missing OPP properties for CPUs

[Olof Johansson]

On Mon, Jul 2, 2018 at 9:13 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 02-07-18, 16:27, Olof Johansson wrote:
>> On Mon, Jul 02, 2018 at 02:25:40PM -0600, Rob Herring wrote:
>> > On Fri, May 25, 2018 at 4:32 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
>> > >
>> > > The OPP properties, like "operating-points", should either be present
>> > > for all the CPUs of a cluster or none. If these are present only for a
>> > > subset of CPUs of a cluster then things will start falling apart as soon
>> > > as the CPUs are brought online in a different order. For example, this
>> > > will happen because the operating system looks for such properties in
>> > > the CPU node it is trying to bring up, so that it can create an OPP
>> > > table.
>> > >
>> > > Add such missing properties.
>> > >
>> > > Fix other missing property (clock latency) as well to make it all
>> > > work.
>> > >
>> > > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
>> > > ---
>> > >  arch/arm/boot/dts/highbank.dts | 30 ++++++++++++++++++++++++++++++
>> > >  1 file changed, 30 insertions(+)
>> >
>> > Acked-by: Rob Herring <robh@kernel.org>
>> >
>> > ARM-SOC maintainers, Please apply this.
>>
>> Applied to next/dt.
>
> Thanks Olof.
>
> Can you also apply other patches in this series, that haven't been
> applied yet by SoC maintainers ? And same for the arm64 series..

This is the kind of patch that should be applied by the maintainers
for active platforms, where they have systems to test with and can
make sure you haven't regressed something on them.

For very low patch rate platforms we can apply directly through
maintainer acks, like in this case.

So, my recommendation is to repost the series to the maintainers.
Please don't patchbomb arm at kernel.org though, so keep us off of cc by
default (you can add our individual addresses if you want).


Thanks,

-Olof