[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@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 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@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

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[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 1/4] dt-bindings: gpu: add the RK3399 mali for rockchip specifics

[Caesar Wang]

RK3399's GPU uses the quad-core Mali-T860, which is the new generation of
high-end graphics processors from ARM.

This patch added "rockchip,rk3399-mali" for dt-bindings, in order to
support IPA of gpu thermal in later.

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

 Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
index d3b6e1a4..a461e47 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
@@ -17,6 +17,7 @@ Required properties:
   * which must be preceded by one of the following vendor specifics:
     + "amlogic,meson-gxm-mali"
     + "rockchip,rk3288-mali"
+    + "rockchip,rk3399-mali"
 
 - reg : Physical base address of the device and length of the register area.
 
-- 
2.7.4

[PATCH 1/4] dt-bindings: gpu: add the RK3399 mali for rockchip specifics

[Caesar Wang]

RK3399's GPU uses the quad-core Mali-T860, which is the new generation of
high-end graphics processors from ARM.

This patch added "rockchip,rk3399-mali" for dt-bindings, in order to
support IPA of gpu thermal in later.

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

 Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
index d3b6e1a4..a461e47 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
@@ -17,6 +17,7 @@ Required properties:
   * which must be preceded by one of the following vendor specifics:
     + "amlogic,meson-gxm-mali"
     + "rockchip,rk3288-mali"
+    + "rockchip,rk3399-mali"
 
 - reg : Physical base address of the device and length of the register area.
 
-- 
2.7.4

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[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@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

[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-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
---

 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@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

[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 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 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-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
---

 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 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@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@0 {
 					temperature = <70000>;
 					hysteresis = <2000>;
 					type = "passive";
 				};
-				cpu_alert1: cpu_alert1 {
-					temperature = <75000>;
+				target: trip-point@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

[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

Re: [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@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

Re: [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-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> ---
> 
>  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@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

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

[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

Re: [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@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@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [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-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>> ---
>>
>>   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@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-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip

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

[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

Re: [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@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

[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

Re: [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@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@0 {

foo@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@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 {
> 

Re: [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-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> 
> ---
> 
>  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@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@0 {

foo@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@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 {
> 


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

[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 {
> 

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

[Caesar Wang]

[-- Attachment #1: Type: text/plain, Size: 2210 bytes --]

Hi Brian,

锟斤拷 2017锟斤拷07锟斤拷13锟斤拷 01:32, 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@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 :)
*

*

The coefficient is used to calulate the dynamic power as below -
Pdyn= dynamic-power-coefficient * V^2 * f

The value was tested on rockchip inside, that should be resonable for me.
As the PLT tested the little cpu power comsumption Pl = 0.9mw, but big 
cpu power comsumption Pb= 0.28mw

-Caesar
>
>>   		};
>>   	};
>>   
> ...
>
> Brian
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip


[-- Attachment #2: Type: text/html, Size: 4096 bytes --]

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

[Caesar Wang]

[-- Attachment #1: Type: text/plain, Size: 6163 bytes --]

在 2017年07月13日 02:44, 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.
>

I believe the thermal IPA (Power allocator) is better governor on ARM 
SoCs,  you just override for dts if
someone want to use the other governors (step_wise, fair_share..)

The other rockchip SoCs also will support the power allocator governor 
later.

>> 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.

Will do.

>
>
>> 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@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@0 {
> foo@0 will produce warnings when used without reg property. Also,
> why all that renaming, the previous names sounded fine to me.

The IPA likes these name, as the 
Documentation/thermal/power_allocator.txt describes

>
>>   					temperature = <70000>;
>>   					hysteresis = <2000>;
>>   					type = "passive";
>>   				};
>> -				cpu_alert1: cpu_alert1 {
>> -					temperature = <75000>;
>> +				target: trip-point@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.

Think about the better performance, Intelligent Power Allocator should 
be enough safe for 80/85 degree.
That's also used on rockchip inside and chromeos4.4.

The Old limit followed up the rk3288 way before.

>>   					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?

The threshold is  "switch on" trip point that temperature above which 
the governor control loop starts operating.
That just for enabling the IPA.

The target is "desired temperature" trip point. The different is 
throttle the big with little cluster frequency.
Priority to reduce the frequency of little cluster for better performance.

>
>>   					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 :-) .

Will do.

Thanks,
Caesar

>
> Heiko
>
>> +			static-coefficient = <1079403>;
>> +			dynamic-coefficient = <977>;
>> +			ts = <32000 4700 (-80) 2>;
>> +			thermal-zone = "gpu-thermal";
>> +		};
>>   	};
>>   
>>   	pinctrl: pinctrl {
>>
>
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip


[-- Attachment #2: Type: text/html, Size: 8279 bytes --]