On 02/07/2024 12:22, Rafael J. Wysocki wrote:
On Tue, Jul 2, 2024 at 11:29 AM Daniel Lezcano
<daniel.lezcano@xxxxxxxxxx> wrote:
On 01/07/2024 18:26, Rob Herring wrote:
On Thu, Jun 27, 2024 at 10:54:50AM +0200, Daniel Lezcano wrote:
Currently the thermal framework has 4 trip point types:
- active : basically for fans (or anything requiring energy to cool
down)
- passive : a performance limiter
- hot : for a last action before reaching critical
- critical : a without return threshold leading to a system shutdown
A thermal zone monitors the temperature regarding these trip
points. The old way to do that is actively polling the temperature
which is very bad for embedded systems, especially mobile and it is
even worse today as we can have more than fifty thermal zones. The
modern way is to rely on the driver to send an interrupt when the trip
points are crossed, so the system can sleep while the temperature
monitoring is offloaded to a dedicated hardware.
However, the thermal aspect is also managed from userspace to protect
the user, especially tracking down the skin temperature sensor. The
logic is more complex than what we found in the kernel because it
needs multiple sources indicating the thermal situation of the entire
system.
For this reason it needs to setup trip points at different levels in
order to get informed about what is going on with some thermal zones
when running some specific application.
For instance, the skin temperature must be limited to 43°C on a long
run but can go to 48°C for 10 minutes, or 60°C for 1 minute.
The thermal engine must then rely on trip points to monitor those
temperatures. Unfortunately, today there is only 'active' and
'passive' trip points which has a specific meaning for the kernel, not
the userspace. That leads to hacks in different platforms for mobile
and embedded systems where 'active' trip points are used to send
notification to the userspace. This is obviously not right because
these trip are handled by the kernel.
This patch introduces the 'user' trip point type where its semantic is
simple: do nothing at the kernel level, just send a notification to
the user space.
Sounds like OS behavior/policy though I guess the existing ones kind are
too. Maybe we should have defined *what* action to take and then the OS
could decide whether what actions to handle vs. pass it up a level.
Right
Why can't userspace just ask to be notified at a trip point it
defines?
Yes I think it is possible to create a netlink message to create a trip
point which will return a trip id.
Rafael what do you think ?
Trips cannot be created on the fly ATM.
What can be done is to create trips that are invalid to start with and
then set their temperature via sysfs. This has been done already for
quite a while AFAICS.
Yes, I remember that.
I would like to avoid introducing more weirdness in the thermal
framework which deserve a clear ABI.
What is missing to create new trip points on the fly ?
--
<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
