[PATCH v2 0/5] thermal: hisilicon: enable power allocator for Hi6220

[PATCH v2 0/5] thermal: hisilicon: enable power allocator for Hi6220

[Leo Yan]

Hi6220 has octa-core so it has quite high power consumption when run
benchmark and introduces high temperature for SoC. So need enable
thermal governor to control temperature and also cannot hurt much for
performance after impose cooling operations on CPU.

This patch series is to enable power allocator for Hi6220. Patch 1 is to
change "hysteresis" as optional property for trip points, so when enable
power allocator governor we can ignore this property.

During profiling also found two issues for thermal sensor's driver. The
power allocator just uses only one sensor, so patch 2 is to fix sensor
driver to let it can initialize driver successfully with only enabling
one sensor; patch 3 is to dismiss warning of IRQ imbalance enabling.

After profiling on Hikey, the power model has been simplized with only
dynamic coefficient, and now it's convienence to pass it from CPU node.
So patch 4 and 5 bind sensor and pass power model parameters.

This patch series have been tested on 96boards Hikey.

Changes from v1:
* According to Javi's review, removed unecessary properties for DT
* Add patch 1 for change "hysteresis" as optional property
* Add patch 3 to fix IRQ imbalance enabling issue


Leo Yan (5):
  thermal: change "hysteresis" as optional property
  thermal: hisilicon: support to use any sensor
  thermal: hisilicon: fix IRQ imbalance enabling
  arm64: dts: register Hi6220's thermal sensor
  arm64: dts: register Hi6220's thermal zone for power allocator

 .../devicetree/bindings/thermal/thermal.txt        |  9 ++---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi          | 42 ++++++++++++++++++++++
 drivers/thermal/hisi_thermal.c                     | 40 ++++++++++++---------
 drivers/thermal/of-thermal.c                       |  9 +++--
 4 files changed, 75 insertions(+), 25 deletions(-)

-- 
1.9.1

[PATCH v2 0/5] thermal: hisilicon: enable power allocator for Hi6220

[Leo Yan]

Hi6220 has octa-core so it has quite high power consumption when run
benchmark and introduces high temperature for SoC. So need enable
thermal governor to control temperature and also cannot hurt much for
performance after impose cooling operations on CPU.

This patch series is to enable power allocator for Hi6220. Patch 1 is to
change "hysteresis" as optional property for trip points, so when enable
power allocator governor we can ignore this property.

During profiling also found two issues for thermal sensor's driver. The
power allocator just uses only one sensor, so patch 2 is to fix sensor
driver to let it can initialize driver successfully with only enabling
one sensor; patch 3 is to dismiss warning of IRQ imbalance enabling.

After profiling on Hikey, the power model has been simplized with only
dynamic coefficient, and now it's convienence to pass it from CPU node.
So patch 4 and 5 bind sensor and pass power model parameters.

This patch series have been tested on 96boards Hikey.

Changes from v1:
* According to Javi's review, removed unecessary properties for DT
* Add patch 1 for change "hysteresis" as optional property
* Add patch 3 to fix IRQ imbalance enabling issue


Leo Yan (5):
  thermal: change "hysteresis" as optional property
  thermal: hisilicon: support to use any sensor
  thermal: hisilicon: fix IRQ imbalance enabling
  arm64: dts: register Hi6220's thermal sensor
  arm64: dts: register Hi6220's thermal zone for power allocator

 .../devicetree/bindings/thermal/thermal.txt        |  9 ++---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi          | 42 ++++++++++++++++++++++
 drivers/thermal/hisi_thermal.c                     | 40 ++++++++++++---------
 drivers/thermal/of-thermal.c                       |  9 +++--
 4 files changed, 75 insertions(+), 25 deletions(-)

-- 
1.9.1

--
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 v2 0/5] thermal: hisilicon: enable power allocator for Hi6220

[Leo Yan]

Hi6220 has octa-core so it has quite high power consumption when run
benchmark and introduces high temperature for SoC. So need enable
thermal governor to control temperature and also cannot hurt much for
performance after impose cooling operations on CPU.

This patch series is to enable power allocator for Hi6220. Patch 1 is to
change "hysteresis" as optional property for trip points, so when enable
power allocator governor we can ignore this property.

During profiling also found two issues for thermal sensor's driver. The
power allocator just uses only one sensor, so patch 2 is to fix sensor
driver to let it can initialize driver successfully with only enabling
one sensor; patch 3 is to dismiss warning of IRQ imbalance enabling.

After profiling on Hikey, the power model has been simplized with only
dynamic coefficient, and now it's convienence to pass it from CPU node.
So patch 4 and 5 bind sensor and pass power model parameters.

This patch series have been tested on 96boards Hikey.

Changes from v1:
* According to Javi's review, removed unecessary properties for DT
* Add patch 1 for change "hysteresis" as optional property
* Add patch 3 to fix IRQ imbalance enabling issue


Leo Yan (5):
  thermal: change "hysteresis" as optional property
  thermal: hisilicon: support to use any sensor
  thermal: hisilicon: fix IRQ imbalance enabling
  arm64: dts: register Hi6220's thermal sensor
  arm64: dts: register Hi6220's thermal zone for power allocator

 .../devicetree/bindings/thermal/thermal.txt        |  9 ++---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi          | 42 ++++++++++++++++++++++
 drivers/thermal/hisi_thermal.c                     | 40 ++++++++++++---------
 drivers/thermal/of-thermal.c                       |  9 +++--
 4 files changed, 75 insertions(+), 25 deletions(-)

-- 
1.9.1

[PATCH v2 1/5] thermal: change "hysteresis" as optional property

[Leo Yan]

The property "hysteresis" is mandatory for trip points, so if without
it the thermal zone cannot register successfully. But "hysteresis" is
ignored in the thermal subsystem and only inquired by several thermal
sensor drivers.

So change "hysteresis" as optional properties.

Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
 Documentation/devicetree/bindings/thermal/thermal.txt | 9 +++++----
 drivers/thermal/of-thermal.c                          | 9 ++++-----
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
index 41b817f..7d79e77 100644
--- a/Documentation/devicetree/bindings/thermal/thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -89,10 +89,6 @@ Required properties:
   Type: signed		in millicelsius.
   Size: one cell
 
-- hysteresis:		A low hysteresis value on temperature property (above).
-  Type: unsigned	This is a relative value, in millicelsius.
-  Size: one cell
-
 - type:			a string containing the trip type. Expected values are:
 	"active":	A trip point to enable active cooling
 	"passive":	A trip point to enable passive cooling
@@ -100,6 +96,11 @@ Required properties:
 	"critical":	Hardware not reliable.
   Type: string
 
+Optional properties:
+- hysteresis:		A low hysteresis value on temperature property (above).
+  Type: unsigned	This is a relative value, in millicelsius.
+  Size: one cell
+
 * Cooling device maps
 
 The cooling device maps node is a node to describe how cooling devices
diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index 9043f8f..ab05500 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -689,11 +689,10 @@ static int thermal_of_populate_trip(struct device_node *np,
 	trip->temperature = prop;
 
 	ret = of_property_read_u32(np, "hysteresis", &prop);
-	if (ret < 0) {
-		pr_err("missing hysteresis property\n");
-		return ret;
-	}
-	trip->hysteresis = prop;
+	if (ret < 0)
+		pr_warning("missing hysteresis property\n");
+	else
+		trip->hysteresis = prop;
 
 	ret = thermal_of_get_trip_type(np, &trip->type);
 	if (ret < 0) {
-- 
1.9.1

[PATCH v2 1/5] thermal: change "hysteresis" as optional property

[Leo Yan]

The property "hysteresis" is mandatory for trip points, so if without
it the thermal zone cannot register successfully. But "hysteresis" is
ignored in the thermal subsystem and only inquired by several thermal
sensor drivers.

So change "hysteresis" as optional properties.

Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
 Documentation/devicetree/bindings/thermal/thermal.txt | 9 +++++----
 drivers/thermal/of-thermal.c                          | 9 ++++-----
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
index 41b817f..7d79e77 100644
--- a/Documentation/devicetree/bindings/thermal/thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -89,10 +89,6 @@ Required properties:
   Type: signed		in millicelsius.
   Size: one cell
 
-- hysteresis:		A low hysteresis value on temperature property (above).
-  Type: unsigned	This is a relative value, in millicelsius.
-  Size: one cell
-
 - type:			a string containing the trip type. Expected values are:
 	"active":	A trip point to enable active cooling
 	"passive":	A trip point to enable passive cooling
@@ -100,6 +96,11 @@ Required properties:
 	"critical":	Hardware not reliable.
   Type: string
 
+Optional properties:
+- hysteresis:		A low hysteresis value on temperature property (above).
+  Type: unsigned	This is a relative value, in millicelsius.
+  Size: one cell
+
 * Cooling device maps
 
 The cooling device maps node is a node to describe how cooling devices
diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index 9043f8f..ab05500 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -689,11 +689,10 @@ static int thermal_of_populate_trip(struct device_node *np,
 	trip->temperature = prop;
 
 	ret = of_property_read_u32(np, "hysteresis", &prop);
-	if (ret < 0) {
-		pr_err("missing hysteresis property\n");
-		return ret;
-	}
-	trip->hysteresis = prop;
+	if (ret < 0)
+		pr_warning("missing hysteresis property\n");
+	else
+		trip->hysteresis = prop;
 
 	ret = thermal_of_get_trip_type(np, &trip->type);
 	if (ret < 0) {
-- 
1.9.1

[PATCH v2 2/5] thermal: hisilicon: support to use any sensor

[Leo Yan]

In current code sensor driver registers all 4 sensors together and if
any of them has not bound to thermal zone successfully then driver will
return failure for driver's initialization. As a result, if DT binds
thermal zone with only one sensor, then the thermal driver will not work
well anymore.

So this patch is to fix this issue. It allows the thermal sensor driver
can register any number sensors at initialization phase, and fix up code
for other related code to skip related sensor's accessing if the sensor
has not been enabled in initialization phase.

Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
 drivers/thermal/hisi_thermal.c | 33 ++++++++++++++++++++-------------
 1 file changed, 20 insertions(+), 13 deletions(-)

diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
index 5e820b5..7a3e5d8 100644
--- a/drivers/thermal/hisi_thermal.c
+++ b/drivers/thermal/hisi_thermal.c
@@ -160,7 +160,7 @@ static int hisi_thermal_get_temp(void *_sensor, int *temp)
 	struct hisi_thermal_sensor *sensor = _sensor;
 	struct hisi_thermal_data *data = sensor->thermal;
 
-	int sensor_id = 0, i;
+	int sensor_id = -1, i;
 	long max_temp = 0;
 
 	*temp = hisi_thermal_get_sensor_temp(data, sensor);
@@ -168,12 +168,19 @@ static int hisi_thermal_get_temp(void *_sensor, int *temp)
 	sensor->sensor_temp = *temp;
 
 	for (i = 0; i < HISI_MAX_SENSORS; i++) {
+		if (!data->sensors[i].tzd)
+			continue;
+
 		if (data->sensors[i].sensor_temp >= max_temp) {
 			max_temp = data->sensors[i].sensor_temp;
 			sensor_id = i;
 		}
 	}
 
+	/* If no sensor has been enabled, then skip to enable irq */
+	if (sensor_id == -1)
+		return 0;
+
 	mutex_lock(&data->thermal_lock);
 	data->irq_bind_sensor = sensor_id;
 	mutex_unlock(&data->thermal_lock);
@@ -226,8 +233,12 @@ static irqreturn_t hisi_thermal_alarm_irq_thread(int irq, void *dev)
 		 sensor->thres_temp / 1000);
 	mutex_unlock(&data->thermal_lock);
 
-	for (i = 0; i < HISI_MAX_SENSORS; i++)
+	for (i = 0; i < HISI_MAX_SENSORS; i++) {
+		if (!data->sensors[i].tzd)
+			continue;
+
 		thermal_zone_device_update(data->sensors[i].tzd);
+	}
 
 	return IRQ_HANDLED;
 }
@@ -247,6 +258,7 @@ static int hisi_thermal_register_sensor(struct platform_device *pdev,
 				sensor, &hisi_of_thermal_ops);
 	if (IS_ERR(sensor->tzd)) {
 		ret = PTR_ERR(sensor->tzd);
+		sensor->tzd = NULL;
 		dev_err(&pdev->dev, "failed to register sensor id %d: %d\n",
 			sensor->id, ret);
 		return ret;
@@ -334,25 +346,17 @@ static int hisi_thermal_probe(struct platform_device *pdev)
 	for (i = 0; i < HISI_MAX_SENSORS; ++i) {
 		ret = hisi_thermal_register_sensor(pdev, data,
 						   &data->sensors[i], i);
-		if (ret) {
+		if (ret)
 			dev_err(&pdev->dev,
 				"failed to register thermal sensor: %d\n", ret);
-			goto err_get_sensor_data;
-		}
+		else
+			hisi_thermal_toggle_sensor(&data->sensors[i], true);
 	}
 
 	hisi_thermal_enable_bind_irq_sensor(data);
 	data->irq_enabled = true;
 
-	for (i = 0; i < HISI_MAX_SENSORS; i++)
-		hisi_thermal_toggle_sensor(&data->sensors[i], true);
-
 	return 0;
-
-err_get_sensor_data:
-	clk_disable_unprepare(data->clk);
-
-	return ret;
 }
 
 static int hisi_thermal_remove(struct platform_device *pdev)
@@ -363,6 +367,9 @@ static int hisi_thermal_remove(struct platform_device *pdev)
 	for (i = 0; i < HISI_MAX_SENSORS; i++) {
 		struct hisi_thermal_sensor *sensor = &data->sensors[i];
 
+		if (!sensor->tzd)
+			continue;
+
 		hisi_thermal_toggle_sensor(sensor, false);
 		thermal_zone_of_sensor_unregister(&pdev->dev, sensor->tzd);
 	}
-- 
1.9.1

[PATCH v2 2/5] thermal: hisilicon: support to use any sensor

[Leo Yan]

In current code sensor driver registers all 4 sensors together and if
any of them has not bound to thermal zone successfully then driver will
return failure for driver's initialization. As a result, if DT binds
thermal zone with only one sensor, then the thermal driver will not work
well anymore.

So this patch is to fix this issue. It allows the thermal sensor driver
can register any number sensors at initialization phase, and fix up code
for other related code to skip related sensor's accessing if the sensor
has not been enabled in initialization phase.

Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
 drivers/thermal/hisi_thermal.c | 33 ++++++++++++++++++++-------------
 1 file changed, 20 insertions(+), 13 deletions(-)

diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
index 5e820b5..7a3e5d8 100644
--- a/drivers/thermal/hisi_thermal.c
+++ b/drivers/thermal/hisi_thermal.c
@@ -160,7 +160,7 @@ static int hisi_thermal_get_temp(void *_sensor, int *temp)
 	struct hisi_thermal_sensor *sensor = _sensor;
 	struct hisi_thermal_data *data = sensor->thermal;
 
-	int sensor_id = 0, i;
+	int sensor_id = -1, i;
 	long max_temp = 0;
 
 	*temp = hisi_thermal_get_sensor_temp(data, sensor);
@@ -168,12 +168,19 @@ static int hisi_thermal_get_temp(void *_sensor, int *temp)
 	sensor->sensor_temp = *temp;
 
 	for (i = 0; i < HISI_MAX_SENSORS; i++) {
+		if (!data->sensors[i].tzd)
+			continue;
+
 		if (data->sensors[i].sensor_temp >= max_temp) {
 			max_temp = data->sensors[i].sensor_temp;
 			sensor_id = i;
 		}
 	}
 
+	/* If no sensor has been enabled, then skip to enable irq */
+	if (sensor_id == -1)
+		return 0;
+
 	mutex_lock(&data->thermal_lock);
 	data->irq_bind_sensor = sensor_id;
 	mutex_unlock(&data->thermal_lock);
@@ -226,8 +233,12 @@ static irqreturn_t hisi_thermal_alarm_irq_thread(int irq, void *dev)
 		 sensor->thres_temp / 1000);
 	mutex_unlock(&data->thermal_lock);
 
-	for (i = 0; i < HISI_MAX_SENSORS; i++)
+	for (i = 0; i < HISI_MAX_SENSORS; i++) {
+		if (!data->sensors[i].tzd)
+			continue;
+
 		thermal_zone_device_update(data->sensors[i].tzd);
+	}
 
 	return IRQ_HANDLED;
 }
