Linux kernel stable tree https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/atom?h=linux-5.19.y 2022-10-24T07:58:09+00:00 2022-10-24T07:58:09+00:00 Doug Smythies dsmythies@telus.net 2022-09-06T20:28:57+00:00 urn:sha1:25b364cb9b72a66d4dc9a382d7d6f9e0d0059f3e [ Upstream commit 71bb5c82aaaea007167f3ba68d3a669c74d7d55d ] Users may disable HWP in firmware, in which case intel_pstate wouldn't load unless the CPU model is explicitly supported. Add TIGERLAKE to the list of CPUs that can register intel_pstate while not advertising the HWP capability. Without this change, an TIGERLAKE in no-HWP mode could only use the acpi_cpufreq frequency scaling driver. See also commits: d8de7a44e11f: cpufreq: intel_pstate: Add Skylake servers support fbdc21e9b038: cpufreq: intel_pstate: Add Icelake servers support in no-HWP mode 706c5328851d: cpufreq: intel_pstate: Add Cometlake support in no-HWP mode Reported by: M. Cargi Ari <cagriari@pm.me> Signed-off-by: Doug Smythies <dsmythies@telus.net> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 2022-10-24T07:58:08+00:00 Perry Yuan Perry.Yuan@amd.com 2022-08-14T16:35:45+00:00 urn:sha1:8ce338db7440a1b7f2d48d1a78df2548ebd4a935 [ Upstream commit b185c5053c65b7704ead4537e4d4d9b33dc398dc ] Fix the wrong lowest perf value reading which is used for new des_perf calculation by governor requested, the incorrect min_perf will get incorrect des_perf to be set , that will cause the system frequency changing unexpectedly. Reviewed-by: Huang Rui <ray.huang@amd.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Perry Yuan <Perry.Yuan@amd.com> Signed-off-by: Su Jinzhou <jinzhou.su@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 2022-10-24T07:57:02+00:00 Perry Yuan Perry.Yuan@amd.com 2022-08-30T01:56:00+00:00 urn:sha1:7c0258acaf71284a281a9470aad6d16defef7ec2 [ Upstream commit bedadcfb011fef55273bd686e8893fdd8911dcdb ] To avoid some new AMD processors use wrong highest perf when amd pstate driver loaded, this fix will query the highest perf from MSR register MSR_AMD_CPPC_CAP1 and cppc_acpi interface firstly, then compare with the highest perf value got by calling amd_get_highest_perf() function. The lower value will be the correct highest perf we need to use. Otherwise the CPU max MHz will be incorrect if the amd_get_highest_perf() did not cover the new process family and model ID. Like this lscpu info, the max frequency is incorrect. Vendor ID: AuthenticAMD Socket(s): 1 Stepping: 2 CPU max MHz: 5410.0000 CPU min MHz: 400.0000 BogoMIPS: 5600.54 Fixes: 3743d55b289c2 (x86, sched: Fix the AMD CPPC maximum performance value on certain AMD Ryzen generations) Acked-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Perry Yuan <Perry.Yuan@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 2022-10-24T07:56:50+00:00 Viresh Kumar viresh.kumar@linaro.org 2022-09-21T07:00:38+00:00 urn:sha1:c5f1c47aaa3fea115d355d5a3ec321d4063d128d commit 91dc90fdb8b8199519a3aac9c46a433b02223c5b upstream. Commit 6240aaad75e1 was supposed to drop the reference count to the OPP, instead it avoided more stuff if the OPP isn't found. This isn't entirely correct. We already have a frequency value available, we just couldn't align it with an OPP in case of IS_ERR(opp). Lets continue with updating thermal pressure, etc, even if we aren't able to find an OPP here. This fixes warning generated by the 'smatch' tool. Fixes: 6240aaad75e1 ("cpufreq: qcom-hw: fix the opp entries refcounting") Cc: v5.18+ <stable@vger.kernel.org> # v5.18+ Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2022-09-15T08:47:09+00:00 Lukasz Luba lukasz.luba@arm.com 2022-08-16T12:01:57+00:00 urn:sha1:73085208dd6b1a83bc38aa74d79efaa5741c3436 [ Upstream commit 6ca7076fbfaeccce173aeab832d76b9e49e1034b ] There is no need to check if the cpufreq driver implements callback cpufreq_driver::target_index. The logic in the __resolve_freq uses the frequency table available in the policy. It doesn't matter if the driver provides 'target_index' or 'target' callback. It just has to populate the 'policy->freq_table'. Thus, check only frequency table during the frequency resolving call. Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 2022-08-17T13:15:52+00:00 Yang Yingliang yangyingliang@huawei.com 2022-05-17T13:34:50+00:00 urn:sha1:6d90c0829fe73c478e63fe90b4cec716271fb6e1 [ Upstream commit 72d67d6b3447303a441a8cedc34f7224b75f64b5 ] If regulator_get_voltage() fails, it should return the error code in mtk_cpu_dvfs_info_init(). Fixes: 0daa47325bae ("cpufreq: mediatek: Link CCI device to CPU") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 2022-08-17T13:14:05+00:00 Lukasz Luba lukasz.luba@arm.com 2022-07-07T07:15:52+00:00 urn:sha1:bfd4c6710d22c939bebc2f34e897e919a9f01ad5 [ Upstream commit ae6ccaa650380d243cf43d31c864c5ced2fd4612 ] The milli-Watts precision causes rounding errors while calculating efficiency cost for each OPP. This is especially visible in the 'simple' Energy Model (EM), where the power for each OPP is provided from OPP framework. This can cause some OPPs to be marked inefficient, while using micro-Watts precision that might not happen. Update all EM users which access 'power' field and assume the value is in milli-Watts. Solve also an issue with potential overflow in calculation of energy estimation on 32bit machine. It's needed now since the power value (thus the 'cost' as well) are higher. Example calculation which shows the rounding error and impact: power = 'dyn-power-coeff' * volt_mV * volt_mV * freq_MHz power_a_uW = (100 * 600mW * 600mW * 500MHz) / 10^6 = 18000 power_a_mW = (100 * 600mW * 600mW * 500MHz) / 10^9 = 18 power_b_uW = (100 * 605mW * 605mW * 600MHz) / 10^6 = 21961 power_b_mW = (100 * 605mW * 605mW * 600MHz) / 10^9 = 21 max_freq = 2000MHz cost_a_mW = 18 * 2000MHz/500MHz = 72 cost_a_uW = 18000 * 2000MHz/500MHz = 72000 cost_b_mW = 21 * 2000MHz/600MHz = 70 // <- artificially better cost_b_uW = 21961 * 2000MHz/600MHz = 73203 The 'cost_b_mW' (which is based on old milli-Watts) is misleadingly better that the 'cost_b_uW' (this patch uses micro-Watts) and such would have impact on the 'inefficient OPPs' information in the Cpufreq framework. This patch set removes the rounding issue. Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 2022-07-15T11:54:14+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2022-07-15T11:54:14+00:00 urn:sha1:5a5adb1528e59e8a4b23ffa7dda4849b61e97cf8 Pull a cpufreq ARM fix for 5.19-rc7 from Viresh Kumar: - mediatek: Handle sram regulator probe deferral * tag 'cpufreq-arm-fixes-5.19-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: cpufreq: mediatek: Handle sram regulator probe deferral 2022-07-13T11:21:32+00:00 AngeloGioacchino Del Regno angelogioacchino.delregno@collabora.com 2022-07-13T11:15:36+00:00 urn:sha1:d2394860b45c3c1484e4b0a5d09909a1e3f6569e If the regulator_get_optional() call for the SRAM regulator returns a probe deferral, we must bail out and retry probing later: failing to do this will produce unstabilities on platforms requiring the handling for this regulator. Fixes: ffa7bdf7f344 ("cpufreq: mediatek: Make sram regulator optional") Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> 2022-06-28T15:56:57+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2022-06-28T15:56:57+00:00 urn:sha1:049b1ed9bef1e544ddca37e60debc809c3bd9f34 Pull cpufreq ARM fixes for 5.19-rc5 from Viresh Kumar: - Fix missing of_node_put for qoriq and pmac32 driver (Liang He). - Fix issues around throttle interrupt for qcom driver (Stephen Boyd). - Add MT8186 to cpufreq-dt-platdev blocklist (AngeloGioacchino Del Regno). * tag 'cpufreq-arm-fixes-5.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: cpufreq: Add MT8186 to cpufreq-dt-platdev blocklist cpufreq: pmac32-cpufreq: Fix refcount leak bug cpufreq: qcom-hw: Don't do lmh things without a throttle interrupt drivers: cpufreq: Add missing of_node_put() in qoriq-cpufreq.c