From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: daniel.lezcano@linaro.org, rafael@kernel.org
Cc: linux-pm@vger.kernel.org, lukasz.luba@arm.com, quic_manafm@quicinc.com
Subject: [PATCH v5 0/4] Add thermal user thresholds support
Date: Mon, 14 Oct 2024 11:43:03 +0200 [thread overview]
Message-ID: <20241014094309.1430126-1-daniel.lezcano@linaro.org> (raw)
The trip points are a firmware description of the temperature limits
of a specific thermal zone where we associate an action which is done
by the kernel. The time resolution is low.
The userspace has to deal with a more complex thermal management based
on heuristics from different information coming from different
places. The logic is much more complex but based on a bigger time
resolution, usually one second based.
The purpose of the userspace is to monitor the temperatures from
different places and take actions. However, it can not be constantly
reading the temperature to detect when a temperature threshold has
been reached. This is especially bad for mobile or embedded system as
that will lead to an unacceptable number of wakeup to check the
temperature with nothing to do.
On the other side, the sensors are now most of the time interrupt
driven. That means the thermal framework will use the temperature trip
points to program the sensor to trigger an interrupt when a
temperature limit is crossed.
Unfortunately, the userspace can not benefit this feature and current
solutions found here and there, iow out-of-tree, are to add fake trip
points in the firmware and enable the writable trip points.
This is bad for different reasons, the trip points are for in-kernel
actions, the semantic of their types is used by the thermal framework
and by adding trip points in the device tree is a way to overcome the
current limitation but tampering with how the thermal framework is
supposed to work. The writable trip points is a way to adjust a
temperature limit given a specific platform if the firmware is not
accurate enough and TBH it is more a debug feature from my POV.
The user thresholds mechanism is a way to have the userspace to tell
thermal framework to send a notification when a temperature limit is
crossed. There is no id, no hysteresis, just the temperature and the
direction of the limit crossing. That means we can be notified when a
temperature threshold is crossed the way up only, or the way down only
or both ways. That allows to create hysteresis values if it is needed.
Those thresholds are refered as user thresholds in order to do the
difference with the trip points which are similar.
An user threshold can be added, deleted or flushed. The latter means
all user thresholds belonging to a thermal zone will be deleted.
When one or several user thresholds are crossed, an event is sent to
the userspace.
All aforementioned actions and events lead to a notification to the
userspace.
Along with the kernel changes, the thermal library has been extended
to provide the different API to deal with the new user threshold
netlink events and commands.
In addition, the thermal-engine skeleton uses these new API by
flushing and adding user thresholds as well as getting the
notification about these actions.
Overall the series has been tested with the thermal-engine skeleton
and some selftests which are not part of this series.
Changelog:
V5:
- Added CAP_SYS_ADMIN needed capability when adding, deleting and
flushing a threshold (Rafael)
- Remove the pid information to prevent leaking pid inside
containers. Also the information is not really needed (Rafael)
- Renamed "THERMAL_GENL_ATTR_THRESHOLD_WAY" to
"THERMAL_GENL_ATTR_THRESHOLD_DIRECTION". Did not used '*_DIR' as
suggested initially because it can be ambiguous with 'directory'
(Rafael)
- Renamed 'last_temp' to 'prev_temp' (Rafael)
- Used CLASS constructor/destructor to get / put the thermal
zone's device refcount (Rafael)
- Moved locking inside thermal_thresholds_for_each() (Rafael)
- Reflected the changes above in the thermal library and the
thermal engine skeleton
V4:
- Fix missing stubs when THERMAL_NETLINK=n (kernel test robot)
V3:
- the first patch of the v2 series has been merged
- Modified the description to split the information between the
cover letter and the patch 1 description (Rafael)
- Made the thresholds code as part of the core (Rafael)
- Converted the thresholds into a list and directly declared in
the thermal zone device structure (Rafael)
- Changed the name of the field in the thermal zone device
structure to user_thresholds (Rafael)
- Added #include "thermal_thresholds.h" (Rafael)
- Combined the conditions in the function
__thermal_threshold_is_crossed (Rafael)
- Moved the function thermal_thresholds_flush() before
thermal_thresholds_exit() (Rafael)
- Change thermal_thresholds_handle() to return void (Rafael)
- Move the list field on top the of the structure threshold and
renamed it list_node (Rafael)
- Changed THERMAL_THRESHOLD_* notifications to
THERMAL_TZ_THRESHOLD_* (Rafael)
V2:
- Compute min and max in thermal_zone_device_update() but keep
the loop as it is (Rafael)
- Include slab.h to fix compilation warnings on some architectures
with kmalloc and kfree (kernel test robot)
Daniel Lezcano (4):
thermal/netlink: Add the commands and the events for the thresholds
tools/lib/thermal: Make more generic the command encoding function
tools/lib/thermal: Add the threshold netlink ABI
tools/thermal/thermal-engine: Take into account the thresholds API
drivers/thermal/thermal_netlink.c | 236 +++++++++++++++++-
drivers/thermal/thermal_netlink.h | 34 +++
drivers/thermal/thermal_thresholds.c | 36 +--
drivers/thermal/thermal_thresholds.h | 2 +-
include/uapi/linux/thermal.h | 27 +-
tools/lib/thermal/commands.c | 167 ++++++++++++-
tools/lib/thermal/events.c | 55 +++-
tools/lib/thermal/include/thermal.h | 40 +++
tools/lib/thermal/libthermal.map | 5 +
tools/lib/thermal/thermal.c | 17 ++
tools/thermal/lib/Makefile | 2 +-
tools/thermal/thermal-engine/thermal-engine.c | 105 +++++++-
12 files changed, 662 insertions(+), 64 deletions(-)
--
2.43.0
next reply other threads:[~2024-10-14 9:43 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-14 9:43 Daniel Lezcano [this message]
2024-10-14 9:43 ` [PATCH v5 1/4] thermal/netlink: Add the commands and the events for the thresholds Daniel Lezcano
2024-10-21 10:58 ` Rafael J. Wysocki
2024-10-21 19:42 ` Lukasz Luba
2024-10-21 19:47 ` Rafael J. Wysocki
2024-10-21 19:51 ` Lukasz Luba
2024-10-21 22:02 ` Lukasz Luba
2024-10-22 7:09 ` Daniel Lezcano
2024-10-22 9:40 ` Lukasz Luba
2024-10-22 10:01 ` Rafael J. Wysocki
2024-10-22 10:20 ` Lukasz Luba
2024-10-14 9:43 ` [PATCH v5 2/4] tools/lib/thermal: Make more generic the command encoding function Daniel Lezcano
2024-10-21 19:49 ` Lukasz Luba
2024-10-22 7:12 ` Daniel Lezcano
2024-10-22 9:43 ` Lukasz Luba
2024-10-14 9:43 ` [PATCH v5 3/4] tools/lib/thermal: Add the threshold netlink ABI Daniel Lezcano
2024-10-21 20:47 ` Lukasz Luba
2024-10-22 7:49 ` Daniel Lezcano
2024-10-22 9:50 ` Lukasz Luba
2024-10-22 13:21 ` Daniel Lezcano
2024-10-14 9:43 ` [PATCH v5 4/4] tools/thermal/thermal-engine: Take into account the thresholds API Daniel Lezcano
2024-10-21 20:10 ` Lukasz Luba
2024-10-22 7:52 ` Daniel Lezcano
2024-10-21 8:28 ` [PATCH v5 0/4] Add thermal user thresholds support Daniel Lezcano
2024-10-21 8:43 ` Lukasz Luba
2024-10-21 11:02 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241014094309.1430126-1-daniel.lezcano@linaro.org \
--to=daniel.lezcano@linaro.org \
--cc=linux-pm@vger.kernel.org \
--cc=lukasz.luba@arm.com \
--cc=quic_manafm@quicinc.com \
--cc=rafael@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox