[PATCH 0/4] arm64: dts: rockchip: support mail and IPA thermal for rk3399

[PATCH 0/4] arm64: dts: rockchip: support mail and IPA thermal for rk3399

[Caesar Wang]

This series patches supported the mail in devicetree and used the
thermal IPA by default.

Verified with rk3399 kevin board on my github
https://github.com/Caesar-github/rockchip/commits/gru/next-stable-chromeos
The kernel is based on Linus's master branch and Heiko's
v4.14-armsoc-tmp/dts64 branch. ( The Linux version 4.12.0 for now).
---

Tested on Kevin board with bringing up ChromeOS.
OS VERSION:
    CHROMEOS_RELEASE_DESCRIPTION=9693.1.0 (Official Build) dev-channel kevin test

BIOS VERSION:
    Google_Kevin.8785.211.2017_06_20_1043

EC VERSION:
    Build info:    kevin_v1.10.217-24514961d 2017-07-03 07:46:36 wxt at nb

With the ARM's lastest mali driver TX011-SW-99002-r18p0-01rel0 on
https://developer.arm.com/products/software/mali-drivers/midgard-kernel

>From the bootup log:
    localhost devfreq0 # dmesg |grep mali
    [    0.933334] mali ff9a0000.gpu: GPU identified as 0x0860 r2p0 status 0
    [    0.940830] mali ff9a0000.gpu: Protected mode not available
    [    0.947334] mali ff9a0000.gpu: Using configured power model mali-simple-power-model, and fallback mali-simple-power-model
    [    0.960083] mali ff9a0000.gpu: Probed as mali0

    localhost devfreq0 # pwd
    /sys/devices/platform/ff9a0000.gpu/devfreq/devfreq0
    localhost devfreq0 # ls
    available_frequencies  device    min_freq          subsystem    uevent
    available_governors    governor  polling_interval  target_freq  userspace
    cur_freq               max_freq  power             trans_stat

    localhost ff9a0000.gpu # ls
    core_availability_policy  gpuinfo               modalias       soft_job_timeout
    core_mask                 js_scheduling_period  of_node        subsystem
    devfreq                   js_timeouts           pm_poweroff    uevent
    driver                    mem_pool_max_size     power
    driver_override           mem_pool_size         power_policy
    dvfs_period               misc                  reset_timeout
---

And for thermal with IPA.
Try to run 'md5sum /dev/zero &' and octane/benchmark scripts to go up the temperature.
>From the scripts to have a look at the actual control.
"
while true; do grep "" /sys/class/thermal/thermal_zone[0-1]/temp /sys/devices/system/cpu/cpu[0-5]/cpufreq/scaling_cur_freq /sys/devices/platform/ff9a0000.gpu/devfreq/ff9a0000.gpu/cur_freq;date;sleep .5; done &
"

-Caesar



Caesar Wang (4):
  dt-bindings: gpu: add the RK3399 mali for rockchip specifics
  arm64: dts: rockchip: add ARM Mali GPU node for RK3399 SoCs
  arm64: dts: rockchip: enable the GPU for RK3399-GRU
  arm64: dts: rockchip: update the thermal zones for RK3399 SoCs

 .../devicetree/bindings/gpu/arm,mali-midgard.txt   |  1 +
 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi       |  5 ++
 arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi   | 33 +++++++++
 arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi       | 33 +++++++++
 arch/arm64/boot/dts/rockchip/rk3399.dtsi           | 78 +++++++++++++---------
 5 files changed, 117 insertions(+), 33 deletions(-)

-- 
2.7.4

[PATCH 2/4] arm64: dts: rockchip: add ARM Mali GPU node for RK3399 SoCs

[Caesar Wang]

Add Mali GPU device tree node for the RK3399 SoCs, with devfreq
opp table.

RK3399 and RK3399-OP1 SoCs have a different recommendation table with
gpu opp. As the ARM's mali driver found on
https://developer.arm.com/products/software/mali-drivers/midgard-kernel.

