Messages in this thread | | | Subject | Re: [PATCH] thermal: core: Send a sysfs notification on trip points | From | Daniel Lezcano <> | Date | Mon, 6 Apr 2020 11:53:38 +0200 |
| |
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
| |