On 02/07/2024 19:15, Rafael J. Wysocki wrote:
On Tue, Jul 2, 2024 at 6:31 PM Daniel Lezcano <daniel.lezcano@xxxxxxxxxx> wrote:
On 02/07/2024 13:03, Rafael J. Wysocki wrote:
[ ... ]
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 ?
A different data structure to store them (essentially, a list instead
of an array).
I doubt it's worth the hassle.
What's wrong with the current approach mentioned above? It will need
to be supported going forward anyway.
So when the "user trip point" option will be set, a thermal zone will
have ~ten(?) user trip points initialized to an invalid temperature ?
If a thermal zone is registered with 10 invalid trip points, htat can
happen already today.
IINW, this is the case for a particular driver (int340x_thermal_zone?),
may be for a thermal zone. But in the general case where we can have
more the 50 thermal zones it is not adequate as we will end up with more
than 500 trip points overall.
Assuming it is the int340x_thermal_zone driver, it is active trip
points, so that assumes the associated cooling device will be active.
TBH, it is fuzzy regarding a notification mechanism
Let's talk about the usage model, though.
Sure
IIUC, this would be something like "triggers" I mentioned before: If a
certain temperature level is reached, a notification is sent to user
space, and there are multiple (possibly many) levels like this. They
can be added and deleted at any time.
Yes, except I don't think the usage will be to often creating trip
points. More likely, depending on the kind of sensors and the associated
logic, a number of trip points will created for a specific profile and
then modified on the fly.
There can be an interface for this, as simple as a pair of sysfs
attributes under a thermal zone: add_trigger and remove_trigger. If
root (or equivalent) writes a (valid) temperature value to
add_trigger, a new trigger is added (up to a limit and provided that
enough memory can be allocated). Conversely, if a temperature value
is written to remove_trigger and there is a trigger with that
temperature, it will be deleted.
A hysteresis would be needed too. IMO, netlinks are more adequate for
this purpose.
Internally, the triggers can be stored in a sorted list (with some
optimizations, so it need not be walked every time the zone
temperature changes) or a tree, independent of the trips table (if
any). Every time the zone temperature changes, the triggers list is
consulted (in addition to the trips table) and if any of them have
been crossed, notifications are sent to user space.
So basically, thermal_zone_device_update() will browse two lists,
triggers + trip points, right ?
If polling is used, this would just work, but without polling the
driver needs to support setting a pair (at least) of temperature
levels causing an interrupt to occur.
I'm missing this point, can you elaborate ?
If a specific callback, say
.set_triggers(), is provided by the driver, it can be used for setting
those temperature levels to the triggers right above and right below
the current zone temperature, in analogy with .set_trips().
Does this reflect what you are after?
At the first glance I would say yes, but I don't get why it is more
complicate to just add 'triggers' with the trip points (formerly 'user'
trip points)
--
<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