@@ -247,6 +258,7 @@ static int hisi_thermal_register_sensor(struct platform_device *pdev,
 				sensor, &hisi_of_thermal_ops);
 	if (IS_ERR(sensor->tzd)) {
 		ret = PTR_ERR(sensor->tzd);
+		sensor->tzd = NULL;
 		dev_err(&pdev->dev, "failed to register sensor id %d: %d\n",
 			sensor->id, ret);
 		return ret;
@@ -334,25 +346,17 @@ static int hisi_thermal_probe(struct platform_device *pdev)
 	for (i = 0; i < HISI_MAX_SENSORS; ++i) {
 		ret = hisi_thermal_register_sensor(pdev, data,
 						   &data->sensors[i], i);
-		if (ret) {
+		if (ret)
 			dev_err(&pdev->dev,
 				"failed to register thermal sensor: %d\n", ret);
-			goto err_get_sensor_data;
-		}
+		else
+			hisi_thermal_toggle_sensor(&data->sensors[i], true);
 	}
 
 	hisi_thermal_enable_bind_irq_sensor(data);
 	data->irq_enabled = true;
 
-	for (i = 0; i < HISI_MAX_SENSORS; i++)
-		hisi_thermal_toggle_sensor(&data->sensors[i], true);
-
 	return 0;
-
-err_get_sensor_data:
-	clk_disable_unprepare(data->clk);
-
-	return ret;
 }
 
 static int hisi_thermal_remove(struct platform_device *pdev)
@@ -363,6 +367,9 @@ static int hisi_thermal_remove(struct platform_device *pdev)
 	for (i = 0; i < HISI_MAX_SENSORS; i++) {
 		struct hisi_thermal_sensor *sensor = &data->sensors[i];
 
+		if (!sensor->tzd)
+			continue;
+
 		hisi_thermal_toggle_sensor(sensor, false);
 		thermal_zone_of_sensor_unregister(&pdev->dev, sensor->tzd);
 	}
-- 
1.9.1

[PATCH v2 3/5] thermal: hisilicon: fix IRQ imbalance enabling

[Leo Yan]

When register sensors into thermal zone during initialization phase, it
reports error for IRQ imbalance enabling:

[    2.040713] WARNING: at kernel/irq/manage.c:513
[    2.040719] Modules linked in:
[    2.040721]
[    2.040729] CPU: 1 PID: 804 Comm: irq/33-hisi_the Not tainted 4.5.0-rc4+ #505
[    2.040732] Hardware name: HiKey Development Board (DT)
[    2.040736] task: ffffffc03ae82580 ti: ffffffc0379c8000 task.ti: ffffffc0379c8000
[    2.040745] PC is at __enable_irq+0x74/0x84
[    2.040749] LR is at __enable_irq+0x74/0x84

This warning is for IRQ imbalance enabling, which is caused by
enable_irq() twice. During sensor's initialization it tries to enable
IRQ, the driver will call thermal_zone_of_sensor_register() to bind
sensors and read sensor's temperature. But at this moment the flag
"data->irq_enabled" has been not initialized as correct state, so it
finally introduces the function enabled_irq() to be called twice. In
essentially this is caused by the flag "data->irq_enabled" is
inconsistent with real hardware IRQ enabling state.

So this patch is to fix this issue, firstly init "irq_enabled" flag
before binding sensors to thermal zone. Also change to use the function
irq_get_irqchip_state() to read back real interrupt line state.

Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
 drivers/thermal/hisi_thermal.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
index 7a3e5d8..982ffd1 100644
--- a/drivers/thermal/hisi_thermal.c
+++ b/drivers/thermal/hisi_thermal.c
@@ -343,6 +343,10 @@ static int hisi_thermal_probe(struct platform_device *pdev)
 		return ret;
 	}
 
+	hisi_thermal_enable_bind_irq_sensor(data);
+	irq_get_irqchip_state(data->irq, IRQCHIP_STATE_MASKED,
+			      &data->irq_enabled);
+
 	for (i = 0; i < HISI_MAX_SENSORS; ++i) {
 		ret = hisi_thermal_register_sensor(pdev, data,
 						   &data->sensors[i], i);
@@ -353,9 +357,6 @@ static int hisi_thermal_probe(struct platform_device *pdev)
 			hisi_thermal_toggle_sensor(&data->sensors[i], true);
 	}
 
-	hisi_thermal_enable_bind_irq_sensor(data);
-	data->irq_enabled = true;
-
 	return 0;
 }
 
-- 
1.9.1

[PATCH v2 3/5] thermal: hisilicon: fix IRQ imbalance enabling

[Leo Yan]

When register sensors into thermal zone during initialization phase, it
reports error for IRQ imbalance enabling:

[    2.040713] WARNING: at kernel/irq/manage.c:513
[    2.040719] Modules linked in:
[    2.040721]
[    2.040729] CPU: 1 PID: 804 Comm: irq/33-hisi_the Not tainted 4.5.0-rc4+ #505
[    2.040732] Hardware name: HiKey Development Board (DT)
[    2.040736] task: ffffffc03ae82580 ti: ffffffc0379c8000 task.ti: ffffffc0379c8000
[    2.040745] PC is at __enable_irq+0x74/0x84
[    2.040749] LR is at __enable_irq+0x74/0x84

This warning is for IRQ imbalance enabling, which is caused by
enable_irq() twice. During sensor's initialization it tries to enable
IRQ, the driver will call thermal_zone_of_sensor_register() to bind
sensors and read sensor's temperature. But at this moment the flag
"data->irq_enabled" has been not initialized as correct state, so it
finally introduces the function enabled_irq() to be called twice. In
essentially this is caused by the flag "data->irq_enabled" is
inconsistent with real hardware IRQ enabling state.

So this patch is to fix this issue, firstly init "irq_enabled" flag
before binding sensors to thermal zone. Also change to use the function
irq_get_irqchip_state() to read back real interrupt line state.

Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
 drivers/thermal/hisi_thermal.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
index 7a3e5d8..982ffd1 100644
--- a/drivers/thermal/hisi_thermal.c
+++ b/drivers/thermal/hisi_thermal.c
@@ -343,6 +343,10 @@ static int hisi_thermal_probe(struct platform_device *pdev)
 		return ret;
 	}
 
+	hisi_thermal_enable_bind_irq_sensor(data);
+	irq_get_irqchip_state(data->irq, IRQCHIP_STATE_MASKED,
+			      &data->irq_enabled);
+
 	for (i = 0; i < HISI_MAX_SENSORS; ++i) {
 		ret = hisi_thermal_register_sensor(pdev, data,
 						   &data->sensors[i], i);
@@ -353,9 +357,6 @@ static int hisi_thermal_probe(struct platform_device *pdev)
 			hisi_thermal_toggle_sensor(&data->sensors[i], true);
 	}
 
