kernel/git/stable/linux.git/drivers/cpufreq, branch linux-5.16.y

cpufreq: CPPC: Fix performance/frequency conversion

2022-04-13T18:03:09+00:00

[ Upstream commit ec1c7ad47664f964c1101fe555b6fde0cb124b38 ] CPUfreq governors request CPU frequencies using information on current CPU usage. The CPPC driver converts them to performance requests. Frequency targets are computed as: target_freq = (util / cpu_capacity) * max_freq target_freq is then clamped between [policy->min, policy->max]. The CPPC driver converts performance values to frequencies (and vice-versa) using cppc_cpufreq_perf_to_khz() and cppc_cpufreq_khz_to_perf(). These functions both use two different factors depending on the range of the input value. For cppc_cpufreq_khz_to_perf(): - (NOMINAL_PERF / NOMINAL_FREQ) or - (LOWEST_PERF / LOWEST_FREQ) and for cppc_cpufreq_perf_to_khz(): - (NOMINAL_FREQ / NOMINAL_PERF) or - ((NOMINAL_PERF - LOWEST_FREQ) / (NOMINAL_PERF - LOWEST_PERF)) This means: 1- the functions are not inverse for some values: (perf_to_khz(khz_to_perf(x)) != x) 2- cppc_cpufreq_perf_to_khz(LOWEST_PERF) can sometimes give a different value from LOWEST_FREQ due to integer approximation 3- it is implied that performance and frequency are proportional (NOMINAL_FREQ / NOMINAL_PERF) == (LOWEST_PERF / LOWEST_FREQ) This patch changes the conversion functions to an affine function. This fixes the 3 points above. Suggested-by: Lukasz Luba Suggested-by: Morten Rasmussen Signed-off-by: Pierre Gondois Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin

cpufreq: qcom-cpufreq-nvmem: fix reading of PVS Valid fuse

2022-04-08T12:06:21+00:00

[ Upstream commit 4a8a77abf0e2b6468ba0281e33384cbec5fb476a ] The fuse consists of 64 bits, with this statement we're supposed to get the upper 32 bits but it actually read out of bounds and got 0 instead of the desired value which lead to the "PVS bin not set." codepath being run resetting our pvs value. Fixes: a8811ec764f9 ("cpufreq: qcom: Add support for krait based socs") Signed-off-by: Luca Weiss Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin

cpufreq: intel_pstate: Update cpuinfo.max_freq on HWP_CAP changes

2022-01-27T11:02:28+00:00

[ Upstream commit dfeeedc1bf5772226bddf51ed3f853e5a6707bf1 ] With HWP enabled, when the turbo range of performance levels is disabled by the platform firmware, the CPU capacity is given by the "guaranteed performance" field in MSR_HWP_CAPABILITIES which is generally dynamic. When it changes, the kernel receives an HWP notification interrupt handled by notify_hwp_interrupt(). When the "guaranteed performance" value changes in the above configuration, the CPU performance scaling needs to be adjusted so as to use the new CPU capacity in computations, which means that the cpuinfo.max_freq value needs to be updated for that CPU. Accordingly, modify intel_pstate_notify_work() to read MSR_HWP_CAPABILITIES and update cpuinfo.max_freq to reflect the new configuration (this update can be carried out even if the configuration doesn't actually change, because it simply doesn't matter then and it takes less time to update it than to do extra checks to decide whether or not a change has really occurred). Reported-by: Srinivas Pandruvada Tested-by: Srinivas Pandruvada Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

cpufreq: Fix initialization of min and max frequency QoS requests

2022-01-27T11:02:25+00:00

[ Upstream commit 521223d8b3ec078f670c7c35a1a04b1b2af07966 ] The min and max frequency QoS requests in the cpufreq core are initialized to whatever the current min and max frequency values are at the init time, but if any of these values change later (for example, cpuinfo.max_freq is updated by the driver), these initial request values will be limiting the CPU frequency unnecessarily unless they are changed by user space via sysfs. To address this, initialize min_freq_req and max_freq_req to FREQ_QOS_MIN_DEFAULT_VALUE and FREQ_QOS_MAX_DEFAULT_VALUE, respectively, so they don't really limit anything until user space updates them. Reported-by: Srinivas Pandruvada Tested-by: Srinivas Pandruvada Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

cpufreq: qcom-hw: Fix probable nested interrupt handling

2022-01-27T11:01:33+00:00