Signed-off-by: Caesar Wang <wxt@rock-chips.com>
---

 arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi | 33 ++++++++++++++++++++++++
 arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi     | 33 ++++++++++++++++++++++++
 arch/arm64/boot/dts/rockchip/rk3399.dtsi         | 16 ++++++++++++
 3 files changed, 82 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi
index be7fe63..d8a120f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi
@@ -118,6 +118,35 @@
 			opp-microvolt = <1250000>;
 		};
 	};
+
+	gpu_opp_table: opp-table2 {
+		compatible = "operating-points-v2";
+
+		opp00 {
+			opp-hz = /bits/ 64 <200000000>;
+			opp-microvolt = <800000>;
+		};
+		opp01 {
+			opp-hz = /bits/ 64 <297000000>;
+			opp-microvolt = <800000>;
+		};
+		opp02 {
+			opp-hz = /bits/ 64 <400000000>;
+			opp-microvolt = <825000>;
+		};
+		opp03 {
+			opp-hz = /bits/ 64 <500000000>;
+			opp-microvolt = <850000>;
+		};
+		opp04 {
+			opp-hz = /bits/ 64 <600000000>;
+			opp-microvolt = <925000>;
+		};
+		opp05 {
+			opp-hz = /bits/ 64 <800000000>;
+			opp-microvolt = <1075000>;
+		};
+	};
 };
 
 &cpu_l0 {
@@ -143,3 +172,7 @@
 &cpu_b1 {
 	operating-points-v2 = <&cluster1_opp>;
 };
+
+&gpu {
+	operating-points-v2 = <&gpu_opp_table>;
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
index c83460d..81617bc 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
@@ -110,6 +110,35 @@
 			opp-microvolt = <1200000>;
 		};
 	};
