On Mon, 2020-07-13 at 17:03 +0200, Daniel Lezcano wrote:Hi Rui,
On 10/07/2020 15:51, Thara Gopinath wrote:
Thermal framework today supports monitoring for rising temperatures
and
subsequently initiating cooling action in case of a thermal trip
point
being crossed. There are scenarios where a SoC need some warming
action to
be activated if the temperature falls below a cetain permissible
limit.
Since warming action can be considered mirror opposite of cooling
action,
most of the thermal framework can be re-used to achieve this.
This patch series is yet another attempt to add support for
monitoring
falling temperature in thermal framework. Unlike the first
attempt[1]
(where a new property was added to thermal trip point binding to
indicate
direction of temperature monitoring), this series introduces a new
trip
point type (THERMAL_TRIP_COLD) to indicate a trip point at which
falling
temperature monitoring must be triggered. This patch series uses
Daniel
Lezcano's recently added thermal genetlink interface[2] to notify
userspace
of falling temperature and rising temperature at the cold trip
point. This
will enable a user space engine to trigger the relevant mitigation
for
falling temperature. At present, no support is added to any of the
thermal
governors to monitor and mitigate falling temperature at the cold
trip
point;rather all governors return doing nothing if triggered for a
cold
trip point. As future extension, monitoring of falling temperature
can be
added to the relevant thermal governor.
I agree we need a cold trip point in order to introduce the
functioning
temperature range in the thermal framework.
Rui, what is your opinion ?
I agree with the concept of "cold" trip point.
In this patch set, the cold trip point is defined with only netlink
event support. But there are still quite a lot of things unclear,
especially what we should do in thermal framework?
For example, to support this, we can
either
introduce both "cold" trip points and "warming devices", and introduce
new logic in thermal framework and governors to handle them,
Or
introduce "cold" trip point and "warming" device, but only
semantically, and treat them just like normal trip points and cooling
devices. And strictly define cooling state 0 as the state that
generates most heat, and define max cooling state as the state that
generates least heat. Then, say, we have a trip point at -10C, the
"warming" device is set to cooling state 0 when the temperature is
lower than -10C, and in most cases, this thermal zone is always in a
"overheating" state (temperature higher than -10C), and the "warming"
device for this thermal zone is "throttled" to generate as least heat
as possible. And this is pretty much what the current code has always
been doing, right?
I can not say which one is better for now as I don't have the
background of this requirement. It's nice that Thara sent this RFC
series for discussion, but from upstream point of view, I'd prefer to
see a full stack solution, before taking any code.
thanks,
Rui