lkml.org 
[lkml]   [2020]   [Apr]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] thermal: core: Send a sysfs notification on trip points
From
Date
On 06/04/2020 11:25, Amit Kucheria wrote:
> On Thu, Apr 2, 2020 at 7:53 PM Daniel Lezcano
> <daniel.lezcano@linaro.org> wrote:
>>
>> Currently the userspace has no easy way to get notified when a
>> specific trip point was crossed. There are a couple of
>> approaches:
>>
>> - the userspace polls the sysfs temperature with usually an
>> unacceptable delay between the trip temperature point crossing
>> and the moment it is detected, or a high polling rate with an
>> unacceptable number of wakeup events.
>>
>> - the thermal zone is set to be managed by an userspace governor
>> in order to receive the uevent even if the thermal zone needs to
>> be managed by another governor.
>>
>> These changes allow to send a sysfs notification on the
>> trip_point_*_temp when the temperature is getting higher than the
>> trip point temperature. By this way, the userspace can be
>> notified everytime when the trip point is crossed, this is useful
>> for the thermal Android HAL or for notification to be sent via
>> d-bus.
>>
>> That allows the userspace to manage the applications based on
>> specific alerts on different thermal zones to mitigate the skin
>> temperature, letting the kernel governors handle the high
>> temperature for hardware like the CPU, the GPU or the modem.
>>
>> The temperature can be oscillating around a trip point and the
>> event will be sent multiple times. It is up to the userspace to
>> deal with this situation.
>
> Thinking about this a bit more, userspace might want a
> notification when the temperature reduces and crosses the threshold
> on its way down too.
>
> Currently, we're only sending the notification on the way up. How
> should userspace know when to stop mitigation activity other than
> constantly polling the TZ temperature?

Assuming you want to monitor the temperature after a specific trip
point is reached:

- the notification is sent way up

- user space starts reading the temperature

- the temperature goes below the trip point temperature

- user space stops reading the temperature

Actually, I don't see the point of being notified and not read the
temperature after.

That is how is working the kernel side, especially with the interrupt
mode. The sensor fires an interrupt -> thermal zone update ->
temperature read -> trip point reached -> passive mode on ->
temperature polling -> temperature below trip point -> passive mode off.



>> The following userspace program allows to monitor those events:
>>
>> struct trip_data { int fd; int temperature; const char *path; };
>>
>
> [snip]
>


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

\
 
 \ /
  Last update: 2020-04-06 11:54    [W:0.076 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site