+
+	gpu_opp_table: opp-table2 {
+		compatible = "operating-points-v2";
+
+		opp00 {
+			opp-hz = /bits/ 64 <200000000>;
+			opp-microvolt = <800000>;
+		};
+		opp01 {
+			opp-hz = /bits/ 64 <297000000>;
+			opp-microvolt = <800000>;
+		};
+		opp02 {
+			opp-hz = /bits/ 64 <400000000>;
+			opp-microvolt = <825000>;
+		};
+		opp03 {
+			opp-hz = /bits/ 64 <500000000>;
+			opp-microvolt = <875000>;
+		};
+		opp04 {
+			opp-hz = /bits/ 64 <600000000>;
+			opp-microvolt = <925000>;
+		};
+		opp05 {
+			opp-hz = /bits/ 64 <800000000>;
+			opp-microvolt = <1100000>;
+		};
+	};
 };
 
 &cpu_l0 {
@@ -135,3 +164,7 @@
 &cpu_b1 {
 	operating-points-v2 = <&cluster1_opp>;
 };
+
+&gpu {
+	operating-points-v2 = <&gpu_opp_table>;
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 1cbd7a2..8c6438b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1443,6 +1443,22 @@
 		status = "disabled";
 	};
 
+	gpu: gpu at ff9a0000 {
+		compatible = "arm,rk3399-mali",
+			     "arm,malit860",
+			     "arm,malit86x",
+			     "arm,malit8xx";
+		reg = <0x0 0xff9a0000 0x0 0x10000>;
+		interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH 0>;
+		interrupt-names = "GPU", "JOB", "MMU";
+		clocks = <&cru ACLK_GPU>;
+		clock-names = "clk_mali";
+		power-domains = <&power RK3399_PD_GPU>;
+		status = "disabled";
+	};
+
 	pinctrl: pinctrl {
 		compatible = "rockchip,rk3399-pinctrl";
 		rockchip,grf = <&grf>;
-- 
2.7.4

[PATCH 2/4] arm64: dts: rockchip: add ARM Mali GPU node for RK3399 SoCs

[Heiko Stuebner]

Hi Caesar,

Am Mittwoch, 12. Juli 2017, 14:29:28 CEST schrieb Caesar Wang:
> Add Mali GPU device tree node for the RK3399 SoCs, with devfreq
> opp table.
> 
> RK3399 and RK3399-OP1 SoCs have a different recommendation table with
> gpu opp. As the ARM's mali driver found on
> https://developer.arm.com/products/software/mali-drivers/midgard-kernel.
> 
> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
> ---
> 
>  arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi | 33 ++++++++++++++++++++++++
>  arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi     | 33 ++++++++++++++++++++++++
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi         | 16 ++++++++++++
>  3 files changed, 82 insertions(+)

[...]

> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> index 1cbd7a2..8c6438b 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -1443,6 +1443,22 @@
>  		status = "disabled";
>  	};
>  
> +	gpu: gpu at ff9a0000 {
> +		compatible = "arm,rk3399-mali",
> +			     "arm,malit860",
> +			     "arm,malit86x",
> +			     "arm,malit8xx";

no wildcards and correct compatibles please.
The binding specifies arm,mali-t860 for your chip and the soc
specific compatible needs a rockchip vendor, so you need

	compatible = "rockchip,rk3399-mali", "arm,mali-t860";


> +		reg = <0x0 0xff9a0000 0x0 0x10000>;
> +		interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH 0>;
> +		interrupt-names = "GPU", "JOB", "MMU";

interrupt names are job, mmu, gpu in lower case. The out-of-tree driver
will need to conform to that.

> +		clocks = <&cru ACLK_GPU>;
> +		clock-names = "clk_mali";

no clock-names property, as midgard malis only have one clock input


Heiko

[PATCH 2/4] arm64: dts: rockchip: add ARM Mali GPU node for RK3399 SoCs

[Caesar Wang]

? 2017?07?12? 15:19, Heiko Stuebner ??:
> Hi Caesar,
>
> Am Mittwoch, 12. Juli 2017, 14:29:28 CEST schrieb Caesar Wang:
>> Add Mali GPU device tree node for the RK3399 SoCs, with devfreq
>> opp table.
>>
>> RK3399 and RK3399-OP1 SoCs have a different recommendation table with
>> gpu opp. As the ARM's mali driver found on
>> https://developer.arm.com/products/software/mali-drivers/midgard-kernel.
>>
>> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
>> ---
>>
>>   arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi | 33 ++++++++++++++++++++++++
>>   arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi     | 33 ++++++++++++++++++++++++
>>   arch/arm64/boot/dts/rockchip/rk3399.dtsi         | 16 ++++++++++++
>>   3 files changed, 82 insertions(+)
> [...]
>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> index 1cbd7a2..8c6438b 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> @@ -1443,6 +1443,22 @@
>>   		status = "disabled";
>>   	};
>>   
>> +	gpu: gpu at ff9a0000 {
>> +		compatible = "arm,rk3399-mali",
>> +			     "arm,malit860",
>> +			     "arm,malit86x",
>> +			     "arm,malit8xx";
> no wildcards and correct compatibles please.
> The binding specifies arm,mali-t860 for your chip and the soc
> specific compatible needs a rockchip vendor, so you need
>
> 	compatible = "rockchip,rk3399-mali", "arm,mali-t860";
>

Okay,  sound resonable.

>> +		reg = <0x0 0xff9a0000 0x0 0x10000>;
>> +		interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH 0>,
>> +			     <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH 0>,
>> +			     <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH 0>;
>> +		interrupt-names = "GPU", "JOB", "MMU";
> interrupt names are job, mmu, gpu in lower case. The out-of-tree driver
> will need to conform to that.

Okay, we need update the ARM's mali driver to follow up.

>> +		clocks = <&cru ACLK_GPU>;
>> +		clock-names = "clk_mali";
> no clock-names property, as midgard malis only have one clock input

Sorry, I seem to be reference for the MAILI's document, not the Linux 
document.

Update these for patches v2.

Thanks your comments.

-Caesar

>
> Heiko
>
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip

[PATCH 3/4] arm64: dts: rockchip: enable the GPU for RK3399-GRU

[Caesar Wang]

This patch enables the gpu and adds the mali-supply power for RK3399-GRU
devices.

Signed-off-by: Caesar Wang <wxt@rock-chips.com>
---

 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index 90259cf..d48e98b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -595,6 +595,11 @@
 	status = "okay";
 };
 
+&gpu {
+	mali-supply = <&ppvar_gpu>;
+	status = "okay";
+};
+
 ap_i2c_mic: &i2c1 {
 	status = "okay";
 
-- 
2.7.4

[PATCH 4/4] arm64: dts: rockchip: update the thermal zones for RK3399 SoCs

[Caesar Wang]

As RK3399 had used the Power allocator thermal governor by default,
enabled this to manage thermals by dynamically allocating and limiting
power to devices.

Also, this patch supported the dynamic-power-coefficient/sustainable_power
and GPU's power model for needed parameters with thermal IPA.

Signed-off-by: Caesar Wang <wxt@rock-chips.com>

---

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 62 +++++++++++++++-----------------
 1 file changed, 29 insertions(+), 33 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 8c6438b..139f58c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -147,7 +147,7 @@
 			enable-method = "psci";
 			#cooling-cells = <2>; /* min followed by max */
 			clocks = <&cru ARMCLKB>;
-			dynamic-power-coefficient = <100>;
+			dynamic-power-coefficient = <436>;
 		};
 
 		cpu_b1: cpu at 101 {
@@ -156,7 +156,7 @@
 			reg = <0x0 0x101>;
 			enable-method = "psci";
 			clocks = <&cru ARMCLKB>;
-			dynamic-power-coefficient = <100>;
+			dynamic-power-coefficient = <436>;
 		};
 	};
 
