linux-stable.git/drivers/cpufreq, branch v6.7

cpufreq/amd-pstate: Only print supported EPP values for performance governor

2023-11-29T21:04:15+00:00

show_energy_performance_available_preferences() to show only supported
values which is performance in performance governor policy.

-------Before--------
$ cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_driver
amd-pstate-epp
$ cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
performance
$ cat /sys/devices/system/cpu/cpu1/cpufreq/energy_performance_preference
performance
$ cat /sys/devices/system/cpu/cpu1/cpufreq/energy_performance_available_preferences
default performance balance_performance balance_power power

-------After--------
$ cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_driver
amd-pstate-epp
$ cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
performance
$ cat /sys/devices/system/cpu/cpu1/cpufreq/energy_performance_preference
performance
$ cat /sys/devices/system/cpu/cpu1/cpufreq/energy_performance_available_preferences
performance

Fixes: ffa5096a7c33 ("cpufreq: amd-pstate: implement Pstate EPP support for the AMD processors")
Suggested-by: Wyes Karny 
Signed-off-by: Ayush Jain 
Reviewed-by: Wyes Karny 
Acked-by: Huang Rui 
Signed-off-by: Rafael J. Wysocki

cpufreq/amd-pstate: Fix scaling_min_freq and scaling_max_freq update

2023-11-29T16:40:16+00:00

When amd_pstate is running, writing to scaling_min_freq and
scaling_max_freq has no effect. These values are only passed to the
policy level, but not to the platform level. This means that the
platform does not know about the frequency limits set by the user.

To fix this, update the min_perf and max_perf values at the platform
level whenever the user changes the scaling_min_freq and scaling_max_freq
values.

Fixes: ffa5096a7c33 ("cpufreq: amd-pstate: implement Pstate EPP support for the AMD processors")
Acked-by: Huang Rui 
Signed-off-by: Wyes Karny 
Signed-off-by: Rafael J. Wysocki

cpufreq/amd-pstate: Fix the return value of amd_pstate_fast_switch()

2023-11-28T14:06:25+00:00

cpufreq_driver->fast_switch() callback expects a frequency as a return
value. amd_pstate_fast_switch() was returning the return value of
amd_pstate_update_freq(), which only indicates a success or failure.

Fix this by making amd_pstate_fast_switch() return the target_freq
when the call to amd_pstate_update_freq() is successful, and return
the current frequency from policy->cur when the call to
amd_pstate_update_freq() is unsuccessful.

Fixes: 4badf2eb1e98 ("cpufreq: amd-pstate: Add ->fast_switch() callback")
Acked-by: Huang Rui 
Reviewed-by: Wyes Karny 
Reviewed-by: Perry Yuan 
Cc: 6.4+  # v6.4+
Signed-off-by: Gautham R. Shenoy 
Signed-off-by: Rafael J. Wysocki

cpufreq: qcom-nvmem: Preserve PM domain votes in system suspend

2023-11-23T07:38:01+00:00

>From the Linux point of view, the power domains used by the CPU must
stay always-on. This is because we still need the CPU to keep running
until the last instruction, which will typically be a firmware call that
shuts down the CPU cleanly.

At the moment the power domain votes (enable + performance state) are
dropped during system suspend, which means the CPU could potentially
malfunction while entering suspend.

We need to distinguish between two different setups used with
qcom-cpufreq-nvmem:

 1. CPR power domain: The backing regulator used by CPR should stay
    always-on in Linux; it is typically disabled automatically by
    hardware when the CPU enters a deep idle state. However, we
    should pause the CPR state machine during system suspend.

 2. RPMPD: The power domains used by the CPU should stay always-on
    in Linux (also across system suspend). The CPU typically only
    uses the *_AO ("active-only") variants of the power domains in
    RPMPD. For those, the RPM firmware will automatically drop
    the votes internally when the CPU enters a deep idle state.

Make this work correctly by calling device_set_awake_path() on the
virtual genpd devices, so that the votes are maintained across system
suspend. The power domain drivers need to set GENPD_FLAG_ACTIVE_WAKEUP
to opt into staying on during system suspend.

For now we only set this for the RPMPD case. For CPR, not setting it
will ensure the state machine is still paused during system suspend,
while the backing regulator will stay on with "regulator-always-on".

Signed-off-by: Stephan Gerhold 
Reviewed-by: Ulf Hansson 
Signed-off-by: Viresh Kumar

cpufreq: qcom-nvmem: Enable virtual power domain devices

2023-11-23T07:38:00+00:00

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 
Reviewed-by: Ulf Hansson 
Signed-off-by: Viresh Kumar

cpufreq: imx6q: Don't disable 792 Mhz OPP unnecessarily