[ Upstream commit e0e27c3d4e20dab861566f1c348ae44e4b498630 ] Re-enabling an interrupt from its own interrupt handler may cause an interrupt storm, if there is a pending interrupt and because its handling is disabled due to already done entrance into the handler above in the stack. Also, apparently it is improper to lock a mutex in an interrupt contex. Fixes: 275157b367f4 ("cpufreq: qcom-cpufreq-hw: Add dcvs interrupt support") Signed-off-by: Vladimir Zapolskiy Reviewed-by: Matthias Kaehlcke Reviewed-by: Bjorn Andersson Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin

cpufreq: qcom-cpufreq-hw: Update offline CPUs per-cpu thermal pressure

2022-01-27T11:01:33+00:00

[ Upstream commit 93d9e6f93e1586fcc97498c764be2e8c8401f4bd ] The thermal pressure signal gives information to the scheduler about reduced CPU capacity due to thermal. It is based on a value stored in a per-cpu 'thermal_pressure' variable. The online CPUs will get the new value there, while the offline won't. Unfortunately, when the CPU is back online, the value read from per-cpu variable might be wrong (stale data). This might affect the scheduler decisions, since it sees the CPU capacity differently than what is actually available. Fix it by making sure that all online+offline CPUs would get the proper value in their per-cpu variable when there is throttling or throttling is removed. Fixes: 275157b367f479 ("cpufreq: qcom-cpufreq-hw: Add dcvs interrupt support") Reviewed-by: Thara Gopinath Signed-off-by: Lukasz Luba Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin

cpufreq: Fix a comment in cpufreq_policy_free

2021-12-01T19:02:11+00:00

Make the comment in blocking_notifier_call_chain() easier to understand. Signed-off-by: Tang Yizhou Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: Fix get_cpu_device() failure in add_cpu_dev_symlink()

2021-12-01T18:50:56+00:00

When I hot added a CPU, I found 'cpufreq' directory was not created below /sys/devices/system/cpu/cpuX/. It is because get_cpu_device() failed in add_cpu_dev_symlink(). cpufreq_add_dev() is the .add_dev callback of a CPU subsys interface. It will be called when the CPU device registered into the system. The call chain is as follows: register_cpu() ->device_register() ->device_add() ->bus_probe_device() ->cpufreq_add_dev() But only after the CPU device has been registered, we can get the CPU device by get_cpu_device(), otherwise it will return NULL. Since we already have the CPU device in cpufreq_add_dev(), pass it to add_cpu_dev_symlink(). I noticed that the 'kobj' of the CPU device has been added into the system before cpufreq_add_dev(). Fixes: 2f0ba790df51 ("cpufreq: Fix creation of symbolic links to policy directories") Signed-off-by: Xiongfeng Wang Acked-by: Viresh Kumar Cc: All applicable Signed-off-by: Rafael J. Wysocki

cpufreq: intel_pstate: ITMT support for overclocked system

2021-11-23T13:11:18+00:00

On systems with overclocking enabled, CPPC Highest Performance can be hard coded to 0xff. In this case even if we have cores with different highest performance, ITMT can't be enabled as the current implementation depends on CPPC Highest Performance. On such systems we can use MSR_HWP_CAPABILITIES maximum performance field when CPPC.Highest Performance is 0xff. Due to legacy reasons, we can't solely depend on MSR_HWP_CAPABILITIES as in some older systems CPPC Highest Performance is the only way to identify different performing cores. Reported-by: Michael Larabel Signed-off-by: Srinivas Pandruvada Tested-by: Michael Larabel Signed-off-by: Rafael J. Wysocki

cpufreq: intel_pstate: Fix active mode offline/online EPP handling

2021-11-23T13:02:11+00:00

After commit 4adcf2e5829f ("cpufreq: intel_pstate: Add ->offline and ->online callbacks") the EPP value set by the "performance" scaling algorithm in the active mode is not restored after an offline/online cycle which replaces it with the saved EPP value coming from user space. Address this issue by forcing intel_pstate_hwp_set() to set a new EPP value when it runs first time after online. Fixes: 4adcf2e5829f ("cpufreq: intel_pstate: Add ->offline and ->online callbacks") Link: https://lore.kernel.org/linux-pm/adc7132c8655bd4d1c8b6129578e931a14fe1db2.camel@linux.intel.com/ Reported-by: Srinivas Pandruvada Cc: 5.9+ # 5.9+ Signed-off-by: Rafael J. Wysocki