@@ -690,24 +690,25 @@
 	};
 
 	thermal_zones: thermal-zones {
-		cpu_thermal: cpu {
+		soc_thermal: soc-thermal {
 			polling-delay-passive = <100>;
 			polling-delay = <1000>;
+			sustainable-power = <1000>;
 
 			thermal-sensors = <&tsadc 0>;
 
 			trips {
-				cpu_alert0: cpu_alert0 {
+				threshold: trip-point at 0 {
 					temperature = <70000>;
 					hysteresis = <2000>;
 					type = "passive";
 				};
-				cpu_alert1: cpu_alert1 {
-					temperature = <75000>;
+				target: trip-point at 1 {
+					temperature = <85000>;
 					hysteresis = <2000>;
 					type = "passive";
 				};
-				cpu_crit: cpu_crit {
+				soc_crit: soc-crit {
 					temperature = <95000>;
 					hysteresis = <2000>;
 					type = "critical";
@@ -716,45 +717,31 @@
 
 			cooling-maps {
 				map0 {
-					trip = <&cpu_alert0>;
+					trip = <&target>;
 					cooling-device =
-						<&cpu_b0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+						<&cpu_l0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+					contribution = <4096>;
 				};
 				map1 {
-					trip = <&cpu_alert1>;
+					trip = <&target>;
 					cooling-device =
-						<&cpu_l0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
 						<&cpu_b0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+					contribution = <1024>;
+				};
+				map2 {
+					trip = <&target>;
+					cooling-device =
+						<&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+					contribution = <4096>;
 				};
 			};
 		};
 
-		gpu_thermal: gpu {
+		gpu_thermal: gpu-thermal {
 			polling-delay-passive = <100>;
 			polling-delay = <1000>;
 
 			thermal-sensors = <&tsadc 1>;
-
-			trips {
-				gpu_alert0: gpu_alert0 {
-					temperature = <75000>;
-					hysteresis = <2000>;
-					type = "passive";
-				};
-				gpu_crit: gpu_crit {
-					temperature = <95000>;
-					hysteresis = <2000>;
-					type = "critical";
-				};
-			};
-
-			cooling-maps {
-				map0 {
-					trip = <&gpu_alert0>;
-					cooling-device =
-						<&cpu_b0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
-				};
-			};
 		};
 	};
 
@@ -1455,8 +1442,17 @@
 		interrupt-names = "GPU", "JOB", "MMU";
 		clocks = <&cru ACLK_GPU>;
 		clock-names = "clk_mali";
+		#cooling-cells = <2>;
 		power-domains = <&power RK3399_PD_GPU>;
 		status = "disabled";
+
+		gpu_power_model: power_model {
+			compatible = "arm,mali-simple-power-model";
+			static-coefficient = <1079403>;
+			dynamic-coefficient = <977>;
+			ts = <32000 4700 (-80) 2>;
+			thermal-zone = "gpu-thermal";
+		};
 	};
 
 	pinctrl: pinctrl {
-- 
2.7.4

[PATCH 4/4] arm64: dts: rockchip: update the thermal zones for RK3399 SoCs

[Brian Norris]

Hi Caesar,

On Wed, Jul 12, 2017 at 02:29:30PM +0800, Caesar Wang wrote:
> As RK3399 had used the Power allocator thermal governor by default,
> enabled this to manage thermals by dynamically allocating and limiting
> power to devices.
> 
> Also, this patch supported the dynamic-power-coefficient/sustainable_power
> and GPU's power model for needed parameters with thermal IPA.
> 
> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
> 
> ---
> 
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 62 +++++++++++++++-----------------
>  1 file changed, 29 insertions(+), 33 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> index 8c6438b..139f58c 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -147,7 +147,7 @@
>  			enable-method = "psci";
>  			#cooling-cells = <2>; /* min followed by max */
>  			clocks = <&cru ARMCLKB>;
> -			dynamic-power-coefficient = <100>;
> +			dynamic-power-coefficient = <436>;
>  		};
>  
>  		cpu_b1: cpu at 101 {
> @@ -156,7 +156,7 @@
>  			reg = <0x0 0x101>;
>  			enable-method = "psci";
>  			clocks = <&cru ARMCLKB>;
> -			dynamic-power-coefficient = <100>;
> +			dynamic-power-coefficient = <436>;

There are 6 of these properties (1 for each core now; not just 1 for
each cluster), and you're only changing 2 of them.

BTW, are these values determined from measurement this time? And heavily
tested? The previous values were suspiciously round, but they'd been
heavily tested so I didn't mind :)

>  		};
>  	};
>  

...

Brian

[PATCH 4/4] arm64: dts: rockchip: update the thermal zones for RK3399 SoCs

[Heiko Stuebner]

Hi Caesar,

Am Mittwoch, 12. Juli 2017, 14:29:30 CEST schrieb Caesar Wang:
> As RK3399 had used the Power allocator thermal governor by default,
> enabled this to manage thermals by dynamically allocating and limiting
> power to devices.

Does this still run with other thermal governors? The devicetree describes
the hardware, but should not mandate or exclude specific implementations.


> Also, this patch supported the dynamic-power-coefficient/sustainable_power
> and GPU's power model for needed parameters with thermal IPA.

As written below, this doesn't look like a reviewed binding (otherwise
please point me to the binding patch), but even if it is a real binding
it should get its separate patch.


> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
> 
> ---
> 
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 62 +++++++++++++++-----------------
>  1 file changed, 29 insertions(+), 33 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> index 8c6438b..139f58c 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -147,7 +147,7 @@
>  			enable-method = "psci";
>  			#cooling-cells = <2>; /* min followed by max */
>  			clocks = <&cru ARMCLKB>;
> -			dynamic-power-coefficient = <100>;
> +			dynamic-power-coefficient = <436>;
>  		};
>  
>  		cpu_b1: cpu at 101 {
> @@ -156,7 +156,7 @@
>  			reg = <0x0 0x101>;
>  			enable-method = "psci";
>  			clocks = <&cru ARMCLKB>;
> -			dynamic-power-coefficient = <100>;
> +			dynamic-power-coefficient = <436>;
>  		};
>  	};
>  
> @@ -690,24 +690,25 @@
>  	};
>  
>  	thermal_zones: thermal-zones {
> -		cpu_thermal: cpu {
> +		soc_thermal: soc-thermal {
>  			polling-delay-passive = <100>;
>  			polling-delay = <1000>;
> +			sustainable-power = <1000>;
>  
>  			thermal-sensors = <&tsadc 0>;
>  
>  			trips {
> -				cpu_alert0: cpu_alert0 {
> +				threshold: trip-point at 0 {

foo at 0 will produce warnings when used without reg property. Also,
why all that renaming, the previous names sounded fine to me.


>  					temperature = <70000>;
>  					hysteresis = <2000>;
>  					type = "passive";
>  				};
> -				cpu_alert1: cpu_alert1 {
> -					temperature = <75000>;
> +				target: trip-point at 1 {
> +					temperature = <85000>;

When raising the target-temperature to 85 degrees I really
do expect some sort of reassurement in the commit message
why that is really safe - especially when the old limit was 10 degrees
lower.

>  					hysteresis = <2000>;
>  					type = "passive";
>  				};
> -				cpu_crit: cpu_crit {
> +				soc_crit: soc-crit {
>  					temperature = <95000>;
>  					hysteresis = <2000>;
>  					type = "critical";
> @@ -716,45 +717,31 @@
>  
>  			cooling-maps {
>  				map0 {
> -					trip = <&cpu_alert0>;
> +					trip = <&target>;
>  					cooling-device =
> -						<&cpu_b0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> +						<&cpu_l0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> +					contribution = <4096>;
>  				};
>  				map1 {
> -					trip = <&cpu_alert1>;
> +					trip = <&target>;

Is it correct to use the _same_ trip point all the time? ... what about
the threshold and soc_crit ones?

>  					cooling-device =
> -						<&cpu_l0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
>  						<&cpu_b0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> +					contribution = <1024>;
> +				};
> +				map2 {
> +					trip = <&target>;
> +					cooling-device =
> +						<&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> +					contribution = <4096>;
>  				};
>  			};
>  		};
>  
> -		gpu_thermal: gpu {
> +		gpu_thermal: gpu-thermal {
>  			polling-delay-passive = <100>;
>  			polling-delay = <1000>;
>  
>  			thermal-sensors = <&tsadc 1>;
> -
> -			trips {
> -				gpu_alert0: gpu_alert0 {
> -					temperature = <75000>;
> -					hysteresis = <2000>;
> -					type = "passive";
> -				};
> -				gpu_crit: gpu_crit {
> -					temperature = <95000>;
> -					hysteresis = <2000>;
> -					type = "critical";
> -				};
> -			};
> -
> -			cooling-maps {
> -				map0 {
> -					trip = <&gpu_alert0>;
> -					cooling-device =
> -						<&cpu_b0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> -				};
> -			};
>  		};
>  	};
>  
> @@ -1455,8 +1442,17 @@
>  		interrupt-names = "GPU", "JOB", "MMU";
>  		clocks = <&cru ACLK_GPU>;
>  		clock-names = "clk_mali";
> +		#cooling-cells = <2>;
>  		power-domains = <&power RK3399_PD_GPU>;
>  		status = "disabled";
> +
> +		gpu_power_model: power_model {
> +			compatible = "arm,mali-simple-power-model";

Is this binding documented / reviewed somewhere? Because it looks
quite suspcicious :-) .


Heiko

> +			static-coefficient = <1079403>;
> +			dynamic-coefficient = <977>;
> +			ts = <32000 4700 (-80) 2>;
> +			thermal-zone = "gpu-thermal";
> +		};
>  	};
>  
>  	pinctrl: pinctrl {
>