2023-11-23T07:20:40+00:00

For a 900MHz i.MX6ULL CPU the 792MHz OPP is disabled. There is no
convincing reason to disable this OPP. If a CPU can run at 900MHz,
it should also be able to cope with 792MHz. Looking at the voltage
level of 792MHz in [1] (page 24, table 10. "Operating Ranges") the
current defined OPP is above the minimum. So the voltage level
shouldn't be a problem. However in [2] (page 24, table 10.
"Operating Ranges"), it is not mentioned that 792MHz OPP isn't
allowed. Change it to only disable 792MHz OPP for i.MX6ULL types
below 792 MHz.

[1] https://www.nxp.com/docs/en/data-sheet/IMX6ULLIEC.pdf
[2] https://www.nxp.com/docs/en/data-sheet/IMX6ULLCEC.pdf

Fixes: 0aa9abd4c212 ("cpufreq: imx6q: check speed grades for i.MX6ULL")
Signed-off-by: Christoph Niedermaier 
Reviewed-by: Marek Vasut 
Reviewed-by: Fabio Estevam 
[ Viresh: Edited subject ]
Signed-off-by: Viresh Kumar

Merge branch 'pm-cpufreq'

2023-11-07T19:45:12+00:00

Merge branch 'pm-cpufreq'

Merge additional Qualcomm cpufreq driver updates for 6.7-rc1:

 - Add support for several Qualcomm SoC versions (Robert Marko,
   Varadarajan Narayanan).

* pm-cpufreq:
  cpufreq: qcom-nvmem: Introduce cpufreq for ipq95xx
  cpufreq: qcom-nvmem: Enable cpufreq for ipq53xx
  cpufreq: qcom-nvmem: add support for IPQ8074

Merge tag 'cpufreq-arm-updates-6.7-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm

2023-11-03T14:31:57+00:00

Merge ARM cpufreq updates for 6.7 (part 2) from Viresh kumar:

"- Add support for several Qualcomm SoC versions (Robert Marko and
   Varadarajan Narayanan)."

* tag 'cpufreq-arm-updates-6.7-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm:
  cpufreq: qcom-nvmem: Introduce cpufreq for ipq95xx
  cpufreq: qcom-nvmem: Enable cpufreq for ipq53xx
  cpufreq: qcom-nvmem: add support for IPQ8074
  soc: qcom: socinfo: Add IDs for IPQ8174 family
  dt-bindings: arm: qcom,ids: Add IDs for IPQ8174 family
  dt-bindings: qcom: geni-se: Allow dma-coherent
  soc: qcom: socinfo: Add SoC ID for QCM6490
  dt-bindings: arm: qcom,ids: Add SoC ID for QCM6490
  soc: qcom: socinfo: Add SM8550-adjacent PMICs
  soc: qcom: wcnss_ctrl: Remove redundant initialization owner in wcnss_ctrl_driver
  soc: qcom: socinfo: Add Soc ID for SM7150P
  dt-bindings: arm: qcom,ids: Add Soc ID for SM7150P
  firmware: Add support for Qualcomm UEFI Secure Application
  firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface
  lib/ucs2_string: Add UCS-2 strscpy function

cpufreq: qcom-nvmem: Introduce cpufreq for ipq95xx

2023-11-02T05:34:53+00:00

IPQ95xx SoCs have different OPPs available for the CPU based on
the SoC variant. This can be determined from an eFuse register
present in the silicon.

Added support for ipq95xx on nvmem driver which helps to
determine OPPs at runtime based on the eFuse register which
has the CPU frequency limits. opp-supported-hw dt binding
can be used to indicate the available OPPs for each limit.

Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Praveenkumar I 
Signed-off-by: Kathiravan T 
Signed-off-by: Varadarajan Narayanan 
[ Viresh: Fixed subject ]
Signed-off-by: Viresh Kumar

cpufreq: qcom-nvmem: Enable cpufreq for ipq53xx

2023-11-02T05:34:53+00:00

IPQ53xx have different OPPs available for the CPU based on
SoC variant. This can be determined through use of an eFuse
register present in the silicon.

Added support for ipq53xx on nvmem driver which helps to
determine OPPs at runtime based on the eFuse register which
has the CPU frequency limits. opp-supported-hw dt binding
can be used to indicate the available OPPs for each limit.

nvmem driver also creates the "cpufreq-dt" platform_device after
passing the version matching data to the OPP framework so that the
cpufreq-dt handles the actual cpufreq implementation.

Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Bryan O'Donoghue 
Signed-off-by: Kathiravan T 
Signed-off-by: Varadarajan Narayanan 
[ Viresh: Fixed subject ]
Signed-off-by: Viresh Kumar