diff options
author | Stephan Gerhold <stephan.gerhold@kernkonzept.com> | 2023-11-14 11:07:43 +0100 |
---|---|---|
committer | Viresh Kumar <viresh.kumar@linaro.org> | 2023-11-23 13:08:00 +0530 |
commit | 5cbff51e709a72a60b0416b00521b835a1f9a3d5 (patch) | |
tree | 7460e24077c49058378a7bd2e703bb5fd3811b47 /samples | |
parent | 2e4e0984c7d696cc74cf2fd7e7f62997f0e9ebe6 (diff) | |
download | linux-stable-5cbff51e709a72a60b0416b00521b835a1f9a3d5.tar.gz linux-stable-5cbff51e709a72a60b0416b00521b835a1f9a3d5.tar.bz2 linux-stable-5cbff51e709a72a60b0416b00521b835a1f9a3d5.zip |
cpufreq: qcom-nvmem: Enable virtual power domain devices
The genpd core caches performance state votes from devices that are
runtime suspended as of commit 3c5a272202c2 ("PM: domains: Improve
runtime PM performance state handling"). They get applied once the
device becomes active again.
To attach the power domains needed by qcom-cpufreq-nvmem the OPP core
calls genpd_dev_pm_attach_by_id(). This results in "virtual" dummy
devices that use runtime PM only to control the enable and performance
state for the attached power domain.
However, at the moment nothing ever resumes the virtual devices created
for qcom-cpufreq-nvmem. They remain permanently runtime suspended. This
means that performance state votes made during cpufreq scaling get
always cached and never applied to the hardware.
Fix this by enabling the devices after attaching them.
Without this fix performance states votes are silently ignored, and the
CPU/CPR voltage is never adjusted. This has been broken since 5.14 but
for some reason no one noticed this on QCS404 so far.
Fixes: 1cb8339ca225 ("cpufreq: qcom: Add support for qcs404 on nvmem driver")
Signed-off-by: Stephan Gerhold <stephan.gerhold@kernkonzept.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Diffstat (limited to 'samples')
0 files changed, 0 insertions, 0 deletions