Hi,
This series brings couple corrections and improvements to the device-trees
of Acer A500, AC100 and Nexus 7 devices. It also corrects polarity of
headphones-detection GPIO in all Tegra device-trees that use WM8903 audio
codec.
Dmitry Osipenko (10):
ARM: tegra: acer-a500: Improve microphone detection
ARM: tegra: acer-a500: Specify proper voltage for WiFi SDIO bus
ARM: tegra: acer-a500: Bump thermal trips by 10C
ARM: tegra: Add reg property to Tegra20 EMC table device-tree nodes
ARM: tegra: wm8903: Fix polarity of headphones-detection GPIO in
device-trees
ARM: tegra: paz00: Add CPU thermal zone
ARM: tegra: nexus7: Add i2c-thermtrip node
ARM: tegra: nexus7: Improve thermal zones
ARM: tegra: nexus7: Remove monitored-battery property
ARM: tegra: nexus7: Correct 3v3 regulator GPIO of PM269 variant
.../boot/dts/tegra20-acer-a500-picasso.dts | 21 ++++++---
arch/arm/boot/dts/tegra20-harmony.dts | 2 +-
arch/arm/boot/dts/tegra20-medcom-wide.dts | 2 +-
arch/arm/boot/dts/tegra20-paz00.dts | 43 ++++++++++++++++++-
arch/arm/boot/dts/tegra20-plutux.dts | 2 +-
arch/arm/boot/dts/tegra20-seaboard.dts | 2 +-
arch/arm/boot/dts/tegra20-tec.dts | 2 +-
arch/arm/boot/dts/tegra20-ventana.dts | 2 +-
.../tegra30-asus-nexus7-grouper-common.dtsi | 12 +-----
...egra30-asus-nexus7-grouper-maxim-pmic.dtsi | 9 ++++
.../tegra30-asus-nexus7-grouper-ti-pmic.dtsi | 11 ++++-
arch/arm/boot/dts/tegra30-cardhu.dtsi | 2 +-
12 files changed, 83 insertions(+), 27 deletions(-)
--
2.30.2
Tegra20 has v2.00 SDMMC controller which doesn't support voltage
switching and the WiFi SDIO bus voltage is fixed to 1.8v in accordance
to the board's schematics, while MMC core confusingly saying that it's
3.3v because of the v2.00. Let's correct the voltage in the device-tree
just for consistency. This is a minor improvement which doesn't fix any
problems.
Signed-off-by: Dmitry Osipenko <[email protected]>
---
arch/arm/boot/dts/tegra20-acer-a500-picasso.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts b/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts
index d7d97b7e4794..eff9bfb2d442 100644
--- a/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts
+++ b/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts
@@ -762,7 +762,7 @@ sdmmc1: mmc@c8000000 {
mmc-pwrseq = <&brcm_wifi_pwrseq>;
vmmc-supply = <&vdd_3v3_sys>;
- vqmmc-supply = <&vdd_3v3_sys>;
+ vqmmc-supply = <&vdd_1v8_sys>;
/* Azurewave AW-NH611 BCM4329 */
wifi@1 {
--
2.30.2
It's possible to hit the temperature of the thermal zone in a very warm
environment under a constant load, like watching a video using software
decoding. It's even easier to hit the limit with a slightly overclocked
CPU. Bump the temperature limit by 10C in order to improve user
experience. Acer A500 has a large board and 10" display panel which are
used for the heat dissipation, the SoC is placed far away from battery,
hence we can safely bump the temperature limit.
Signed-off-by: Dmitry Osipenko <[email protected]>
---
arch/arm/boot/dts/tegra20-acer-a500-picasso.dts | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts b/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts
index eff9bfb2d442..15b7965599ee 100644
--- a/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts
+++ b/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts
@@ -1059,15 +1059,15 @@ cpu-thermal {
trips {
trip0: cpu-alert0 {
- /* start throttling at 50C */
- temperature = <50000>;
+ /* start throttling at 60C */
+ temperature = <60000>;
hysteresis = <200>;
type = "passive";
};
trip1: cpu-crit {
- /* shut down at 60C */
- temperature = <60000>;
+ /* shut down at 70C */
+ temperature = <70000>;
hysteresis = <2000>;
type = "critical";
};
--
2.30.2
The reg property is now specified for the emc-tables nodes in the Tegra20
device-tree binding. Add reg property to the EMC table device-tree nodes
of Tegra20 board device-trees in order to silence dt_binding_check warning
about the missing property.
Signed-off-by: Dmitry Osipenko <[email protected]>
---
arch/arm/boot/dts/tegra20-acer-a500-picasso.dts | 4 ++++
arch/arm/boot/dts/tegra20-paz00.dts | 1 +
2 files changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts b/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts
index 15b7965599ee..883b76f1039b 100644
--- a/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts
+++ b/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts
@@ -1088,6 +1088,7 @@ memory-controller@7000f400 {
emc-tables@0 {
nvidia,ram-code = <0>; /* elpida-8gb */
+ reg = <0>;
#address-cells = <1>;
#size-cells = <0>;
@@ -1185,6 +1186,7 @@ emc-table@300000 {
emc-tables@1 {
nvidia,ram-code = <1>; /* elpida-4gb */
+ reg = <1>;
#address-cells = <1>;
#size-cells = <0>;
@@ -1282,6 +1284,7 @@ emc-table@300000 {
emc-tables@2 {
nvidia,ram-code = <2>; /* hynix-8gb */
+ reg = <2>;
#address-cells = <1>;
#size-cells = <0>;
@@ -1379,6 +1382,7 @@ emc-table@300000 {
emc-tables@3 {
nvidia,ram-code = <3>; /* hynix-4gb */
+ reg = <3>;
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/tegra20-paz00.dts b/arch/arm/boot/dts/tegra20-paz00.dts
index 940a9f31cd86..63d62418d4b8 100644
--- a/arch/arm/boot/dts/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/tegra20-paz00.dts
@@ -318,6 +318,7 @@ emc-tables@0 {
nvidia,ram-code = <0x0>;
#address-cells = <1>;
#size-cells = <0>;
+ reg = <0>;
emc-table@166500 {
reg = <166500>;
--
2.30.2
All Tegra boards which use WM8903 audio codec are specifying a wrong
polarity for the headphones detection GPIO. The kernel driver hardcodes
the polarity to active-low, which is the correct polarity, so we can fix
the device-trees safely.
Signed-off-by: Dmitry Osipenko <[email protected]>
---
arch/arm/boot/dts/tegra20-acer-a500-picasso.dts | 2 +-
arch/arm/boot/dts/tegra20-harmony.dts | 2 +-
arch/arm/boot/dts/tegra20-medcom-wide.dts | 2 +-
arch/arm/boot/dts/tegra20-plutux.dts | 2 +-
arch/arm/boot/dts/tegra20-seaboard.dts | 2 +-
arch/arm/boot/dts/tegra20-tec.dts | 2 +-
arch/arm/boot/dts/tegra20-ventana.dts | 2 +-
arch/arm/boot/dts/tegra30-cardhu.dtsi | 2 +-
8 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts b/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts
index 883b76f1039b..1976c383912a 100644
--- a/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts
+++ b/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts
@@ -1033,7 +1033,7 @@ sound {
nvidia,audio-codec = <&wm8903>;
nvidia,spkr-en-gpios = <&wm8903 2 GPIO_ACTIVE_HIGH>;
- nvidia,hp-det-gpios = <&gpio TEGRA_GPIO(W, 2) GPIO_ACTIVE_HIGH>;
+ nvidia,hp-det-gpios = <&gpio TEGRA_GPIO(W, 2) GPIO_ACTIVE_LOW>;
nvidia,int-mic-en-gpios = <&wm8903 1 GPIO_ACTIVE_HIGH>;
nvidia,headset;
diff --git a/arch/arm/boot/dts/tegra20-harmony.dts b/arch/arm/boot/dts/tegra20-harmony.dts
index 86494cb4d5a1..ae4312eedcbd 100644
--- a/arch/arm/boot/dts/tegra20-harmony.dts
+++ b/arch/arm/boot/dts/tegra20-harmony.dts
@@ -748,7 +748,7 @@ sound {
nvidia,spkr-en-gpios = <&wm8903 2 GPIO_ACTIVE_HIGH>;
nvidia,hp-det-gpios = <&gpio TEGRA_GPIO(W, 2)
- GPIO_ACTIVE_HIGH>;
+ GPIO_ACTIVE_LOW>;
nvidia,int-mic-en-gpios = <&gpio TEGRA_GPIO(X, 0)
GPIO_ACTIVE_HIGH>;
nvidia,ext-mic-en-gpios = <&gpio TEGRA_GPIO(X, 1)
diff --git a/arch/arm/boot/dts/tegra20-medcom-wide.dts b/arch/arm/boot/dts/tegra20-medcom-wide.dts
index a348ca30e522..b31c9bca16e6 100644
--- a/arch/arm/boot/dts/tegra20-medcom-wide.dts
+++ b/arch/arm/boot/dts/tegra20-medcom-wide.dts
@@ -84,7 +84,7 @@ sound {
nvidia,audio-codec = <&wm8903>;
nvidia,spkr-en-gpios = <&wm8903 2 GPIO_ACTIVE_HIGH>;
- nvidia,hp-det-gpios = <&gpio TEGRA_GPIO(W, 2) GPIO_ACTIVE_HIGH>;
+ nvidia,hp-det-gpios = <&gpio TEGRA_GPIO(W, 2) GPIO_ACTIVE_LOW>;
clocks = <&tegra_car TEGRA20_CLK_PLL_A>,
<&tegra_car TEGRA20_CLK_PLL_A_OUT0>,
diff --git a/arch/arm/boot/dts/tegra20-plutux.dts b/arch/arm/boot/dts/tegra20-plutux.dts
index 378f23b2958b..5811b7006a9b 100644
--- a/arch/arm/boot/dts/tegra20-plutux.dts
+++ b/arch/arm/boot/dts/tegra20-plutux.dts
@@ -52,7 +52,7 @@ sound {
nvidia,audio-codec = <&wm8903>;
nvidia,spkr-en-gpios = <&wm8903 2 GPIO_ACTIVE_HIGH>;
- nvidia,hp-det-gpios = <&gpio TEGRA_GPIO(W, 2) GPIO_ACTIVE_HIGH>;
+ nvidia,hp-det-gpios = <&gpio TEGRA_GPIO(W, 2) GPIO_ACTIVE_LOW>;
clocks = <&tegra_car TEGRA20_CLK_PLL_A>,
<&tegra_car TEGRA20_CLK_PLL_A_OUT0>,
diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts b/arch/arm/boot/dts/tegra20-seaboard.dts
index c24d4a37613e..92d494b8c3d2 100644
--- a/arch/arm/boot/dts/tegra20-seaboard.dts
+++ b/arch/arm/boot/dts/tegra20-seaboard.dts
@@ -911,7 +911,7 @@ sound {
nvidia,audio-codec = <&wm8903>;
nvidia,spkr-en-gpios = <&wm8903 2 GPIO_ACTIVE_HIGH>;
- nvidia,hp-det-gpios = <&gpio TEGRA_GPIO(X, 1) GPIO_ACTIVE_HIGH>;
+ nvidia,hp-det-gpios = <&gpio TEGRA_GPIO(X, 1) GPIO_ACTIVE_LOW>;
clocks = <&tegra_car TEGRA20_CLK_PLL_A>,
<&tegra_car TEGRA20_CLK_PLL_A_OUT0>,
diff --git a/arch/arm/boot/dts/tegra20-tec.dts b/arch/arm/boot/dts/tegra20-tec.dts
index 44ced60315de..10ff09d86efa 100644
--- a/arch/arm/boot/dts/tegra20-tec.dts
+++ b/arch/arm/boot/dts/tegra20-tec.dts
@@ -61,7 +61,7 @@ sound {
nvidia,spkr-en-gpios = <&wm8903 2 GPIO_ACTIVE_HIGH>;
nvidia,hp-det-gpios = <&gpio TEGRA_GPIO(W, 2)
- GPIO_ACTIVE_HIGH>;
+ GPIO_ACTIVE_LOW>;
clocks = <&tegra_car TEGRA20_CLK_PLL_A>,
<&tegra_car TEGRA20_CLK_PLL_A_OUT0>,
diff --git a/arch/arm/boot/dts/tegra20-ventana.dts b/arch/arm/boot/dts/tegra20-ventana.dts
index 99a356c1ccec..5a2578b3707f 100644
--- a/arch/arm/boot/dts/tegra20-ventana.dts
+++ b/arch/arm/boot/dts/tegra20-ventana.dts
@@ -709,7 +709,7 @@ sound {
nvidia,audio-codec = <&wm8903>;
nvidia,spkr-en-gpios = <&wm8903 2 GPIO_ACTIVE_HIGH>;
- nvidia,hp-det-gpios = <&gpio TEGRA_GPIO(W, 2) GPIO_ACTIVE_HIGH>;
+ nvidia,hp-det-gpios = <&gpio TEGRA_GPIO(W, 2) GPIO_ACTIVE_LOW>;
nvidia,int-mic-en-gpios = <&gpio TEGRA_GPIO(X, 0)
GPIO_ACTIVE_HIGH>;
nvidia,ext-mic-en-gpios = <&gpio TEGRA_GPIO(X, 1)
diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi
index 2dff14b87f3e..d9dd11569d4b 100644
--- a/arch/arm/boot/dts/tegra30-cardhu.dtsi
+++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi
@@ -630,7 +630,7 @@ sound {
nvidia,spkr-en-gpios = <&wm8903 2 GPIO_ACTIVE_HIGH>;
nvidia,hp-det-gpios = <&gpio TEGRA_GPIO(W, 2)
- GPIO_ACTIVE_HIGH>;
+ GPIO_ACTIVE_LOW>;
clocks = <&tegra_car TEGRA30_CLK_PLL_A>,
<&tegra_car TEGRA30_CLK_PLL_A_OUT0>,
--
2.30.2
Add i2c-thermtrip node which enables emergency shutdown by PMC on
SoC die overheat detected by TSENSOR.
Signed-off-by: Dmitry Osipenko <[email protected]>
---
.../boot/dts/tegra30-asus-nexus7-grouper-maxim-pmic.dtsi | 9 +++++++++
.../boot/dts/tegra30-asus-nexus7-grouper-ti-pmic.dtsi | 9 +++++++++
2 files changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-maxim-pmic.dtsi b/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-maxim-pmic.dtsi
index 17b6682ffce8..53966fa4eef2 100644
--- a/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-maxim-pmic.dtsi
+++ b/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-maxim-pmic.dtsi
@@ -182,4 +182,13 @@ regulator@4 {
enable-active-high;
vin-supply = <&vdd_3v3_sys>;
};
+
+ pmc@7000e400 {
+ i2c-thermtrip {
+ nvidia,i2c-controller-id = <4>;
+ nvidia,bus-addr = <0x3c>;
+ nvidia,reg-addr = <0x41>;
+ nvidia,reg-data = <0xe0>;
+ };
+ };
};
diff --git a/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-ti-pmic.dtsi b/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-ti-pmic.dtsi
index b97da45ebdb4..06b5e8a5ce5d 100644
--- a/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-ti-pmic.dtsi
+++ b/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-ti-pmic.dtsi
@@ -147,4 +147,13 @@ vdd_3v3_sys: regulator@1 {
gpio = <&pmic 7 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
+
+ pmc@7000e400 {
+ i2c-thermtrip {
+ nvidia,i2c-controller-id = <4>;
+ nvidia,bus-addr = <0x2d>;
+ nvidia,reg-addr = <0x3f>;
+ nvidia,reg-data = <0x80>;
+ };
+ };
};
--
2.30.2
Remove unused thermal zone just to clean up device-tree and set critical
temperature further apart from the passive cooling trip point since
during or thermal testing of Asus Transformer devices we found that CPU
could reach the critical temperature in a certain kernel configurations
for a brief moment if critical trip point is set close to the passive
trip point and then device will be immediately shut off without getting
a chance to cool down using passive cooling.
Signed-off-by: Dmitry Osipenko <[email protected]>
---
.../boot/dts/tegra30-asus-nexus7-grouper-common.dtsi | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-common.dtsi b/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-common.dtsi
index dc773b1bf8ee..3376d06facbb 100644
--- a/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-common.dtsi
+++ b/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-common.dtsi
@@ -1252,13 +1252,6 @@ sound {
};
thermal-zones {
- skin-thermal {
- polling-delay-passive = <1000>; /* milliseconds */
- polling-delay = <0>; /* milliseconds */
-
- thermal-sensors = <&nct72 0>;
- };
-
cpu-thermal {
polling-delay-passive = <1000>; /* milliseconds */
polling-delay = <5000>; /* milliseconds */
@@ -1274,8 +1267,8 @@ trip0: cpu-alert0 {
};
trip1: cpu-crit {
- /* shut down at 60C */
- temperature = <60000>;
+ /* shut down at 65C */
+ temperature = <65000>;
hysteresis = <2000>;
type = "critical";
};
--
2.30.2
The bq27541 Linux kernel driver will try to reprogram controller based
on the values from monitored-battery node, but it fails to do so because
controller was locked by manufacturer. Still this is a very undesirable
behaviour, hence let's remove the optional battery node.
Signed-off-by: Dmitry Osipenko <[email protected]>
---
arch/arm/boot/dts/tegra30-asus-nexus7-grouper-common.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-common.dtsi b/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-common.dtsi
index 3376d06facbb..c6264738f593 100644
--- a/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-common.dtsi
+++ b/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-common.dtsi
@@ -927,7 +927,6 @@ fuel-gauge@55 {
compatible = "ti,bq27541";
reg = <0x55>;
power-supplies = <&power_supply>;
- monitored-battery = <&battery_cell>;
};
power_supply: charger@6a {
--
2.30.2
Add thermal zone with a passive cooling trip for CPU. Attach it to the
LM90 sensor which monitors CPU temperature. Now CPU frequencies will be
throttled once trip point is reached, preventing critical overheat.
Tested-by: Agneli <[email protected]>
Tested-by: Paul Fertser <[email protected]>
Signed-off-by: Dmitry Osipenko <[email protected]>
---
arch/arm/boot/dts/tegra20-paz00.dts | 42 +++++++++++++++++++++++++++--
1 file changed, 40 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/tegra20-paz00.dts b/arch/arm/boot/dts/tegra20-paz00.dts
index 63d62418d4b8..3180bff90756 100644
--- a/arch/arm/boot/dts/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/tegra20-paz00.dts
@@ -2,6 +2,8 @@
/dts-v1/;
#include <dt-bindings/input/input.h>
+#include <dt-bindings/thermal/thermal.h>
+
#include "tegra20.dtsi"
#include "tegra20-cpu-opp.dtsi"
#include "tegra20-cpu-opp-microvolt.dtsi"
@@ -498,9 +500,10 @@ ldo_rtc {
};
};
- adt7461@4c {
+ adt7461: temperature-sensor@4c {
compatible = "adi,adt7461";
reg = <0x4c>;
+ #thermal-sensor-cells = <1>;
};
};
@@ -655,11 +658,46 @@ cpus {
cpu0: cpu@0 {
cpu-supply = <&cpu_vdd_reg>;
operating-points-v2 = <&cpu0_opp_table>;
+ #cooling-cells = <2>;
};
- cpu@1 {
+ cpu1: cpu@1 {
cpu-supply = <&cpu_vdd_reg>;
operating-points-v2 = <&cpu0_opp_table>;
+ #cooling-cells = <2>;
+ };
+ };
+
+ thermal-zones {
+ cpu-thermal {
+ polling-delay-passive = <500>; /* milliseconds */
+ polling-delay = <1500>; /* milliseconds */
+
+ thermal-sensors = <&adt7461 1>;
+
+ trips {
+ trip0: cpu-alert0 {
+ /* start throttling at 80C */
+ temperature = <80000>;
+ hysteresis = <200>;
+ type = "passive";
+ };
+
+ trip1: cpu-crit {
+ /* shut down at 85C */
+ temperature = <85000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map0 {
+ trip = <&trip0>;
+ cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
};
};
};
--
2.30.2
The 3v3 regulator GPIO is GP6 and not GP7, which is the DDR regulator.
Both regulators are always-on, nevertheless the DT model needs to be
corrected, fix it.
Reported-by: Svyatoslav Ryhel <[email protected]>
Signed-off-by: Dmitry Osipenko <[email protected]>
---
arch/arm/boot/dts/tegra30-asus-nexus7-grouper-ti-pmic.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-ti-pmic.dtsi b/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-ti-pmic.dtsi
index 06b5e8a5ce5d..9365ae607239 100644
--- a/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-ti-pmic.dtsi
+++ b/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-ti-pmic.dtsi
@@ -144,7 +144,7 @@ vdd_core: core-regulator@60 {
};
vdd_3v3_sys: regulator@1 {
- gpio = <&pmic 7 GPIO_ACTIVE_HIGH>;
+ gpio = <&pmic 6 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
--
2.30.2
On Mon, May 10, 2021 at 11:25:53PM +0300, Dmitry Osipenko wrote:
> It's possible to hit the temperature of the thermal zone in a very warm
> environment under a constant load, like watching a video using software
> decoding. It's even easier to hit the limit with a slightly overclocked
> CPU. Bump the temperature limit by 10C in order to improve user
> experience. Acer A500 has a large board and 10" display panel which are
> used for the heat dissipation, the SoC is placed far away from battery,
> hence we can safely bump the temperature limit.
60^C looks like a touch-safety limit (to avoid burns for users). Did you
verify the touchable parts' temperature somehow after the change?
Best Regards
Micha??Miros?aw
15.05.2021 00:16, Michał Mirosław пишет:
> On Mon, May 10, 2021 at 11:25:53PM +0300, Dmitry Osipenko wrote:
>> It's possible to hit the temperature of the thermal zone in a very warm
>> environment under a constant load, like watching a video using software
>> decoding. It's even easier to hit the limit with a slightly overclocked
>> CPU. Bump the temperature limit by 10C in order to improve user
>> experience. Acer A500 has a large board and 10" display panel which are
>> used for the heat dissipation, the SoC is placed far away from battery,
>> hence we can safely bump the temperature limit.
>
> 60^C looks like a touch-safety limit (to avoid burns for users). Did you
> verify the touchable parts' temperature somehow after the change?
The SoC is placed under a can. Both front and back of device are large
metal planes which dissipate heat efficiently. I don't recall A500
getting hot ever and I'm holding it in hands every day. From a user
perspective it may feel like a part of device getting slightly warm in a
worst case.
From: Thierry Reding <[email protected]>
On Mon, 10 May 2021 23:25:50 +0300, Dmitry Osipenko wrote:
> This series brings couple corrections and improvements to the device-trees
> of Acer A500, AC100 and Nexus 7 devices. It also corrects polarity of
> headphones-detection GPIO in all Tegra device-trees that use WM8903 audio
> codec.
>
> Dmitry Osipenko (10):
> ARM: tegra: acer-a500: Improve microphone detection
> ARM: tegra: acer-a500: Specify proper voltage for WiFi SDIO bus
> ARM: tegra: acer-a500: Bump thermal trips by 10C
> ARM: tegra: Add reg property to Tegra20 EMC table device-tree nodes
> ARM: tegra: wm8903: Fix polarity of headphones-detection GPIO in
> device-trees
> ARM: tegra: paz00: Add CPU thermal zone
> ARM: tegra: nexus7: Add i2c-thermtrip node
> ARM: tegra: nexus7: Improve thermal zones
> ARM: tegra: nexus7: Remove monitored-battery property
> ARM: tegra: nexus7: Correct 3v3 regulator GPIO of PM269 variant
>
> [...]
Applied, thanks!
[01/10] ARM: tegra: acer-a500: Improve microphone detection
commit: ef3082db434f3f87b83ccaa1ce4ebfd05535b651
[02/10] ARM: tegra: acer-a500: Specify proper voltage for WiFi SDIO bus
commit: a99d77c4b2ac9095d9bd5969996905886debbe8b
[03/10] ARM: tegra: acer-a500: Bump thermal trips by 10C
commit: c46240c005ae7fe10c2fe753ead996379cbf73ff
[04/10] ARM: tegra: Add reg property to Tegra20 EMC table device-tree nodes
commit: b39a16b577cc11c7ab3fb67c8723c7ea057d96d4
[05/10] ARM: tegra: wm8903: Fix polarity of headphones-detection GPIO in device-trees
commit: 5f45da704de425d74abd75feaa928fc8a3df03ba
[06/10] ARM: tegra: paz00: Add CPU thermal zone
commit: 2e09908f37c34356baae72f047bbb8fc9faac32f
[07/10] ARM: tegra: nexus7: Add i2c-thermtrip node
commit: 8b73d8c3d2c93c6e3db19d8c2641fc74dc9f8bf1
[08/10] ARM: tegra: nexus7: Improve thermal zones
commit: 7168137532d2d27d34811cd5a073ad5c3215b592
[09/10] ARM: tegra: nexus7: Remove monitored-battery property
commit: 4405d933b66c0c9268de3b3d9cab3e3b780c64f1
[10/10] ARM: tegra: nexus7: Correct 3v3 regulator GPIO of PM269 variant
commit: c4dd6066bc304649e3159f1c7a08ece25d537e00
Best regards,
--
Thierry Reding <[email protected]>
On Mon, May 10, 2021 at 11:25:54PM +0300, Dmitry Osipenko wrote:
> The reg property is now specified for the emc-tables nodes in the Tegra20
> device-tree binding. Add reg property to the EMC table device-tree nodes
> of Tegra20 board device-trees in order to silence dt_binding_check warning
> about the missing property.
>
> Signed-off-by: Dmitry Osipenko <[email protected]>
> ---
> arch/arm/boot/dts/tegra20-acer-a500-picasso.dts | 4 ++++
> arch/arm/boot/dts/tegra20-paz00.dts | 1 +
> 2 files changed, 5 insertions(+)
In retrospect we should've just used "reg" in the first place rather
than adding the custom "nvidia,ram-code". It's a bit redundant to have
both of them with the same value. I wonder if we should deprecate the
use of "nvidia,ram-code" and at least make the code look at the "reg"
property first and only fall back to "nvidia,ram-code" if "reg" does
not exist. We probably won't ever be able to get rid of the fallback
for backwards-compatibility reasons, but at least that would make the
intent a bit clearer.
Thierry
31.05.2021 12:14, Thierry Reding пишет:
> On Mon, May 10, 2021 at 11:25:54PM +0300, Dmitry Osipenko wrote:
>> The reg property is now specified for the emc-tables nodes in the Tegra20
>> device-tree binding. Add reg property to the EMC table device-tree nodes
>> of Tegra20 board device-trees in order to silence dt_binding_check warning
>> about the missing property.
>>
>> Signed-off-by: Dmitry Osipenko <[email protected]>
>> ---
>> arch/arm/boot/dts/tegra20-acer-a500-picasso.dts | 4 ++++
>> arch/arm/boot/dts/tegra20-paz00.dts | 1 +
>> 2 files changed, 5 insertions(+)
>
> In retrospect we should've just used "reg" in the first place rather
> than adding the custom "nvidia,ram-code". It's a bit redundant to have
> both of them with the same value. I wonder if we should deprecate the
> use of "nvidia,ram-code" and at least make the code look at the "reg"
> property first and only fall back to "nvidia,ram-code" if "reg" does
> not exist. We probably won't ever be able to get rid of the fallback
> for backwards-compatibility reasons, but at least that would make the
> intent a bit clearer.
This may be not doable. We have Asus TF101 which doesn't use RAM code
for the memory identification, instead it uses LPDDR chip info [1]. I
will send the LPDDR patches later on.
[1]
https://github.com/grate-driver/linux/blob/master/arch/arm/boot/dts/tegra20-asus-tf101.dts#L1115
The TF101 support mostly in a completed state now, we still need to try
to figure out why upstream kernel doesn't work using a stock Android
bootloader, so far bootloader replacement to u-boot is required.
On Mon, May 31, 2021 at 11:45:19PM +0300, Dmitry Osipenko wrote:
> 31.05.2021 12:14, Thierry Reding пишет:
> > On Mon, May 10, 2021 at 11:25:54PM +0300, Dmitry Osipenko wrote:
> >> The reg property is now specified for the emc-tables nodes in the Tegra20
> >> device-tree binding. Add reg property to the EMC table device-tree nodes
> >> of Tegra20 board device-trees in order to silence dt_binding_check warning
> >> about the missing property.
> >>
> >> Signed-off-by: Dmitry Osipenko <[email protected]>
> >> ---
> >> arch/arm/boot/dts/tegra20-acer-a500-picasso.dts | 4 ++++
> >> arch/arm/boot/dts/tegra20-paz00.dts | 1 +
> >> 2 files changed, 5 insertions(+)
> >
> > In retrospect we should've just used "reg" in the first place rather
> > than adding the custom "nvidia,ram-code". It's a bit redundant to have
> > both of them with the same value. I wonder if we should deprecate the
> > use of "nvidia,ram-code" and at least make the code look at the "reg"
> > property first and only fall back to "nvidia,ram-code" if "reg" does
> > not exist. We probably won't ever be able to get rid of the fallback
> > for backwards-compatibility reasons, but at least that would make the
> > intent a bit clearer.
>
> This may be not doable. We have Asus TF101 which doesn't use RAM code
> for the memory identification, instead it uses LPDDR chip info [1]. I
> will send the LPDDR patches later on.
>
> [1]
> https://github.com/grate-driver/linux/blob/master/arch/arm/boot/dts/tegra20-asus-tf101.dts#L1115
That DTS defines both "jedec,lpddr-manufacturer-id" and "reg" with the
same value, so we could simply use "reg" there. If you plan to support
the JEDEC properties, we'll have to add code for that anyway, so there
is no downside to first trying "reg". And we may not even need to add
support for any of those JEDEC properties if we can just use the "reg"
standard property in the first place.
> The TF101 support mostly in a completed state now, we still need to try
> to figure out why upstream kernel doesn't work using a stock Android
> bootloader, so far bootloader replacement to u-boot is required.
I think it's fine to merge support upstream if there is some sort of
bootloader that it can run with. If that bootloader is open-source like
U-Boot, the better, but I don't think we need to set the bar as high as
being able to boot with any available bootloader. There are all sorts
of reasons why the Android stock bootloader may cause things not to work
and there's probably no way to get it fixed anyway. It's similarly
possible that the kernel may need some outlandish quirk to accomodate
for that breakage and we may not want, or be able, to upstream such
quirks anyway.
So if you want to pursue making upstream Linux work with the stock
Android bootloader, that's a fine goal and I won't object, but it's not
a requirement that I will insist on before merging DTS files.
Thierry
01.06.2021 14:25, Thierry Reding пишет:
> On Mon, May 31, 2021 at 11:45:19PM +0300, Dmitry Osipenko wrote:
>> 31.05.2021 12:14, Thierry Reding пишет:
>>> On Mon, May 10, 2021 at 11:25:54PM +0300, Dmitry Osipenko wrote:
>>>> The reg property is now specified for the emc-tables nodes in the Tegra20
>>>> device-tree binding. Add reg property to the EMC table device-tree nodes
>>>> of Tegra20 board device-trees in order to silence dt_binding_check warning
>>>> about the missing property.
>>>>
>>>> Signed-off-by: Dmitry Osipenko <[email protected]>
>>>> ---
>>>> arch/arm/boot/dts/tegra20-acer-a500-picasso.dts | 4 ++++
>>>> arch/arm/boot/dts/tegra20-paz00.dts | 1 +
>>>> 2 files changed, 5 insertions(+)
>>>
>>> In retrospect we should've just used "reg" in the first place rather
>>> than adding the custom "nvidia,ram-code". It's a bit redundant to have
>>> both of them with the same value. I wonder if we should deprecate the
>>> use of "nvidia,ram-code" and at least make the code look at the "reg"
>>> property first and only fall back to "nvidia,ram-code" if "reg" does
>>> not exist. We probably won't ever be able to get rid of the fallback
>>> for backwards-compatibility reasons, but at least that would make the
>>> intent a bit clearer.
>>
>> This may be not doable. We have Asus TF101 which doesn't use RAM code
>> for the memory identification, instead it uses LPDDR chip info [1]. I
>> will send the LPDDR patches later on.
>>
>> [1]
>> https://github.com/grate-driver/linux/blob/master/arch/arm/boot/dts/tegra20-asus-tf101.dts#L1115
>
> That DTS defines both "jedec,lpddr-manufacturer-id" and "reg" with the
> same value, so we could simply use "reg" there. If you plan to support
> the JEDEC properties, we'll have to add code for that anyway, so there
> is no downside to first trying "reg".
At least in my mind the reg property is associated with a hardware
register. Changing the purpose of the reg and removing the verbose
properties should create confusion for anyone who looks at device-tree
and not familiar with the binding.
The current main purpose of the reg is "Either an opaque enumerator to
tell different tables apart or the valid frequency for which the table
should be used (in kHz)", like the binding says. It should be better to
keep the reg optional and additional, especially if we will give it
another meaning, IMO.
> And we may not even need to add
> support for any of those JEDEC properties if we can just use the "reg"
> standard property in the first place.
We will need all those JEDEC properties for identifying memory chips,
including information about chip version and h/w geometry. This method
of matching is borrowed from the official downstream kernel of TF101,
apparently board designers decided not to use the RAM code.
01.06.2021 14:25, Thierry Reding пишет:
>> The TF101 support mostly in a completed state now, we still need to try
>> to figure out why upstream kernel doesn't work using a stock Android
>> bootloader, so far bootloader replacement to u-boot is required.
> I think it's fine to merge support upstream if there is some sort of
> bootloader that it can run with. If that bootloader is open-source like
> U-Boot, the better, but I don't think we need to set the bar as high as
> being able to boot with any available bootloader. There are all sorts
> of reasons why the Android stock bootloader may cause things not to work
> and there's probably no way to get it fixed anyway. It's similarly
> possible that the kernel may need some outlandish quirk to accomodate
> for that breakage and we may not want, or be able, to upstream such
> quirks anyway.
Lots of devices with Android bootloader have odd limitations in regards
to kernel zImage size, this is the main culprit. Nothing we can do about
this in kernel code, but at least we may know how to prepare kernel
config properly to make it working.
> So if you want to pursue making upstream Linux work with the stock
> Android bootloader, that's a fine goal and I won't object, but it's not
> a requirement that I will insist on before merging DTS files.
This is indeed not a blocker for the device-tree. We will probably send
all the transformers together once they all will be ready.
On 14/05/2021 23:16, Michał Mirosław wrote:
> On Mon, May 10, 2021 at 11:25:53PM +0300, Dmitry Osipenko wrote:
>> It's possible to hit the temperature of the thermal zone in a very warm
>> environment under a constant load, like watching a video using software
>> decoding. It's even easier to hit the limit with a slightly overclocked
>> CPU. Bump the temperature limit by 10C in order to improve user
>> experience. Acer A500 has a large board and 10" display panel which are
>> used for the heat dissipation, the SoC is placed far away from battery,
>> hence we can safely bump the temperature limit.
>
> 60^C looks like a touch-safety limit (to avoid burns for users). Did you
> verify the touchable parts' temperature somehow after the change?
The skin temperature and the CPU/GPU etc ... temperatures are different
things.
For the embedded system there is the dissipation system and a
temperature sensor on it which is the skin temp. This temperature is the
result of the heat of all the thermal zones on the board and must be
below 45°C. The temperature slowly changes.
On the CPU, the temperature changes can be very fast and you have to
take care of keeping it below the max temperature specified in the TRM
by using different techniques (freq changes, idle injection, ...) but
the temperature can be 75°C, 85°C or whatever the manual says.
50°C and 60°C are low temperature for a CPU and that will inevitably
impact the performances, so setting the temperature close the max
temperature is what will allow max performances.
What matters is the skin temperature.
The skin temperature must be monitored by other techniques, eg. using
the TDP of the system and throttle the different devices to keep them in
this power budget. That is the role of an thermal daemon.
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
11.06.2021 12:52, Daniel Lezcano пишет:
> On 14/05/2021 23:16, Michał Mirosław wrote:
>> On Mon, May 10, 2021 at 11:25:53PM +0300, Dmitry Osipenko wrote:
>>> It's possible to hit the temperature of the thermal zone in a very warm
>>> environment under a constant load, like watching a video using software
>>> decoding. It's even easier to hit the limit with a slightly overclocked
>>> CPU. Bump the temperature limit by 10C in order to improve user
>>> experience. Acer A500 has a large board and 10" display panel which are
>>> used for the heat dissipation, the SoC is placed far away from battery,
>>> hence we can safely bump the temperature limit.
>>
>> 60^C looks like a touch-safety limit (to avoid burns for users). Did you
>> verify the touchable parts' temperature somehow after the change?
>
> The skin temperature and the CPU/GPU etc ... temperatures are different
> things.
>
> For the embedded system there is the dissipation system and a
> temperature sensor on it which is the skin temp. This temperature is the
> result of the heat of all the thermal zones on the board and must be
> below 45°C. The temperature slowly changes.
>
> On the CPU, the temperature changes can be very fast and you have to
> take care of keeping it below the max temperature specified in the TRM
> by using different techniques (freq changes, idle injection, ...) but
> the temperature can be 75°C, 85°C or whatever the manual says.
>
> 50°C and 60°C are low temperature for a CPU and that will inevitably
> impact the performances, so setting the temperature close the max
> temperature is what will allow max performances.
>
> What matters is the skin temperature.
>
> The skin temperature must be monitored by other techniques, eg. using
> the TDP of the system and throttle the different devices to keep them in
> this power budget. That is the role of an thermal daemon.
Thank you for the clarification. Indeed, I wasn't sure how to make use
of the skin temperature properly.
The skin temperature varies a lot depending on the thermal capabilities
of a particular device. It's about 15C below CPU core at a full load on
A500, while it's 2C below CPU core on Nexus 7. But this is expected
since Nexus 7 can't dissipate heat efficiently.
I will revisit the DT thermal zones again for the next kernel release.
On 12/06/2021 12:40, Dmitry Osipenko wrote:
> 11.06.2021 12:52, Daniel Lezcano пишет:
>> On 14/05/2021 23:16, Michał Mirosław wrote:
>>> On Mon, May 10, 2021 at 11:25:53PM +0300, Dmitry Osipenko wrote:
>>>> It's possible to hit the temperature of the thermal zone in a very warm
>>>> environment under a constant load, like watching a video using software
>>>> decoding. It's even easier to hit the limit with a slightly overclocked
>>>> CPU. Bump the temperature limit by 10C in order to improve user
>>>> experience. Acer A500 has a large board and 10" display panel which are
>>>> used for the heat dissipation, the SoC is placed far away from battery,
>>>> hence we can safely bump the temperature limit.
>>>
>>> 60^C looks like a touch-safety limit (to avoid burns for users). Did you
>>> verify the touchable parts' temperature somehow after the change?
>>
>> The skin temperature and the CPU/GPU etc ... temperatures are different
>> things.
>>
>> For the embedded system there is the dissipation system and a
>> temperature sensor on it which is the skin temp. This temperature is the
>> result of the heat of all the thermal zones on the board and must be
>> below 45°C. The temperature slowly changes.
>>
>> On the CPU, the temperature changes can be very fast and you have to
>> take care of keeping it below the max temperature specified in the TRM
>> by using different techniques (freq changes, idle injection, ...) but
>> the temperature can be 75°C, 85°C or whatever the manual says.
>>
>> 50°C and 60°C are low temperature for a CPU and that will inevitably
>> impact the performances, so setting the temperature close the max
>> temperature is what will allow max performances.
>>
>> What matters is the skin temperature.
>>
>> The skin temperature must be monitored by other techniques, eg. using
>> the TDP of the system and throttle the different devices to keep them in
>> this power budget. That is the role of an thermal daemon.
>
> Thank you for the clarification. Indeed, I wasn't sure how to make use
> of the skin temperature properly.
>
> The skin temperature varies a lot depending on the thermal capabilities
> of a particular device. It's about 15C below CPU core at a full load on
> A500, while it's 2C below CPU core on Nexus 7. But this is expected
> since Nexus 7 can't dissipate heat efficiently.
Yeah, but it can not be directly related to the CPU because if the GPU
is intensively used and the battery is charging at the same time, the
skin temp will increase anyway.
You should set the trip points close to the functioning boundary
temperature given in the hardware specification whatever the resulting
heating effect is on the device.
The thermal zone is there to protect the silicon and the system from a
wild reboot.
If the Nexus 7 is too hot after the changes, then you may act on the
sources of the heat. For instance, set the the highest OPP to turbo or
remove it, or, if there is one, change the thermal daemon to reduce the
overall power consumption.
In case you are interested in: https://lwn.net/Articles/839318/
Hope that helps
-- Daniel
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
12.06.2021 17:24, Daniel Lezcano пишет:
> On 12/06/2021 12:40, Dmitry Osipenko wrote:
>> 11.06.2021 12:52, Daniel Lezcano пишет:
>>> On 14/05/2021 23:16, Michał Mirosław wrote:
>>>> On Mon, May 10, 2021 at 11:25:53PM +0300, Dmitry Osipenko wrote:
>>>>> It's possible to hit the temperature of the thermal zone in a very warm
>>>>> environment under a constant load, like watching a video using software
>>>>> decoding. It's even easier to hit the limit with a slightly overclocked
>>>>> CPU. Bump the temperature limit by 10C in order to improve user
>>>>> experience. Acer A500 has a large board and 10" display panel which are
>>>>> used for the heat dissipation, the SoC is placed far away from battery,
>>>>> hence we can safely bump the temperature limit.
>>>>
>>>> 60^C looks like a touch-safety limit (to avoid burns for users). Did you
>>>> verify the touchable parts' temperature somehow after the change?
>>>
>>> The skin temperature and the CPU/GPU etc ... temperatures are different
>>> things.
>>>
>>> For the embedded system there is the dissipation system and a
>>> temperature sensor on it which is the skin temp. This temperature is the
>>> result of the heat of all the thermal zones on the board and must be
>>> below 45°C. The temperature slowly changes.
>>>
>>> On the CPU, the temperature changes can be very fast and you have to
>>> take care of keeping it below the max temperature specified in the TRM
>>> by using different techniques (freq changes, idle injection, ...) but
>>> the temperature can be 75°C, 85°C or whatever the manual says.
>>>
>>> 50°C and 60°C are low temperature for a CPU and that will inevitably
>>> impact the performances, so setting the temperature close the max
>>> temperature is what will allow max performances.
>>>
>>> What matters is the skin temperature.
>>>
>>> The skin temperature must be monitored by other techniques, eg. using
>>> the TDP of the system and throttle the different devices to keep them in
>>> this power budget. That is the role of an thermal daemon.
>>
>> Thank you for the clarification. Indeed, I wasn't sure how to make use
>> of the skin temperature properly.
>>
>> The skin temperature varies a lot depending on the thermal capabilities
>> of a particular device. It's about 15C below CPU core at a full load on
>> A500, while it's 2C below CPU core on Nexus 7. But this is expected
>> since Nexus 7 can't dissipate heat efficiently.
> Yeah, but it can not be directly related to the CPU because if the GPU
> is intensively used and the battery is charging at the same time, the
> skin temp will increase anyway.
Sure, we just added the memory devfreq throttling as a cooling device to
Nexus 7 and Ouya DTs in addition to the CPU throttling.
The GPU and other h/w units are on the pending list. For the starter we
need to add GENPD and runtime PM support to all drivers, which solves
the overheating problem of idling systems. We have Tegra30 Ouya game
console that is getting hot during idle without the runtime PM support.
Afterwards we can add the devfreq support to improve the active cooling.
I'm already working on it.
> You should set the trip points close to the functioning boundary
> temperature given in the hardware specification whatever the resulting
> heating effect is on the device.
>
> The thermal zone is there to protect the silicon and the system from a
> wild reboot.
>
> If the Nexus 7 is too hot after the changes, then you may act on the
> sources of the heat. For instance, set the the highest OPP to turbo or
> remove it, or, if there is one, change the thermal daemon to reduce the
> overall power consumption.
> In case you are interested in: https://lwn.net/Articles/839318/
The DTPM is a very interesting approach. For now Tegra still misses some
basics in mainline kernel which have a higher priority, so I think it
should be good enough to perform the in-kernel thermal management for
the starter. We may consider a more complex solutions later on if will
be necessary.
What I'm currently thinking to do is:
1. Set up the trips of SoC/CPU core thermal zones in accordance to the
silicon limits.
2. Set up the skin trips in accordance to the device limits.
The breached skin trips will cause a mild throttling, while the SoC/CPU
trips will be allowed to cause the severe throttling. Does this sound
good to you?
> Hope that helps
Helps a lot, thank you very much.
On 13/06/2021 02:25, Dmitry Osipenko wrote:
[ ... ]
>> You should set the trip points close to the functioning boundary
>> temperature given in the hardware specification whatever the resulting
>> heating effect is on the device.
>>
>> The thermal zone is there to protect the silicon and the system from a
>> wild reboot.
>>
>> If the Nexus 7 is too hot after the changes, then you may act on the
>> sources of the heat. For instance, set the the highest OPP to turbo or
>> remove it, or, if there is one, change the thermal daemon to reduce the
>> overall power consumption.
>> In case you are interested in: https://lwn.net/Articles/839318/
>
> The DTPM is a very interesting approach. For now Tegra still misses some
> basics in mainline kernel which have a higher priority, so I think it
> should be good enough to perform the in-kernel thermal management for
> the starter. We may consider a more complex solutions later on if will
> be necessary.
>
> What I'm currently thinking to do is:
>
> 1. Set up the trips of SoC/CPU core thermal zones in accordance to the
> silicon limits.
>
> 2. Set up the skin trips in accordance to the device limits.
>
> The breached skin trips will cause a mild throttling, while the SoC/CPU
> trips will be allowed to cause the severe throttling. Does this sound
> good to you?
The skin temperature must be managed from userspace. The kernel is
unable to do a smart thermal management given different thermal zones
but if the goal is to go forward and prevent the tablet to be hot
temporarily until the other hardware support is there, I think it is
acceptable.
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
13.06.2021 21:19, Daniel Lezcano пишет:
> On 13/06/2021 02:25, Dmitry Osipenko wrote:
>
> [ ... ]
>
>>> You should set the trip points close to the functioning boundary
>>> temperature given in the hardware specification whatever the resulting
>>> heating effect is on the device.
>>>
>>> The thermal zone is there to protect the silicon and the system from a
>>> wild reboot.
>>>
>>> If the Nexus 7 is too hot after the changes, then you may act on the
>>> sources of the heat. For instance, set the the highest OPP to turbo or
>>> remove it, or, if there is one, change the thermal daemon to reduce the
>>> overall power consumption.
>>> In case you are interested in: https://lwn.net/Articles/839318/
>>
>> The DTPM is a very interesting approach. For now Tegra still misses some
>> basics in mainline kernel which have a higher priority, so I think it
>> should be good enough to perform the in-kernel thermal management for
>> the starter. We may consider a more complex solutions later on if will
>> be necessary.
>>
>> What I'm currently thinking to do is:
>>
>> 1. Set up the trips of SoC/CPU core thermal zones in accordance to the
>> silicon limits.
>>
>> 2. Set up the skin trips in accordance to the device limits.
>>
>> The breached skin trips will cause a mild throttling, while the SoC/CPU
>> trips will be allowed to cause the severe throttling. Does this sound
>> good to you?
>
> The skin temperature must be managed from userspace. The kernel is
> unable to do a smart thermal management given different thermal zones
> but if the goal is to go forward and prevent the tablet to be hot
> temporarily until the other hardware support is there, I think it is
> acceptable.
The current goal is to get maximum from what we already have, thank you.
On 15/06/2021 14:53, Dmitry Osipenko wrote:
> 13.06.2021 21:19, Daniel Lezcano пишет:
>> On 13/06/2021 02:25, Dmitry Osipenko wrote:
>>
>> [ ... ]
>>
>>>> You should set the trip points close to the functioning boundary
>>>> temperature given in the hardware specification whatever the resulting
>>>> heating effect is on the device.
>>>>
>>>> The thermal zone is there to protect the silicon and the system from a
>>>> wild reboot.
>>>>
>>>> If the Nexus 7 is too hot after the changes, then you may act on the
>>>> sources of the heat. For instance, set the the highest OPP to turbo or
>>>> remove it, or, if there is one, change the thermal daemon to reduce the
>>>> overall power consumption.
>>>> In case you are interested in: https://lwn.net/Articles/839318/
>>>
>>> The DTPM is a very interesting approach. For now Tegra still misses some
>>> basics in mainline kernel which have a higher priority, so I think it
>>> should be good enough to perform the in-kernel thermal management for
>>> the starter. We may consider a more complex solutions later on if will
>>> be necessary.
>>>
>>> What I'm currently thinking to do is:
>>>
>>> 1. Set up the trips of SoC/CPU core thermal zones in accordance to the
>>> silicon limits.
>>>
>>> 2. Set up the skin trips in accordance to the device limits.
>>>
>>> The breached skin trips will cause a mild throttling, while the SoC/CPU
>>> trips will be allowed to cause the severe throttling. Does this sound
>>> good to you?
>>
>> The skin temperature must be managed from userspace. The kernel is
>> unable to do a smart thermal management given different thermal zones
>> but if the goal is to go forward and prevent the tablet to be hot
>> temporarily until the other hardware support is there, I think it is
>> acceptable.
>
> The current goal is to get maximum from what we already have, thank you.
maximum of performance or maximum of mitigation ?
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
15.06.2021 16:05, Daniel Lezcano пишет:
> On 15/06/2021 14:53, Dmitry Osipenko wrote:
>> 13.06.2021 21:19, Daniel Lezcano пишет:
>>> On 13/06/2021 02:25, Dmitry Osipenko wrote:
>>>
>>> [ ... ]
>>>
>>>>> You should set the trip points close to the functioning boundary
>>>>> temperature given in the hardware specification whatever the resulting
>>>>> heating effect is on the device.
>>>>>
>>>>> The thermal zone is there to protect the silicon and the system from a
>>>>> wild reboot.
>>>>>
>>>>> If the Nexus 7 is too hot after the changes, then you may act on the
>>>>> sources of the heat. For instance, set the the highest OPP to turbo or
>>>>> remove it, or, if there is one, change the thermal daemon to reduce the
>>>>> overall power consumption.
>>>>> In case you are interested in: https://lwn.net/Articles/839318/
>>>>
>>>> The DTPM is a very interesting approach. For now Tegra still misses some
>>>> basics in mainline kernel which have a higher priority, so I think it
>>>> should be good enough to perform the in-kernel thermal management for
>>>> the starter. We may consider a more complex solutions later on if will
>>>> be necessary.
>>>>
>>>> What I'm currently thinking to do is:
>>>>
>>>> 1. Set up the trips of SoC/CPU core thermal zones in accordance to the
>>>> silicon limits.
>>>>
>>>> 2. Set up the skin trips in accordance to the device limits.
>>>>
>>>> The breached skin trips will cause a mild throttling, while the SoC/CPU
>>>> trips will be allowed to cause the severe throttling. Does this sound
>>>> good to you?
>>>
>>> The skin temperature must be managed from userspace. The kernel is
>>> unable to do a smart thermal management given different thermal zones
>>> but if the goal is to go forward and prevent the tablet to be hot
>>> temporarily until the other hardware support is there, I think it is
>>> acceptable.
>>
>> The current goal is to get maximum from what we already have, thank you.
>
> maximum of performance or maximum of mitigation ?
The best balance of both. Maximum performance + no risk of damaging
hardware + pleasant body temperature from a user perspective.