-	hisi_thermal_enable_bind_irq_sensor(data);
-	data->irq_enabled = true;
-
 	return 0;
 }
 
-- 
1.9.1

[PATCH v2 4/5] arm64: dts: register Hi6220's thermal sensor

[Leo Yan]

Bind thermal sensor driver for Hi6220.

Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index f588be9..50ba1b0 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -313,5 +313,14 @@
 			interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
 			#mbox-cells = <3>;
 		};
+
+		tsensor: tsensor@0,f7030700 {
+			compatible = "hisilicon,tsensor";
+			reg = <0x0 0xf7030700 0x0 0x1000>;
+			interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&sys_ctrl 22>;
+			clock-names = "thermal_clk";
+			#thermal-sensor-cells = <1>;
+		};
 	};
 };
-- 
1.9.1

[PATCH v2 4/5] arm64: dts: register Hi6220's thermal sensor

[Leo Yan]

Bind thermal sensor driver for Hi6220.

Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index f588be9..50ba1b0 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -313,5 +313,14 @@
 			interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
 			#mbox-cells = <3>;
 		};
+
+		tsensor: tsensor at 0,f7030700 {
+			compatible = "hisilicon,tsensor";
+			reg = <0x0 0xf7030700 0x0 0x1000>;
+			interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&sys_ctrl 22>;
+			clock-names = "thermal_clk";
+			#thermal-sensor-cells = <1>;
+		};
 	};
 };
-- 
1.9.1

[PATCH v2 5/5] arm64: dts: register Hi6220's thermal zone for power allocator

[Leo Yan]

With profiling Hi6220's power modeling so get dynamic coefficient and
sustainable power. So pass these parameters from DT.

Now enable power allocator with only one actor for CPU part, so directly
use cluster0's thermal sensor for monitoring temperature.

Reviewed-by: Javi Merino <javi.merino@arm.com>
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 33 +++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 50ba1b0..d8b963c 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -6,6 +6,7 @@
 
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/clock/hi6220-clock.h>
+#include <dt-bindings/thermal/thermal.h>
 
 / {
 	compatible = "hisilicon,hi6220";
@@ -87,6 +88,7 @@
 			cooling-max-level = <0>;
 			#cooling-cells = <2>; /* min followed by max */
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
+			dynamic-power-coefficient = <311>;
 		};
 
 		cpu1: cpu@1 {
@@ -322,5 +324,36 @@
 			clock-names = "thermal_clk";
 			#thermal-sensor-cells = <1>;
 		};
+
+		thermal-zones {
+
+			cls0: cls0 {
+				polling-delay = <1000>;
+				polling-delay-passive = <100>;
+				sustainable-power = <3326>;
+
+				/* sensor ID */
+				thermal-sensors = <&tsensor 2>;
+
+				trips {
+					threshold: trip-point@0 {
+						temperature = <65000>;
+						type = "passive";
+					};
+
+					target: trip-point@1 {
+						temperature = <75000>;
+						type = "passive";
+					};
+				};
+
+				cooling-maps {
+					map0 {
+						trip = <&target>;
+						cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+					};
+				};
+			};
+		};
 	};
 };
-- 
1.9.1

[PATCH v2 5/5] arm64: dts: register Hi6220's thermal zone for power allocator

[Leo Yan]

With profiling Hi6220's power modeling so get dynamic coefficient and
sustainable power. So pass these parameters from DT.

Now enable power allocator with only one actor for CPU part, so directly
use cluster0's thermal sensor for monitoring temperature.

Reviewed-by: Javi Merino <javi.merino@arm.com>
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 33 +++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 50ba1b0..d8b963c 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -6,6 +6,7 @@
 
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/clock/hi6220-clock.h>
+#include <dt-bindings/thermal/thermal.h>
 
 / {
 	compatible = "hisilicon,hi6220";
@@ -87,6 +88,7 @@
 			cooling-max-level = <0>;
 			#cooling-cells = <2>; /* min followed by max */
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
+			dynamic-power-coefficient = <311>;
 		};
 
 		cpu1: cpu at 1 {
@@ -322,5 +324,36 @@
 			clock-names = "thermal_clk";
 			#thermal-sensor-cells = <1>;
 		};
+
+		thermal-zones {
+
+			cls0: cls0 {
+				polling-delay = <1000>;
+				polling-delay-passive = <100>;
+				sustainable-power = <3326>;
+
+				/* sensor ID */
+				thermal-sensors = <&tsensor 2>;
+
+				trips {
+					threshold: trip-point at 0 {
+						temperature = <65000>;
+						type = "passive";
+					};
+
+					target: trip-point at 1 {
+						temperature = <75000>;
+						type = "passive";
+					};
+				};
+
+				cooling-maps {
+					map0 {
+						trip = <&target>;
+						cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+					};
+				};
+			};
+		};
 	};
 };
-- 
1.9.1

Re: [PATCH v2 1/5] thermal: change "hysteresis" as optional property

[Javi Merino]

On Fri, Feb 26, 2016 at 11:43:43AM +0800, Leo Yan wrote:
> The property "hysteresis" is mandatory for trip points, so if without
> it the thermal zone cannot register successfully. But "hysteresis" is
> ignored in the thermal subsystem and only inquired by several thermal
> sensor drivers.
> 
> So change "hysteresis" as optional properties.

I had forgotten that hysteresis is enforced in DT.  Thanks for fixing
this!
 
