summaryrefslogtreecommitdiff
path: root/rb5.mk
diff options
context:
space:
mode:
authorDaniel Lezcano <daniel.lezcano@linaro.org>2023-09-07 13:48:54 +0200
committerDaniel Lezcano <daniel.lezcano@linaro.org>2023-10-25 14:07:27 +0200
commit4afb511292799e5e54ade7713566a4bbdc15f59b (patch)
tree36033dd7e90dff002983d5ff6e4744949079a221 /rb5.mk
parent1422810dc0973a3d33775812cc3156bcc4d896d6 (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 'rb5.mk')
0 files changed, 0 insertions, 0 deletions