diff options
author | Daniel Lezcano <daniel.lezcano@linaro.org> | 2023-09-07 13:48:54 +0200 |
---|---|---|
committer | Daniel Lezcano <daniel.lezcano@linaro.org> | 2023-10-25 14:07:27 +0200 |
commit | 4afb511292799e5e54ade7713566a4bbdc15f59b (patch) | |
tree | 36033dd7e90dff002983d5ff6e4744949079a221 /shared/utils/tqftpserv/tqftpserv.service.in | |
parent | 1422810dc0973a3d33775812cc3156bcc4d896d6 (diff) |
dragonboard: power: Add the PowerHAL skeletonthermal-hal-upstream
The following changes provide a power HAL skeleton. The goal of this
skeleton is to evolve in order to provide as much functionalities as
possible in a generic manner.
Despite it is a skeleton, the implementation provides a set of
advanced features we can easily enable.
1. Boost actions basically do nothing. But the timer mechanism is
implemented so any action can automatically disable itself after a
specified duration. As per today the boost actions are not specified
by the platform, thus it is a zero boost duration. The meaning of a
zero boost is no timeout for the boost. Consequently, if the system
does not disable the boost, the system will stay in a higher power
consumption state. For this reason, if no duration is provided, the
power HAL will set a default duration anyway.
2. Mode actions do nothing except setting a zero latency when
receiving the LAUNCH mode notification. That is done basically for
having a default behavior for this mode but it is subject to change.
3. Hint sessions are created but no actions is done when created. This
code is candidate for platform specific optimizations. The run
duration are monitored with an exponential moving average algorithm
computing on the fly the intervals between the tasks. Platform
specific code can take decisions based on this information.
4. A power/performance library is integrated in the power HAL and
hopefully it can continue to evolve in the future as an external
project with more features. Nevertheless, the library provides the API
to set/get the frequency as well as setting the min and max
frequency. The CPU is considered as a device so the API is unified
between CPUs and devices. In addition it allows to act on the device
latencies.
As far as I can tell, with the thermal HAL and the power HAL
implemented for the dragonboard, there is almost enough material to
enable the ADPF. However, given the dragonboard is an EVB platform, it
does not have a skin temperature sensor or a slow moving sensor
identified yet. Thus the thermal headroom can not be computed as it
relies on the skin temperature sensor type.
Change-Id: I8a860992a4a673794a5003486da3deed0f28dd06
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Diffstat (limited to 'shared/utils/tqftpserv/tqftpserv.service.in')
0 files changed, 0 insertions, 0 deletions