Re: Thermal driver with safeguards

[Daniel Lezcano <daniel.lezcano@linaro.org>]

On 10/01/2025 17:56, Werner Sembach wrote:
> Hi Daniel,
> 
> Am 09.01.25 um 22:36 schrieb Daniel Lezcano:
>> On 02/12/2024 15:52, Werner Sembach wrote:
>>> Hi,
>>>
>>> given a pair of a temperature sensor and a fan, I want to implement a 
>>> driver. that allows userspace to directly control the fan if it wants 
>>> to. But have a minimum fan speed when certain high temperatures are 
>>> reached to avoid crashes or hardware damage.
>>
>> From the userspace, use directly the thermal-engine which is currently 
>> under development [1]. You can add your platform specific code in a 
>> plugin while the thermal engine will catch all the thermal events and 
>> pass them to it [2].
>>
>> The thermal engine has a configuration file which will setup the 
>> thermal framework to be woken up at different temperatures.
> That still requires to trust userspace/the user to not write dangerous 
> values directly to sysfs?

No, it is not a trip point but temperature thresholds. So if the 
firmware defines trip points, the userspace can not change them.

Userspace thresholds are new : https://lwn.net/Articles/986009/

>> The thermal engine will be proposed for a distro package, so the 
>> platform support will be automatically supported.
>>
>> Beside the trip points can be setup in the device to act on higher 
>> temperature.
> As far as i can tell these trip points only notify userspace but you 
> can't attach code executed in kernel to it.

[ ... ]

>> What is unclear is how the fan is managed. I suggest to have a look at 
>> pwm-fan.c in drivers/hwmon
> 
> I already looked at hwmon, but that basically just writes trough values 
> from and to userspace and has no kernel side management of temperatures 
> and fan speeds whatsoever.

IIUC, you request was about having the userspace to deal with a fan and 
the kernel to be a safe guard, so taking over the thermal management 
when the temperature is too high.

Obviously the monitored temperature must be for a device with a "slow" 
temperature motion, userspace temperature management is not suitable for 
fast temperature transitions.

The thermal engine can for example configure different temperatures, 
let's say: 43°C, 44°C, 46°C, 49°C and 54°C.

Then the DT describes additional trip points for mitigation, one trip 
point for mitigation could be enough (eg 80°C). One for "hot" to send to 
the thermal engine a notification about getting really high so it can do 
some userspace action like killing an application, and finally a 
"critical" trip point to shutdown the system.

The fan would be a cooling device with 0-100 values representing the 
speed in percentage. The trip point at 80°C would be associated with the 
fan with the <0, 100> cooling states.

The dynamic of the thermal management could be the following:

The temperature is changing and stays in the [35°C - 60°C] boundaries. 
The thermal engine receives the events at the different aforementioned 
temperatures and manage to act on the pwm fan via hwmon.

For any reason the temperature goes above 80°C, at this moment the 
kernel takes over the management and will increase/decrease the fan 
speed between the 0% - 100% limits until the temperature goes below the 
80°C.

If it continues to increase and reaches the "hot" trip point, then an 
events is sent to the userspace which should take an action to reduce 
the temperature (kill the application, reduce the battery charge, drop 
the frame rates, etc ...).

If it continues to increase and reaches the "critical" trip point, then 
the system shuts down.

If the temperature decreases and goes below 80°C, then it returns to the 
normal state and the thermal engine can continue its work.

Does it make sense ?


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