> Signed-off-by: Leo Yan <leo.yan@linaro.org>
> ---
>  Documentation/devicetree/bindings/thermal/thermal.txt | 9 +++++----
>  drivers/thermal/of-thermal.c                          | 9 ++++-----
>  2 files changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
> index 41b817f..7d79e77 100644
> --- a/Documentation/devicetree/bindings/thermal/thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
> @@ -89,10 +89,6 @@ Required properties:
>    Type: signed		in millicelsius.
>    Size: one cell
>  
> -- hysteresis:		A low hysteresis value on temperature property (above).
> -  Type: unsigned	This is a relative value, in millicelsius.
> -  Size: one cell
> -
>  - type:			a string containing the trip type. Expected values are:
>  	"active":	A trip point to enable active cooling
>  	"passive":	A trip point to enable passive cooling
> @@ -100,6 +96,11 @@ Required properties:
>  	"critical":	Hardware not reliable.
>    Type: string
>  
> +Optional properties:
> +- hysteresis:		A low hysteresis value on temperature property (above).
> +  Type: unsigned	This is a relative value, in millicelsius.
> +  Size: one cell
> +
>  * Cooling device maps
>  
>  The cooling device maps node is a node to describe how cooling devices
> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
> index 9043f8f..ab05500 100644
> --- a/drivers/thermal/of-thermal.c
> +++ b/drivers/thermal/of-thermal.c
> @@ -689,11 +689,10 @@ static int thermal_of_populate_trip(struct device_node *np,
>  	trip->temperature = prop;
>  
>  	ret = of_property_read_u32(np, "hysteresis", &prop);
> -	if (ret < 0) {
> -		pr_err("missing hysteresis property\n");
> -		return ret;
> -	}
> -	trip->hysteresis = prop;
> +	if (ret < 0)
> +		pr_warning("missing hysteresis property\n");

I'd remove the warning.  It is an optional parameter, so there is no
need to warn about something going wrong.  As you say in the commit
log, it is ignored in the thermal subsystem and only used by some
sensors so no need to warn about it missing.

Other than that, I'm happy to see this merged.

Acked-by: Javi Merino <javi.merino@arm.com>

> +	else
> +		trip->hysteresis = prop;
>  
>  	ret = thermal_of_get_trip_type(np, &trip->type);
>  	if (ret < 0) {
> -- 
> 1.9.1
> 

Re: [PATCH v2 1/5] thermal: change "hysteresis" as optional property

[Javi Merino]

On Fri, Feb 26, 2016 at 11:43:43AM +0800, Leo Yan wrote:
> The property "hysteresis" is mandatory for trip points, so if without
> it the thermal zone cannot register successfully. But "hysteresis" is
> ignored in the thermal subsystem and only inquired by several thermal
> sensor drivers.
> 
> So change "hysteresis" as optional properties.

I had forgotten that hysteresis is enforced in DT.  Thanks for fixing
this!
 
> Signed-off-by: Leo Yan <leo.yan-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>  Documentation/devicetree/bindings/thermal/thermal.txt | 9 +++++----
>  drivers/thermal/of-thermal.c                          | 9 ++++-----
>  2 files changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
> index 41b817f..7d79e77 100644
> --- a/Documentation/devicetree/bindings/thermal/thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
> @@ -89,10 +89,6 @@ Required properties:
>    Type: signed		in millicelsius.
>    Size: one cell
>  
> -- hysteresis:		A low hysteresis value on temperature property (above).
> -  Type: unsigned	This is a relative value, in millicelsius.
> -  Size: one cell
> -
>  - type:			a string containing the trip type. Expected values are:
>  	"active":	A trip point to enable active cooling
>  	"passive":	A trip point to enable passive cooling
> @@ -100,6 +96,11 @@ Required properties:
>  	"critical":	Hardware not reliable.
>    Type: string
>  
> +Optional properties:
> +- hysteresis:		A low hysteresis value on temperature property (above).
> +  Type: unsigned	This is a relative value, in millicelsius.
> +  Size: one cell
> +
>  * Cooling device maps
>  
>  The cooling device maps node is a node to describe how cooling devices
> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
> index 9043f8f..ab05500 100644
> --- a/drivers/thermal/of-thermal.c
> +++ b/drivers/thermal/of-thermal.c
> @@ -689,11 +689,10 @@ static int thermal_of_populate_trip(struct device_node *np,
>  	trip->temperature = prop;
>  
>  	ret = of_property_read_u32(np, "hysteresis", &prop);
> -	if (ret < 0) {
> -		pr_err("missing hysteresis property\n");
> -		return ret;
> -	}
> -	trip->hysteresis = prop;
> +	if (ret < 0)
> +		pr_warning("missing hysteresis property\n");

I'd remove the warning.  It is an optional parameter, so there is no
need to warn about something going wrong.  As you say in the commit
log, it is ignored in the thermal subsystem and only used by some
sensors so no need to warn about it missing.

Other than that, I'm happy to see this merged.

Acked-by: Javi Merino <javi.merino-5wv7dgnIgG8@public.gmane.org>

> +	else
> +		trip->hysteresis = prop;
>  
>  	ret = thermal_of_get_trip_type(np, &trip->type);
>  	if (ret < 0) {
> -- 
> 1.9.1
> 
--
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 v2 1/5] thermal: change "hysteresis" as optional property

[Javi Merino]

On Fri, Feb 26, 2016 at 11:43:43AM +0800, Leo Yan wrote:
> The property "hysteresis" is mandatory for trip points, so if without
> it the thermal zone cannot register successfully. But "hysteresis" is
> ignored in the thermal subsystem and only inquired by several thermal
> sensor drivers.
> 
> So change "hysteresis" as optional properties.

I had forgotten that hysteresis is enforced in DT.  Thanks for fixing
this!
 
> Signed-off-by: Leo Yan <leo.yan@linaro.org>
> ---
>  Documentation/devicetree/bindings/thermal/thermal.txt | 9 +++++----
>  drivers/thermal/of-thermal.c                          | 9 ++++-----
>  2 files changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
> index 41b817f..7d79e77 100644
> --- a/Documentation/devicetree/bindings/thermal/thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
> @@ -89,10 +89,6 @@ Required properties:
>    Type: signed		in millicelsius.
>    Size: one cell
>  
> -- hysteresis:		A low hysteresis value on temperature property (above).
> -  Type: unsigned	This is a relative value, in millicelsius.
> -  Size: one cell
> -
>  - type:			a string containing the trip type. Expected values are:
>  	"active":	A trip point to enable active cooling
>  	"passive":	A trip point to enable passive cooling
> @@ -100,6 +96,11 @@ Required properties:
>  	"critical":	Hardware not reliable.
>    Type: string
>  
> +Optional properties:
> +- hysteresis:		A low hysteresis value on temperature property (above).
> +  Type: unsigned	This is a relative value, in millicelsius.
> +  Size: one cell
> +
>  * Cooling device maps
>  
>  The cooling device maps node is a node to describe how cooling devices
> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
> index 9043f8f..ab05500 100644
> --- a/drivers/thermal/of-thermal.c
> +++ b/drivers/thermal/of-thermal.c
> @@ -689,11 +689,10 @@ static int thermal_of_populate_trip(struct device_node *np,
>  	trip->temperature = prop;
>  
>  	ret = of_property_read_u32(np, "hysteresis", &prop);
> -	if (ret < 0) {
> -		pr_err("missing hysteresis property\n");
> -		return ret;
> -	}
> -	trip->hysteresis = prop;
> +	if (ret < 0)
> +		pr_warning("missing hysteresis property\n");

I'd remove the warning.  It is an optional parameter, so there is no
need to warn about something going wrong.  As you say in the commit
log, it is ignored in the thermal subsystem and only used by some
sensors so no need to warn about it missing.

Other than that, I'm happy to see this merged.

Acked-by: Javi Merino <javi.merino@arm.com>

> +	else
> +		trip->hysteresis = prop;
>  
>  	ret = thermal_of_get_trip_type(np, &trip->type);
>  	if (ret < 0) {
> -- 
> 1.9.1
> 

Re: [PATCH v2 1/5] thermal: change "hysteresis" as optional property

[Eduardo Valentin]

Hi Leo,

On Fri, Feb 26, 2016 at 11:43:43AM +0800, Leo Yan wrote:
> The property "hysteresis" is mandatory for trip points, so if without
> it the thermal zone cannot register successfully. But "hysteresis" is
> ignored in the thermal subsystem and only inquired by several thermal
> sensor drivers.

I am not sure this a good direction to go. Remember that Linux
implementation not necessarily has to be the implication of the DT
binding. Hysteresis is a property that plays a significant role on
thermal control systems, which in many cases avoid overshooting cooling
actions. Having the DT writer to explicitly set it to 0 means that zone
does not suffer of overshooting and does not need hysteresis.

If the Linux thermal subsystem has a problem with handling hysteresis, I
would rather fix Linux code than relaxing the DT binding. Or if you
still believe hysteresis is really optional, I would prefer to see a
better justification than "Linux ignores it".

BR,

Eduardo

Re: [PATCH v2 1/5] thermal: change "hysteresis" as optional property

[Eduardo Valentin]

Hi Leo,

On Fri, Feb 26, 2016 at 11:43:43AM +0800, Leo Yan wrote:
> The property "hysteresis" is mandatory for trip points, so if without
> it the thermal zone cannot register successfully. But "hysteresis" is
> ignored in the thermal subsystem and only inquired by several thermal
> sensor drivers.

I am not sure this a good direction to go. Remember that Linux
implementation not necessarily has to be the implication of the DT
binding. Hysteresis is a property that plays a significant role on
thermal control systems, which in many cases avoid overshooting cooling
actions. Having the DT writer to explicitly set it to 0 means that zone
does not suffer of overshooting and does not need hysteresis.

If the Linux thermal subsystem has a problem with handling hysteresis, I
would rather fix Linux code than relaxing the DT binding. Or if you
still believe hysteresis is really optional, I would prefer to see a
better justification than "Linux ignores it".

BR,

Eduardo
--
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 v2 1/5] thermal: change "hysteresis" as optional property

[Eduardo Valentin]

Hi Leo,

On Fri, Feb 26, 2016 at 11:43:43AM +0800, Leo Yan wrote:
> The property "hysteresis" is mandatory for trip points, so if without
> it the thermal zone cannot register successfully. But "hysteresis" is
> ignored in the thermal subsystem and only inquired by several thermal
> sensor drivers.

I am not sure this a good direction to go. Remember that Linux
implementation not necessarily has to be the implication of the DT
binding. Hysteresis is a property that plays a significant role on
thermal control systems, which in many cases avoid overshooting cooling
actions. Having the DT writer to explicitly set it to 0 means that zone
does not suffer of overshooting and does not need hysteresis.

If the Linux thermal subsystem has a problem with handling hysteresis, I
would rather fix Linux code than relaxing the DT binding. Or if you
still believe hysteresis is really optional, I would prefer to see a
better justification than "Linux ignores it".

BR,

Eduardo

Re: [PATCH v2 1/5] thermal: change "hysteresis" as optional property

[Leo Yan]

Hi Eduardo,

On Thu, Mar 03, 2016 at 08:29:44AM -0800, Eduardo Valentin wrote:
> Hi Leo,
> 
> On Fri, Feb 26, 2016 at 11:43:43AM +0800, Leo Yan wrote:
> > The property "hysteresis" is mandatory for trip points, so if without
> > it the thermal zone cannot register successfully. But "hysteresis" is
> > ignored in the thermal subsystem and only inquired by several thermal
> > sensor drivers.
> 
> I am not sure this a good direction to go. Remember that Linux
> implementation not necessarily has to be the implication of the DT
> binding. Hysteresis is a property that plays a significant role on
> thermal control systems, which in many cases avoid overshooting cooling
> actions. Having the DT writer to explicitly set it to 0 means that zone
> does not suffer of overshooting and does not need hysteresis.

After review current code, the "hysteresis" is used to calculate
temperature falling threshold with a more conservative value; so that
finally avoid overshooting issue.

Please confirm if is my understanding correct or not?

> If the Linux thermal subsystem has a problem with handling hysteresis, I
> would rather fix Linux code than relaxing the DT binding. Or if you
> still believe hysteresis is really optional, I would prefer to see a
> better justification than "Linux ignores it".

If we think about power allocator governor, PID's two parameters are
also used to dismiss overshooting issue: one is k_po (proportional
term), another is k_i (integral term). So that means after we apply
power allocator governor, we don't need parameter "hysteresis" due PID
algorithm can automatically dismiss potential errors.

Does this make sense?

Thanks,
Leo Yan

[PATCH v2 1/5] thermal: change "hysteresis" as optional property

[Leo Yan]

Hi Eduardo,

On Thu, Mar 03, 2016 at 08:29:44AM -0800, Eduardo Valentin wrote:
> Hi Leo,
> 
> On Fri, Feb 26, 2016 at 11:43:43AM +0800, Leo Yan wrote:
> > The property "hysteresis" is mandatory for trip points, so if without
> > it the thermal zone cannot register successfully. But "hysteresis" is
> > ignored in the thermal subsystem and only inquired by several thermal
> > sensor drivers.
> 
> I am not sure this a good direction to go. Remember that Linux
> implementation not necessarily has to be the implication of the DT
> binding. Hysteresis is a property that plays a significant role on
> thermal control systems, which in many cases avoid overshooting cooling
> actions. Having the DT writer to explicitly set it to 0 means that zone
> does not suffer of overshooting and does not need hysteresis.

After review current code, the "hysteresis" is used to calculate
temperature falling threshold with a more conservative value; so that
finally avoid overshooting issue.

Please confirm if is my understanding correct or not?

> If the Linux thermal subsystem has a problem with handling hysteresis, I
> would rather fix Linux code than relaxing the DT binding. Or if you
> still believe hysteresis is really optional, I would prefer to see a
> better justification than "Linux ignores it".

If we think about power allocator governor, PID's two parameters are
also used to dismiss overshooting issue: one is k_po (proportional
term), another is k_i (integral term). So that means after we apply
power allocator governor, we don't need parameter "hysteresis" due PID
algorithm can automatically dismiss potential errors.

Does this make sense?

Thanks,
Leo Yan

Re: [PATCH v2 1/5] thermal: change "hysteresis" as optional property

[Javi Merino]

On Fri, Mar 04, 2016 at 11:03:49AM +0800, Leo Yan wrote:
> Hi Eduardo,
> 
> On Thu, Mar 03, 2016 at 08:29:44AM -0800, Eduardo Valentin wrote:
> > Hi Leo,
> > 
> > On Fri, Feb 26, 2016 at 11:43:43AM +0800, Leo Yan wrote:
> > > The property "hysteresis" is mandatory for trip points, so if without
> > > it the thermal zone cannot register successfully. But "hysteresis" is
> > > ignored in the thermal subsystem and only inquired by several thermal
> > > sensor drivers.
> > 
> > I am not sure this a good direction to go. Remember that Linux
> > implementation not necessarily has to be the implication of the DT
> > binding. Hysteresis is a property that plays a significant role on
> > thermal control systems, which in many cases avoid overshooting cooling
> > actions. Having the DT writer to explicitly set it to 0 means that zone
> > does not suffer of overshooting and does not need hysteresis.
> 
> After review current code, the "hysteresis" is used to calculate
> temperature falling threshold with a more conservative value; so that
> finally avoid overshooting issue.
> 
> Please confirm if is my understanding correct or not?
> 
> > If the Linux thermal subsystem has a problem with handling hysteresis, I
> > would rather fix Linux code than relaxing the DT binding. Or if you
> > still believe hysteresis is really optional, I would prefer to see a
> > better justification than "Linux ignores it".

I see it the other way round, Is hysteresis a property that, without
it, the thermal code can't configure itself so it fails to create the
trip point?  The current code goes "There is no hysteresis for this
property, I don't know how to set up this trip point!".  I think we
can do better than this.

> If we think about power allocator governor, PID's two parameters are
> also used to dismiss overshooting issue: one is k_po (proportional
> term), another is k_i (integral term). So that means after we apply
> power allocator governor, we don't need parameter "hysteresis" due PID
> algorithm can automatically dismiss potential errors.

I disagree.  We shouldn't base DT decisions based on only one
governor in linux.  Having said that, AFAICS all governors currently
ignore hysteresis.

Cheers,
Javi

[PATCH v2 1/5] thermal: change "hysteresis" as optional property

[Javi Merino]

On Fri, Mar 04, 2016 at 11:03:49AM +0800, Leo Yan wrote:
> Hi Eduardo,
> 
> On Thu, Mar 03, 2016 at 08:29:44AM -0800, Eduardo Valentin wrote:
> > Hi Leo,
> > 
> > On Fri, Feb 26, 2016 at 11:43:43AM +0800, Leo Yan wrote:
> > > The property "hysteresis" is mandatory for trip points, so if without
> > > it the thermal zone cannot register successfully. But "hysteresis" is
> > > ignored in the thermal subsystem and only inquired by several thermal
> > > sensor drivers.
> > 
> > I am not sure this a good direction to go. Remember that Linux
> > implementation not necessarily has to be the implication of the DT
> > binding. Hysteresis is a property that plays a significant role on
> > thermal control systems, which in many cases avoid overshooting cooling
> > actions. Having the DT writer to explicitly set it to 0 means that zone
> > does not suffer of overshooting and does not need hysteresis.
> 
> After review current code, the "hysteresis" is used to calculate
> temperature falling threshold with a more conservative value; so that
> finally avoid overshooting issue.
> 
> Please confirm if is my understanding correct or not?
> 
> > If the Linux thermal subsystem has a problem with handling hysteresis, I
> > would rather fix Linux code than relaxing the DT binding. Or if you
> > still believe hysteresis is really optional, I would prefer to see a
> > better justification than "Linux ignores it".

I see it the other way round, Is hysteresis a property that, without
it, the thermal code can't configure itself so it fails to create the
trip point?  The current code goes "There is no hysteresis for this
property, I don't know how to set up this trip point!".  I think we
can do better than this.

> If we think about power allocator governor, PID's two parameters are
> also used to dismiss overshooting issue: one is k_po (proportional
> term), another is k_i (integral term). So that means after we apply
> power allocator governor, we don't need parameter "hysteresis" due PID
> algorithm can automatically dismiss potential errors.

I disagree.  We shouldn't base DT decisions based on only one
governor in linux.  Having said that, AFAICS all governors currently
ignore hysteresis.

Cheers,
Javi

Re: [PATCH v2 1/5] thermal: change "hysteresis" as optional property

[Leo Yan]

Hi Eduardo,

On Fri, Mar 04, 2016 at 11:57:53AM +0000, Javi Merino wrote:
> On Fri, Mar 04, 2016 at 11:03:49AM +0800, Leo Yan wrote:
> > On Thu, Mar 03, 2016 at 08:29:44AM -0800, Eduardo Valentin wrote:
> > > On Fri, Feb 26, 2016 at 11:43:43AM +0800, Leo Yan wrote:

[...]

> > > > The property "hysteresis" is mandatory for trip points, so if without
> > > > it the thermal zone cannot register successfully. But "hysteresis" is
> > > > ignored in the thermal subsystem and only inquired by several thermal
> > > > sensor drivers.
> > > 
> > > If the Linux thermal subsystem has a problem with handling hysteresis, I
> > > would rather fix Linux code than relaxing the DT binding. Or if you
> > > still believe hysteresis is really optional, I would prefer to see a
> > > better justification than "Linux ignores it".
> 
> I see it the other way round, Is hysteresis a property that, without
> it, the thermal code can't configure itself so it fails to create the
> trip point?  The current code goes "There is no hysteresis for this
> property, I don't know how to set up this trip point!".  I think we
> can do better than this.

Do you agree with Javi's suggestion? If you think it's okay, I will
move on to send out a new version patch based on Javi's comments.

Thanks,
Leo Yan

[PATCH v2 1/5] thermal: change "hysteresis" as optional property

[Leo Yan]

Hi Eduardo,

On Fri, Mar 04, 2016 at 11:57:53AM +0000, Javi Merino wrote:
> On Fri, Mar 04, 2016 at 11:03:49AM +0800, Leo Yan wrote:
> > On Thu, Mar 03, 2016 at 08:29:44AM -0800, Eduardo Valentin wrote:
> > > On Fri, Feb 26, 2016 at 11:43:43AM +0800, Leo Yan wrote:

[...]

> > > > The property "hysteresis" is mandatory for trip points, so if without
> > > > it the thermal zone cannot register successfully. But "hysteresis" is
> > > > ignored in the thermal subsystem and only inquired by several thermal
> > > > sensor drivers.
> > > 
> > > If the Linux thermal subsystem has a problem with handling hysteresis, I
> > > would rather fix Linux code than relaxing the DT binding. Or if you
> > > still believe hysteresis is really optional, I would prefer to see a
> > > better justification than "Linux ignores it".
> 
> I see it the other way round, Is hysteresis a property that, without
> it, the thermal code can't configure itself so it fails to create the
> trip point?  The current code goes "There is no hysteresis for this
> property, I don't know how to set up this trip point!".  I think we
> can do better than this.

Do you agree with Javi's suggestion? If you think it's okay, I will
move on to send out a new version patch based on Javi's comments.

Thanks,
Leo Yan

Re: [PATCH v2 1/5] thermal: change "hysteresis" as optional property

[Eduardo Valentin]

On Tue, Mar 08, 2016 at 09:57:43PM +0800, Leo Yan wrote:
> Hi Eduardo,
> 
> On Fri, Mar 04, 2016 at 11:57:53AM +0000, Javi Merino wrote:
> > On Fri, Mar 04, 2016 at 11:03:49AM +0800, Leo Yan wrote:
> > > On Thu, Mar 03, 2016 at 08:29:44AM -0800, Eduardo Valentin wrote:
> > > > On Fri, Feb 26, 2016 at 11:43:43AM +0800, Leo Yan wrote:
> 
> [...]
> 
> > > > > The property "hysteresis" is mandatory for trip points, so if without
> > > > > it the thermal zone cannot register successfully. But "hysteresis" is
> > > > > ignored in the thermal subsystem and only inquired by several thermal
> > > > > sensor drivers.
> > > > 
> > > > If the Linux thermal subsystem has a problem with handling hysteresis, I
> > > > would rather fix Linux code than relaxing the DT binding. Or if you
> > > > still believe hysteresis is really optional, I would prefer to see a
> > > > better justification than "Linux ignores it".
> > 
> > I see it the other way round, Is hysteresis a property that, without
> > it, the thermal code can't configure itself so it fails to create the
> > trip point?  The current code goes "There is no hysteresis for this
> > property, I don't know how to set up this trip point!".  I think we
> > can do better than this.
> 
> Do you agree with Javi's suggestion? If you think it's okay, I will
> move on to send out a new version patch based on Javi's comments.

No I don't. This discussion so far has been about Linux code. I still
havent seen an argument explaining why hysteresis has to be optional.

BR,

> 
> Thanks,
> Leo Yan

[PATCH v2 1/5] thermal: change "hysteresis" as optional property

[Eduardo Valentin]

On Tue, Mar 08, 2016 at 09:57:43PM +0800, Leo Yan wrote:
> Hi Eduardo,
> 
> On Fri, Mar 04, 2016 at 11:57:53AM +0000, Javi Merino wrote:
> > On Fri, Mar 04, 2016 at 11:03:49AM +0800, Leo Yan wrote:
> > > On Thu, Mar 03, 2016 at 08:29:44AM -0800, Eduardo Valentin wrote:
> > > > On Fri, Feb 26, 2016 at 11:43:43AM +0800, Leo Yan wrote:
> 
> [...]
> 
> > > > > The property "hysteresis" is mandatory for trip points, so if without
> > > > > it the thermal zone cannot register successfully. But "hysteresis" is
> > > > > ignored in the thermal subsystem and only inquired by several thermal
> > > > > sensor drivers.
> > > > 
> > > > If the Linux thermal subsystem has a problem with handling hysteresis, I
> > > > would rather fix Linux code than relaxing the DT binding. Or if you
> > > > still believe hysteresis is really optional, I would prefer to see a
> > > > better justification than "Linux ignores it".
> > 
> > I see it the other way round, Is hysteresis a property that, without
> > it, the thermal code can't configure itself so it fails to create the
> > trip point?  The current code goes "There is no hysteresis for this
> > property, I don't know how to set up this trip point!".  I think we
> > can do better than this.
> 
> Do you agree with Javi's suggestion? If you think it's okay, I will
> move on to send out a new version patch based on Javi's comments.

No I don't. This discussion so far has been about Linux code. I still
havent seen an argument explaining why hysteresis has to be optional.

BR,

> 
> Thanks,
> Leo Yan

Re: [PATCH v2 1/5] thermal: change "hysteresis" as optional property

[Javi Merino]

On Tue, Mar 08, 2016 at 12:55:59PM -0800, Eduardo Valentin wrote:
> On Tue, Mar 08, 2016 at 09:57:43PM +0800, Leo Yan wrote:
> > Hi Eduardo,
> > 
> > On Fri, Mar 04, 2016 at 11:57:53AM +0000, Javi Merino wrote:
> > > On Fri, Mar 04, 2016 at 11:03:49AM +0800, Leo Yan wrote:
> > > > On Thu, Mar 03, 2016 at 08:29:44AM -0800, Eduardo Valentin wrote:
> > > > > On Fri, Feb 26, 2016 at 11:43:43AM +0800, Leo Yan wrote:
> > 
> > [...]
> > 
> > > > > > The property "hysteresis" is mandatory for trip points, so if without
> > > > > > it the thermal zone cannot register successfully. But "hysteresis" is
> > > > > > ignored in the thermal subsystem and only inquired by several thermal
> > > > > > sensor drivers.
> > > > > 
> > > > > If the Linux thermal subsystem has a problem with handling hysteresis, I
> > > > > would rather fix Linux code than relaxing the DT binding. Or if you
> > > > > still believe hysteresis is really optional, I would prefer to see a
> > > > > better justification than "Linux ignores it".
> > > 
> > > I see it the other way round, Is hysteresis a property that, without
> > > it, the thermal code can't configure itself so it fails to create the
> > > trip point?  The current code goes "There is no hysteresis for this
> > > property, I don't know how to set up this trip point!".  I think we
> > > can do better than this.
> > 
> > Do you agree with Javi's suggestion? If you think it's okay, I will
> > move on to send out a new version patch based on Javi's comments.
> 
> No I don't. This discussion so far has been about Linux code. I still
> havent seen an argument explaining why hysteresis has to be optional.

Fair enough.  Looks like I'm holding this driver from being
upstreamed, so I'll back off.

Leo, sorry for misguiding you.  Please bring back the hysteresis
property you had in v1.

[PATCH v2 1/5] thermal: change "hysteresis" as optional property

[Javi Merino]

On Tue, Mar 08, 2016 at 12:55:59PM -0800, Eduardo Valentin wrote:
> On Tue, Mar 08, 2016 at 09:57:43PM +0800, Leo Yan wrote:
> > Hi Eduardo,
> > 
> > On Fri, Mar 04, 2016 at 11:57:53AM +0000, Javi Merino wrote:
> > > On Fri, Mar 04, 2016 at 11:03:49AM +0800, Leo Yan wrote:
> > > > On Thu, Mar 03, 2016 at 08:29:44AM -0800, Eduardo Valentin wrote:
> > > > > On Fri, Feb 26, 2016 at 11:43:43AM +0800, Leo Yan wrote:
> > 
> > [...]
> > 
> > > > > > The property "hysteresis" is mandatory for trip points, so if without
> > > > > > it the thermal zone cannot register successfully. But "hysteresis" is
> > > > > > ignored in the thermal subsystem and only inquired by several thermal
> > > > > > sensor drivers.
> > > > > 
> > > > > If the Linux thermal subsystem has a problem with handling hysteresis, I
> > > > > would rather fix Linux code than relaxing the DT binding. Or if you
> > > > > still believe hysteresis is really optional, I would prefer to see a
> > > > > better justification than "Linux ignores it".
> > > 
> > > I see it the other way round, Is hysteresis a property that, without
> > > it, the thermal code can't configure itself so it fails to create the
> > > trip point?  The current code goes "There is no hysteresis for this
> > > property, I don't know how to set up this trip point!".  I think we
> > > can do better than this.
> > 
> > Do you agree with Javi's suggestion? If you think it's okay, I will
> > move on to send out a new version patch based on Javi's comments.
> 
> No I don't. This discussion so far has been about Linux code. I still
> havent seen an argument explaining why hysteresis has to be optional.

Fair enough.  Looks like I'm holding this driver from being
upstreamed, so I'll back off.

Leo, sorry for misguiding you.  Please bring back the hysteresis
property you had in v1.

Re: [PATCH v2 1/5] thermal: change "hysteresis" as optional property

[Leo Yan]

Hi Javi,

Sorry for late response.

On Wed, Mar 09, 2016 at 11:10:52AM +0000, Javi Merino wrote:
> On Tue, Mar 08, 2016 at 12:55:59PM -0800, Eduardo Valentin wrote:
> > On Tue, Mar 08, 2016 at 09:57:43PM +0800, Leo Yan wrote:

[...]

> > > > > > > The property "hysteresis" is mandatory for trip points, so if without
> > > > > > > it the thermal zone cannot register successfully. But "hysteresis" is
> > > > > > > ignored in the thermal subsystem and only inquired by several thermal
> > > > > > > sensor drivers.
> > > > > > 
> > > > > > If the Linux thermal subsystem has a problem with handling hysteresis, I
> > > > > > would rather fix Linux code than relaxing the DT binding. Or if you
> > > > > > still believe hysteresis is really optional, I would prefer to see a
> > > > > > better justification than "Linux ignores it".
> > > > 
> > > > I see it the other way round, Is hysteresis a property that, without
> > > > it, the thermal code can't configure itself so it fails to create the
> > > > trip point?  The current code goes "There is no hysteresis for this
> > > > property, I don't know how to set up this trip point!".  I think we
> > > > can do better than this.
> > > 
> > > Do you agree with Javi's suggestion? If you think it's okay, I will
> > > move on to send out a new version patch based on Javi's comments.
> > 
> > No I don't. This discussion so far has been about Linux code. I still
> > havent seen an argument explaining why hysteresis has to be optional.
> 
> Fair enough.  Looks like I'm holding this driver from being
> upstreamed, so I'll back off.
> 
> Leo, sorry for misguiding you.  Please bring back the hysteresis
> property you had in v1.

Not at all. I will add back hysteresis property and resend new patches.

Thanks,
Leo Yan

[PATCH v2 1/5] thermal: change "hysteresis" as optional property

[Leo Yan]

Hi Javi,

Sorry for late response.

On Wed, Mar 09, 2016 at 11:10:52AM +0000, Javi Merino wrote:
> On Tue, Mar 08, 2016 at 12:55:59PM -0800, Eduardo Valentin wrote:
> > On Tue, Mar 08, 2016 at 09:57:43PM +0800, Leo Yan wrote:

[...]

> > > > > > > The property "hysteresis" is mandatory for trip points, so if without
> > > > > > > it the thermal zone cannot register successfully. But "hysteresis" is
> > > > > > > ignored in the thermal subsystem and only inquired by several thermal
> > > > > > > sensor drivers.
> > > > > > 
> > > > > > If the Linux thermal subsystem has a problem with handling hysteresis, I
> > > > > > would rather fix Linux code than relaxing the DT binding. Or if you
> > > > > > still believe hysteresis is really optional, I would prefer to see a
> > > > > > better justification than "Linux ignores it".
> > > > 
> > > > I see it the other way round, Is hysteresis a property that, without
> > > > it, the thermal code can't configure itself so it fails to create the
> > > > trip point?  The current code goes "There is no hysteresis for this
> > > > property, I don't know how to set up this trip point!".  I think we
> > > > can do better than this.
> > > 
> > > Do you agree with Javi's suggestion? If you think it's okay, I will
> > > move on to send out a new version patch based on Javi's comments.
> > 
> > No I don't. This discussion so far has been about Linux code. I still
> > havent seen an argument explaining why hysteresis has to be optional.
> 
> Fair enough.  Looks like I'm holding this driver from being
> upstreamed, so I'll back off.
> 
> Leo, sorry for misguiding you.  Please bring back the hysteresis
> property you had in v1.

Not at all. I will add back hysteresis property and resend new patches.

Thanks,
Leo Yan