Thread (41 messages) 41 messages, 5 authors, 2014-11-18
STALE4132d

[PATCH 03/21] thermal: of: Extend of-thermal.c to provide number of non critical trip points

From: Lukasz Majewski <hidden>
Date: 2014-11-07 10:05:51
Also in: linux-pm, linux-samsung-soc

Hi Eduardo,
On Thu, Oct 09, 2014 at 06:38:39PM +0200, Lukasz Majewski wrote:
quoted
This patch extends the of-thermal.c to provide information about
number of available non critical (i.e. non HW) trip points in the
system.

Signed-off-by: Lukasz Majewski <redacted>
---
 drivers/thermal/of-thermal.c   | 12 ++++++++++++
 drivers/thermal/thermal_core.h |  5 +++++
 2 files changed, 17 insertions(+)
diff --git a/drivers/thermal/of-thermal.c
b/drivers/thermal/of-thermal.c index 23c8d6c..cd74e64 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -128,6 +128,18 @@ int of_thermal_is_trip_en(struct
thermal_zone_device *tz, int trip) return 1;
 }
 
+int of_thermal_get_non_crit_ntrips(struct thermal_zone_device *tz)
+{
+	struct __thermal_zone *data = tz->devdata;
+	int i;
+
+	for (i = 0; i < data->ntrips; i++)
+		if (data->trips[i].type != THERMAL_TRIP_CRITICAL)
+			continue;
+
+	return --i;
+}
+


I am not against this addition. But looks like we start to spread some
specific APIs that may not be used to other drivers.
Why do you think that this is a specific API? In the thermal OF we can
define trip point as "active", "passive", "hot" and "critical".

With the first three we can handle them and properly react. For the last
one SoC's PMU will power down the board.

Do you know if any board (e.g. from TI) is NOT supposed to shut down
when "critical" temperature is passed?

The real problem here is the accessibility to __thermal_trip and
__thermal_bind arrays.

Use case:
In the Exynos driver we do need to initialize TMU registers with
threshold temperatures.
The temperature is read via tz->ops->get_trip_temp() [1] (from
of-thermal.c).
Unfortunately, the current API is not exporting the number of
non-critical trip points to know how many times call [1].
Of course we could by hand instantiate [1] n times, but this looks for
me a bit clumsy.

Additionally, we now have implicit assumption about the order of defined
temperatures for trip points, but I think this is not a big issue.
Maybe having a
single API to provide a read-only copy the list / array of trips might
be a better approach. I will think of a better way.
Definitely. Exporting available trip points is crucial.
I also request you to document it accordingly.
Ok, I will do that.
quoted
 static int of_thermal_get_trend(struct thermal_zone_device *tz,
int trip, enum thermal_trend *trend)
 {
diff --git a/drivers/thermal/thermal_core.h
b/drivers/thermal/thermal_core.h index ed8ff05..334a7be 100644
--- a/drivers/thermal/thermal_core.h
+++ b/drivers/thermal/thermal_core.h
@@ -83,6 +83,7 @@ int of_parse_thermal_zones(void);
 void of_thermal_destroy_zones(void);
 int of_thermal_get_ntrips(struct thermal_zone_device *);
 int of_thermal_is_trip_en(struct thermal_zone_device *, int);
+int of_thermal_get_non_crit_ntrips(struct thermal_zone_device *);
 #else
 static inline int of_parse_thermal_zones(void) { return 0; }
 static inline void of_thermal_destroy_zones(void) { }
@@ -94,6 +95,10 @@ int of_thermal_is_trip_en(struct
thermal_zone_device *, int) {
 	return 0;
 }
+int of_thermal_get_non_crit_ntrips(struct thermal_zone_device *)
here, it is supposed to be static inline.
quoted
+{
+	return 0;
+}
 #endif
 
 #endif /* __THERMAL_CORE_H__ */
-- 
2.0.0.rc2


-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help