summaryrefslogtreecommitdiffstats
path: root/drivers/cpufreq
Commit message (Collapse)AuthorAgeFilesLines
* cpufreq: Support per-policy performance boostJie Zhan2023-08-291-0/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | The boost control currently applies to the whole system. However, users may prefer to boost a subset of cores in order to provide prioritized performance to workloads running on the boosted cores. Enable per-policy boost by adding a 'boost' sysfs interface under each policy path. This can be found at: /sys/devices/system/cpu/cpufreq/policy<*>/boost Same to the global boost switch, writing 1/0 to the per-policy 'boost' enables/disables boost on a cpufreq policy respectively. The user view of global and per-policy boost controls should be: 1. Enabling global boost initially enables boost on all policies, and per-policy boost can then be enabled or disabled individually, given that the platform does support so. 2. Disabling global boost makes the per-policy boost interface illegal. Signed-off-by: Jie Zhan <zhanjie9@hisilicon.com> Reviewed-by: Wei Xu <xuwei5@hisilicon.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: pcc: Fix the potentinal scheduling delays in target_index()Liao Chang2023-08-291-1/+1
| | | | | | | | | | | | | | | | | | | | pcc_cpufreq_target(): cpufreq_freq_transition_begin(); spin_lock(&pcc_lock); [critical section] cpufreq_freq_transition_end(); spin_unlock(&pcc_lock); Above code has a performance issue, consider that Task0 executes 'cpufreq_freq_transition_end()' to wake Task1 and preempted imediatedly without releasing 'pcc_lock', then Task1 needs to wait for Task0 to release 'pcc_lock'. In the worst case, this locking order can result in Task1 wasting two scheduling rounds before it can enter the critical section. Signed-off-by: Liao Chang <liaochang1@huawei.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: governor: Free dbs_data directly when gov->init() failsLiao Chang2023-08-291-1/+3
| | | | | | | | | | Due to the kobject embedded in the dbs_data doest not has a release() method yet, it needs to use kfree() to free dbs_data directly when governor fails to allocate the tunner field of dbs_data. Signed-off-by: Liao Chang <liaochang1@huawei.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Fix the race condition while updating the transition_task of policyLiao Chang2023-08-291-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The field 'transition_task' of policy structure is used to track the task which is performing the frequency transition. Using this field to print a warning once detect a case where the same task is calling _begin() again before completing the preivous frequency transition via the _end(). However, there is a potential race condition in _end() and _begin() APIs while updating the field 'transition_task' of policy, the scenario is depicted below: Task A Task B /* 1st freq transition */ Invoke _begin() { ... ... } /* 2nd freq transition */ Invoke _begin() { ... //waiting for A to ... //clear ... //transition_ongoing ... //in _end() for ... //the 1st transition | Change the frequency | | Invoke _end() { | ... | ... | transition_ongoing = false; V transition_ongoing = true; transition_task = current; transition_task = NULL; ... //A overwrites the task ... //performing the transition ... //result in error warning. } To fix this race condition, the transition_lock of policy structure is now acquired before updating policy structure in _end() API. Which ensure that only one task can update the 'transition_task' field at a time. Link: https://lore.kernel.org/all/b3c61d8a-d52d-3136-fbf0-d1de9f1ba411@huawei.com/ Fixes: ca654dc3a93d ("cpufreq: Catch double invocations of cpufreq_freq_transition_begin/end") Signed-off-by: Liao Chang <liaochang1@huawei.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Avoid printing kernel addresses in cpufreq_resume()Liao Chang2023-08-291-4/+4
| | | | | | | | | | | | | | | | The pointer value of policy and driver structure are currently printed in the error messages of cpufreq_resume(), this is not recommended and helpful. In order to be consistent with the error message in cpufreq_suspend() and easier to understand, print the name of driver strcture and the manage CPU of policy structure individually in the error messages of cpufreq_resume(). Link: https://lore.kernel.org/all/b7be717c-41d8-bbbf-3e97-3799948ab757@huawei.com Signed-off-by: Liao Chang <liaochang1@huawei.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* Merge tag 'cpufreq-arm-updates-6.6' of ↵Rafael J. Wysocki2023-08-2830-100/+103
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm Pull ARM cpufreq updates for 6.6 from Viresh Kumar: "- Migrate various platforms to use remove callback returning void (Yangtao Li). - Add online/offline/exit hooks for Tegra driver (Sumit Gupta). - Explicitly include correct DT includes (Rob Herring). - Frequency domain updates for qcom-hw driver (Neil Armstrong). - Modify AMD pstate driver return the highest_perf value (Meng Li). - Generic cleanups for cppc, mediatek and powernow driver (Liao Chang and Konrad Dybcio). - Add more platforms to cpufreq-arm driver's blocklist (AngeloGioacchino Del Regno and Konrad Dybcio). - brcmstb-avs-cpufreq: Fix -Warray-bounds bug (Gustavo A. R. Silva)." * tag 'cpufreq-arm-updates-6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: (33 commits) cpufreq: tegra194: remove opp table in exit hook cpufreq: powernow-k8: Use related_cpus instead of cpus in driver.exit() cpufreq: tegra194: add online/offline hooks cpufreq: qcom-cpufreq-hw: add support for 4 freq domains dt-bindings: cpufreq: qcom-hw: add a 4th frequency domain cpufreq: cppc: Set fie_disabled to FIE_DISABLED if fails to create kworker_fie cpufreq: cppc: cppc_cpufreq_get_rate() returns zero in all error cases. cpufreq: Prefer to print cpuid in MIN/MAX QoS register error message cpufreq: amd-pstate-ut: Modify the function to get the highest_perf value cpufreq: mediatek-hw: Remove unused define cpufreq: blocklist more Qualcomm platforms in cpufreq-dt-platdev cpufreq: brcmstb-avs-cpufreq: Fix -Warray-bounds bug cpufreq: blocklist MSM8998 in cpufreq-dt-platdev cpufreq: omap: Convert to platform remove callback returning void cpufreq: qoriq: Convert to platform remove callback returning void cpufreq: acpi: Convert to platform remove callback returning void cpufreq: tegra186: Convert to platform remove callback returning void cpufreq: qcom-nvmem: Convert to platform remove callback returning void cpufreq: kirkwood: Convert to platform remove callback returning void cpufreq: pcc-cpufreq: Convert to platform remove callback returning void ...
| * cpufreq: tegra194: remove opp table in exit hookSumit Gupta2023-08-281-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add exit hook and remove OPP table when the device gets unregistered. This will fix the error messages when the CPU FREQ driver module is removed and then re-inserted. It also fixes these messages while onlining the first CPU from a policy whose all CPU's were previously offlined. debugfs: File 'cpu5' in directory 'opp' already present! debugfs: File 'cpu6' in directory 'opp' already present! debugfs: File 'cpu7' in directory 'opp' already present! Fixes: f41e1442ac5b ("cpufreq: tegra194: add OPP support and set bandwidth") Signed-off-by: Sumit Gupta <sumitg@nvidia.com> [ Viresh: Dropped irrelevant change from it ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
| * cpufreq: powernow-k8: Use related_cpus instead of cpus in driver.exit()Liao Chang2023-08-281-1/+2
| | | | | | | | | | | | | | | | | | | | Since the 'cpus' field of policy structure will become empty in the cpufreq core API, it is better to use 'related_cpus' in the exit() callback of driver. Fixes: c3274763bfc3 ("cpufreq: powernow-k8: Initialize per-cpu data-structures properly") Signed-off-by: Liao Chang <liaochang1@huawei.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
| * cpufreq: tegra194: add online/offline hooksSumit Gupta2023-08-281-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | Implement the light-weight tear down and bring up helpers to reduce the amount of work to do on CPU offline/online operation. This change helps to make the hotplugging paths much faster. Suggested-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Link: https://lore.kernel.org/lkml/20230816033402.3abmugb5goypvllm@vireshk-i7/ [ Viresh: Fixed rebase conflict ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
| * cpufreq: qcom-cpufreq-hw: add support for 4 freq domainsNeil Armstrong2023-08-231-1/+1
| | | | | | | | | | | | | | | | | | Add support for up to 4 frequency domains as used on new platforms. Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
| * cpufreq: cppc: Set fie_disabled to FIE_DISABLED if fails to create kworker_fieLiao Chang2023-08-171-3/+6
| | | | | | | | | | | | | | | | | | | | The function cppc_freq_invariance_init() may failed to create kworker_fie, make it more robust by setting fie_disabled to FIE_DISBALED to prevent an invalid pointer dereference in kthread_destroy_worker(), which called from cppc_freq_invariance_exit(). Signed-off-by: Liao Chang <liaochang1@huawei.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
| * cpufreq: cppc: cppc_cpufreq_get_rate() returns zero in all error cases.Liao Chang2023-08-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | The cpufreq framework used to use the zero of return value to reflect the cppc_cpufreq_get_rate() had failed to get current frequecy and treat all positive integer to be succeed. Since cppc_get_perf_ctrs() returns a negative integer in error case, so it is better to convert the value to zero as the return value of cppc_cpufreq_get_rate(). Signed-off-by: Liao Chang <liaochang1@huawei.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
| * cpufreq: Prefer to print cpuid in MIN/MAX QoS register error messageLiao Chang2023-08-171-4/+4
| | | | | | | | | | | | | | | | | | | | When a cpufreq_policy is allocated, the cpus, related_cpus and real_cpus of policy are still unset. Therefore, it is preferable to print the passed 'cpu' parameter instead of a empty 'cpus' cpumask in error message when registering MIN/MAX QoS notifier fails. Signed-off-by: Liao Chang <liaochang1@huawei.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
| * cpufreq: amd-pstate-ut: Modify the function to get the highest_perf valueMeng Li2023-08-111-2/+2
| | | | | | | | | | | | | | | | | | | | | | The previous function amd_get_highest_perf() will be deprecated. It can only return 166 or 255 by cpuinfo. For platforms that support preferred core, the value of highest perf can be between 166 and 255. Therefore, it will cause amd-pstate-ut to fail when run amd_pstate_ut_check_perf(). Signed-off-by: Meng Li <li.meng@amd.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
| * cpufreq: mediatek-hw: Remove unused defineKonrad Dybcio2023-08-111-2/+0
| | | | | | | | | | | | | | DYNAMIC_POWER does not seem to be used anywhere in the tree, remove it. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
| * cpufreq: blocklist more Qualcomm platforms in cpufreq-dt-platdevKonrad Dybcio2023-08-091-0/+6
| | | | | | | | | | | | | | | | All Qualcomm platforms utilizing the qcom-cpufreq-hw driver have no business in using cpufreq-dt. Prevent that from happening. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
| * cpufreq: brcmstb-avs-cpufreq: Fix -Warray-bounds bugGustavo A. R. Silva2023-08-031-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allocate extra space for terminating element at: drivers/cpufreq/brcmstb-avs-cpufreq.c: 449 table[i].frequency = CPUFREQ_TABLE_END; and add code comment to make this clear. This fixes the following -Warray-bounds warning seen after building ARM with multi_v7_defconfig (GCC 13): In function 'brcm_avs_get_freq_table', inlined from 'brcm_avs_cpufreq_init' at drivers/cpufreq/brcmstb-avs-cpufreq.c:623:15: drivers/cpufreq/brcmstb-avs-cpufreq.c:449:28: warning: array subscript 5 is outside array bounds of 'void[60]' [-Warray-bounds=] 449 | table[i].frequency = CPUFREQ_TABLE_END; In file included from include/linux/node.h:18, from include/linux/cpu.h:17, from include/linux/cpufreq.h:12, from drivers/cpufreq/brcmstb-avs-cpufreq.c:44: In function 'devm_kmalloc_array', inlined from 'devm_kcalloc' at include/linux/device.h:328:9, inlined from 'brcm_avs_get_freq_table' at drivers/cpufreq/brcmstb-avs-cpufreq.c:437:10, inlined from 'brcm_avs_cpufreq_init' at drivers/cpufreq/brcmstb-avs-cpufreq.c:623:15: include/linux/device.h:323:16: note: at offset 60 into object of size 60 allocated by 'devm_kmalloc' 323 | return devm_kmalloc(dev, bytes, flags); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help us make progress towards globally enabling -Warray-bounds. Link: https://github.com/KSPP/linux/issues/324 Fixes: de322e085995 ("cpufreq: brcmstb-avs-cpufreq: AVS CPUfreq driver for Broadcom STB SoCs") Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
| * cpufreq: blocklist MSM8998 in cpufreq-dt-platdevAngeloGioacchino Del Regno2023-08-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | Add the MSM8998 to the blocklist since the CPU scaling on this platform is handled by a separate driver. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Tested-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
| * cpufreq: omap: Convert to platform remove callback returning voidYangtao Li2023-07-201-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Yangtao Li <frank.li@vivo.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
| * cpufreq: qoriq: Convert to platform remove callback returning voidYangtao Li2023-07-201-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Yangtao Li <frank.li@vivo.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
| * cpufreq: acpi: Convert to platform remove callback returning voidYangtao Li2023-07-201-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Yangtao Li <frank.li@vivo.com> Acked-by: Rafael J. Wysocki <rafael@kernel.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
| * cpufreq: tegra186: Convert to platform remove callback returning voidYangtao Li2023-07-201-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Yangtao Li <frank.li@vivo.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
| * cpufreq: qcom-nvmem: Convert to platform remove callback returning voidYangtao Li2023-07-201-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Yangtao Li <frank.li@vivo.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
| * cpufreq: kirkwood: Convert to platform remove callback returning voidYangtao Li2023-07-201-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Yangtao Li <frank.li@vivo.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
| * cpufreq: pcc-cpufreq: Convert to platform remove callback returning voidYangtao Li2023-07-201-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Yangtao Li <frank.li@vivo.com> Acked-by: Rafael J. Wysocki <rafael@kernel.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
| * cpufreq: raspberrypi: Convert to platform remove callback returning voidYangtao Li2023-07-201-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Yangtao Li <frank.li@vivo.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
| * cpufreq: davinci: Convert to platform remove callback returning voidYangtao Li2023-07-201-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Yangtao Li <frank.li@vivo.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
| * cpufreq: imx-cpufreq-dt: Convert to platform remove callback returning voidYangtao Li2023-07-201-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Yangtao Li <frank.li@vivo.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
| * cpufreq: brcmstb-avs-cpufreq: Convert to platform remove callback returning voidYangtao Li2023-07-201-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Yangtao Li <frank.li@vivo.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
| * cpufreq: tegra194: Convert to platform remove callback returning voidYangtao Li2023-07-201-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Yangtao Li <frank.li@vivo.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
| * cpufreq: scpi: Convert to platform remove callback returning voidYangtao Li2023-07-201-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Yangtao Li <frank.li@vivo.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
| * cpufreq: mediatek-hw: Convert to platform remove callback returning voidYangtao Li2023-07-201-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Yangtao Li <frank.li@vivo.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
| * cpufreq: imx6q: Convert to platform remove callback returning voidYangtao Li2023-07-201-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Yangtao Li <frank.li@vivo.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
| * cpufreq: vexpress: Convert to platform remove callback returning voidYangtao Li2023-07-201-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Yangtao Li <frank.li@vivo.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
| * cpufreq: qcom-cpufreq-hw: Convert to platform remove callback returning voidYangtao Li2023-07-201-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Yangtao Li <frank.li@vivo.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
| * cpufreq: dt: Convert to platform remove callback returning voidYangtao Li2023-07-201-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Yangtao Li <frank.li@vivo.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
| * cpufreq: sun50i: Convert to platform remove callback returning voidYangtao Li2023-07-201-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Yangtao Li <frank.li@vivo.com> Acked-by: Jernej Škrabec <jernej.skrabec@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
| * cpufreq: Explicitly include correct DT includesRob Herring2023-07-209-11/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Rafael J. Wysocki <rafael@kernel.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
* | cpufreq: amd-pstate-ut: Fix kernel panic when loading the driverSwapnil Sapkal2023-08-221-8/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After loading the amd-pstate-ut driver, amd_pstate_ut_check_perf() and amd_pstate_ut_check_freq() use cpufreq_cpu_get() to get the policy of the CPU and mark it as busy. In these functions, cpufreq_cpu_put() should be used to release the policy, but it is not, so any other entity trying to access the policy is blocked indefinitely. One such scenario is when amd_pstate mode is changed, leading to the following splat: [ 1332.103727] INFO: task bash:2929 blocked for more than 120 seconds. [ 1332.110001] Not tainted 6.5.0-rc2-amd-pstate-ut #5 [ 1332.115315] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1332.123140] task:bash state:D stack:0 pid:2929 ppid:2873 flags:0x00004006 [ 1332.123143] Call Trace: [ 1332.123145] <TASK> [ 1332.123148] __schedule+0x3c1/0x16a0 [ 1332.123154] ? _raw_read_lock_irqsave+0x2d/0x70 [ 1332.123157] schedule+0x6f/0x110 [ 1332.123160] schedule_timeout+0x14f/0x160 [ 1332.123162] ? preempt_count_add+0x86/0xd0 [ 1332.123165] __wait_for_common+0x92/0x190 [ 1332.123168] ? __pfx_schedule_timeout+0x10/0x10 [ 1332.123170] wait_for_completion+0x28/0x30 [ 1332.123173] cpufreq_policy_put_kobj+0x4d/0x90 [ 1332.123177] cpufreq_policy_free+0x157/0x1d0 [ 1332.123178] ? preempt_count_add+0x58/0xd0 [ 1332.123180] cpufreq_remove_dev+0xb6/0x100 [ 1332.123182] subsys_interface_unregister+0x114/0x120 [ 1332.123185] ? preempt_count_add+0x58/0xd0 [ 1332.123187] ? __pfx_amd_pstate_change_driver_mode+0x10/0x10 [ 1332.123190] cpufreq_unregister_driver+0x3b/0xd0 [ 1332.123192] amd_pstate_change_driver_mode+0x1e/0x50 [ 1332.123194] store_status+0xe9/0x180 [ 1332.123197] dev_attr_store+0x1b/0x30 [ 1332.123199] sysfs_kf_write+0x42/0x50 [ 1332.123202] kernfs_fop_write_iter+0x143/0x1d0 [ 1332.123204] vfs_write+0x2df/0x400 [ 1332.123208] ksys_write+0x6b/0xf0 [ 1332.123210] __x64_sys_write+0x1d/0x30 [ 1332.123213] do_syscall_64+0x60/0x90 [ 1332.123216] ? fpregs_assert_state_consistent+0x2e/0x50 [ 1332.123219] ? exit_to_user_mode_prepare+0x49/0x1a0 [ 1332.123223] ? irqentry_exit_to_user_mode+0xd/0x20 [ 1332.123225] ? irqentry_exit+0x3f/0x50 [ 1332.123226] ? exc_page_fault+0x8e/0x190 [ 1332.123228] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 1332.123232] RIP: 0033:0x7fa74c514a37 [ 1332.123234] RSP: 002b:00007ffe31dd0788 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 1332.123238] RAX: ffffffffffffffda RBX: 0000000000000008 RCX: 00007fa74c514a37 [ 1332.123239] RDX: 0000000000000008 RSI: 000055e27c447aa0 RDI: 0000000000000001 [ 1332.123241] RBP: 000055e27c447aa0 R08: 00007fa74c5d1460 R09: 000000007fffffff [ 1332.123242] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000008 [ 1332.123244] R13: 00007fa74c61a780 R14: 00007fa74c616600 R15: 00007fa74c615a00 [ 1332.123247] </TASK> Fix this by calling cpufreq_cpu_put() wherever necessary. Fixes: 14eb1c96e3a3 ("cpufreq: amd-pstate: Add test module for amd-pstate driver") Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Meng Li <li.meng@amd.com> Reviewed-by: Wyes Karny <wyes.karny@amd.com> Suggested-by: Wyes Karny <wyes.karny@amd.com> Signed-off-by: Swapnil Sapkal <swapnil.sapkal@amd.com> [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | cpufreq: amd-pstate-ut: Remove module parameter accessSwapnil Sapkal2023-08-221-20/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In amd-pstate-ut, shared memory-based systems call get_shared_mem() as part of amd_pstate_ut_check_enabled() function. This function was written when CONFIG_X86_AMD_PSTATE was tristate config and amd_pstate can be built as a module. Currently CONFIG_X86_AMD_PSTATE is a boolean config and module parameter shared_mem is removed. But amd-pstate-ut code still accesses this module parameter. Remove those accesses. Fixes: 456ca88d8a52 ("cpufreq: amd-pstate: change amd-pstate driver to be built-in type") Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Meng Li <li.meng@amd.com> Reviewed-by: Wyes Karny <wyes.karny@amd.com> Suggested-by: Wyes Karny <wyes.karny@amd.com> Signed-off-by: Swapnil Sapkal <swapnil.sapkal@amd.com> [ rjw: Subject edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | cpufreq: intel_pstate: set stale CPU frequency to minimumDoug Smythies2023-08-211-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The intel_pstate CPU frequency scaling driver does not use policy->cur and it is 0. When the CPU frequency is outdated arch_freq_get_on_cpu() will default to the nominal clock frequency when its call to cpufreq_quick_getpolicy_cur returns the never updated 0. Thus, the listed frequency might be outside of currently set limits. Some users are complaining about the high reported frequency, albeit stale, when their system is idle and/or it is above the reduced maximum they have set. This patch will maintain policy_cur for the intel_pstate driver at the current minimum CPU frequency. Reported-by: Yang Jie <yang.jie@linux.intel.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217597 Signed-off-by: Doug Smythies <dsmythies@telus.net> [ rjw: White space damage fixes and comment adjustment ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | cpufreq: stats: Improve the performance of cpufreq_stats_create_table()Liao Chang2023-08-211-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the worst case, the freq_table of policy data is not sorted and contains duplicate frequencies, this means that it needs to iterate through the entire freq_table of policy to ensure each frequency is unique in the freq_table of stats data, this has a time complexity of O(N^2), where N is the number of frequencies in the freq_table of policy. However, if the policy.freq_table is already sorted and contains no duplicate frequencies, it can reduce the time complexity of creating stats.freq_table to O(N), the 'freq_table_sorted' field of policy data can be used to indicate whether the policy.freq_table is sorted. Signed-off-by: Liao Chang <liaochang1@huawei.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Dhruva Gole <d-gole@ti.com> [ rjw: Fix typo in changelog, remove redundant parens ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | cpufreq: amd-pstate: fix global sysfs attribute typeThomas Weißschuh2023-08-071-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit 3666062b87ec ("cpufreq: amd-pstate: move to use bus_get_dev_root()") the "amd_pstate" attributes where moved from a dedicated kobject to the cpu root kobject. While the dedicated kobject expects to contain kobj_attributes the root kobject needs device_attributes. As the changed arguments are not used by the callbacks it works most of the time. However CFI will detect this issue: [ 4947.849350] CFI failure at dev_attr_show+0x24/0x60 (target: show_status+0x0/0x70; expected type: 0x8651b1de) ... [ 4947.849409] Call Trace: [ 4947.849410] <TASK> [ 4947.849411] ? __warn+0xcf/0x1c0 [ 4947.849414] ? dev_attr_show+0x24/0x60 [ 4947.849415] ? report_cfi_failure+0x4e/0x60 [ 4947.849417] ? handle_cfi_failure+0x14c/0x1d0 [ 4947.849419] ? __cfi_show_status+0x10/0x10 [ 4947.849420] ? handle_bug+0x4f/0x90 [ 4947.849421] ? exc_invalid_op+0x1a/0x60 [ 4947.849422] ? asm_exc_invalid_op+0x1a/0x20 [ 4947.849424] ? __cfi_show_status+0x10/0x10 [ 4947.849425] ? dev_attr_show+0x24/0x60 [ 4947.849426] sysfs_kf_seq_show+0xa6/0x110 [ 4947.849433] seq_read_iter+0x16c/0x4b0 [ 4947.849436] vfs_read+0x272/0x2d0 [ 4947.849438] ksys_read+0x72/0xe0 [ 4947.849439] do_syscall_64+0x76/0xb0 [ 4947.849440] ? do_user_addr_fault+0x252/0x650 [ 4947.849442] ? exc_page_fault+0x7a/0x1b0 [ 4947.849443] entry_SYSCALL_64_after_hwframe+0x72/0xdc Fixes: 3666062b87ec ("cpufreq: amd-pstate: move to use bus_get_dev_root()") Reported-by: Jannik Glückert <jannik.glueckert@gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217765 Link: https://lore.kernel.org/lkml/c7f1bf9b-b183-bf6e-1cbb-d43f72494083@gmail.com/ Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | cpufreq: sparc: Don't mark cpufreq callbacks with __initViresh Kumar2023-07-122-2/+2
|/ | | | | | | | | | | | | | | These callbacks can be called again by the cpufreq core after the driver is initialized and must be kept around. We currently get section mismatch build warnings. Don't mark them with __init. Fixes: dcfce7c2cee4 ("cpufreq: sparc: Don't allocate cpufreq_driver dynamically") Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* Merge tag 'pm-6.5-rc1-2' of ↵Linus Torvalds2023-07-0411-120/+130
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull more power management updates from Rafael Wysocki: "These add support for new hardware (ap807 and AM62A7), fix several issues in cpufreq drivers and in the operating performance points (OPP) framework, fix up intel_idle after recent changes and add documentation. Specifics: - Add missing __init annotation to one function in the intel_idle drvier (Rafael Wysocki) - Make intel_pstate use a correct scaling factor when mapping HWP performance levels to frequency values on hybrid-capable systems with disabled E-cores (Srinivas Pandruvada) - Fix Kconfig dependencies of the cpufreq-dt-platform driver (Viresh Kumar) - Add support to build cpufreq-dt-platdev as a module (Zhipeng Wang) - Don't allocate Sparc's cpufreq_driver dynamically (Viresh Kumar) - Add support for TI's AM62A7 platform (Vibhore Vardhan) - Add support for Armada's ap807 platform (Russell King (Oracle)) - Add support for StarFive JH7110 SoC (Mason Huo) - Fix voltage selection for Mediatek Socs (Daniel Golle) - Fix error handling in Tegra's cpufreq driver (Christophe JAILLET) - Document Qualcomm's IPQ8074 in DT bindings (Robert Marko) - Don't warn for disabling a non-existing frequency for imx6q cpufreq driver (Christoph Niedermaier) - Use dev_err_probe() in Qualcomm's cpufreq driver (Andrew Halaney) - Simplify performance state related logic in the OPP core (Viresh Kumar) - Fix use-after-free and improve locking around lazy_opp_tables (Viresh Kumar, Stephan Gerhold) - Minor cleanups - using dev_err_probe() and rate-limiting debug messages (Andrew Halaney, Adrián Larumbe)" * tag 'pm-6.5-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (23 commits) cpufreq: intel_pstate: Fix scaling for hybrid-capable systems with disabled E-cores cpufreq: Make CONFIG_CPUFREQ_DT_PLATDEV depend on OF intel_idle: Add __init annotation to matchup_vm_state_with_baremetal() OPP: Properly propagate error along when failing to get icc_path OPP: Use dev_err_probe() when failing to get icc_path cpufreq: qcom-cpufreq-hw: Use dev_err_probe() when failing to get icc paths cpufreq: mediatek: correct voltages for MT7622 and MT7623 cpufreq: armada-8k: add ap807 support OPP: Simplify the over-designed pstate <-> level dance OPP: pstate is only valid for genpd OPP tables OPP: don't drop performance constraint on OPP table removal OPP: Protect `lazy_opp_tables` list with `opp_table_lock` OPP: Staticize `lazy_opp_tables` in of.c cpufreq: dt-platdev: Support building as module opp: Fix use-after-free in lazy_opp_tables after probe deferral dt-bindings: cpufreq: qcom-cpufreq-nvmem: document IPQ8074 cpufreq: dt-platdev: Blacklist ti,am62a7 SoC cpufreq: ti-cpufreq: Add support for AM62A7 OPP: rate-limit debug messages when no change in OPP is required cpufreq: imx6q: don't warn for disabling a non-existing frequency ...
| * cpufreq: intel_pstate: Fix scaling for hybrid-capable systems with disabled ↵Srinivas Pandruvada2023-06-301-10/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | E-cores Some system BIOS configuration may provide option to disable E-cores. As part of this change, CPUID feature for hybrid (Leaf 7 sub leaf 0, EDX[15] = 0) may not be set. But HWP performance limits will still be using a scaling factor like any other hybrid enabled system. The current check for applying scaling factor will fail when hybrid CPUID feature is not set and the only way to make sure that scaling should be applied by checking CPPC nominal frequency and nominal performance. First, or systems predating Alder Lake, the CPPC nominal frequency and nominal performance are 0, which can be used to distinguish those systems from hybrid systems with disabled E-cores. Second, if the CPPC nominal frequency and nominal performance are defined, which indicates the need to use a special scaling factor, and the nominal performance value multiplied by 100 is not equal to the nominal frequency one, use hybrid scaling factor. This can be done for all HWP systems without additional CPU model check. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> [ rjw: Subject and changelog edits, removal of unneeded parens, comment edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: Make CONFIG_CPUFREQ_DT_PLATDEV depend on OFViresh Kumar2023-06-301-0/+1
| | | | | | | | | | | | | | | | | | | | The cpufreq-dt-platform.c driver requires CONFIG_OF to be selected. Mark it as a dependency. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202306250025.savpMM8L-lkp@intel.com/ Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * Merge tag 'cpufreq-arm-updates-6.5' of ↵Rafael J. Wysocki2023-06-2710-110/+81
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm Pull ARM cpufreq updates for 6.5 from Viresh Kumar: "- Add support to build cpufreq-dt-platdev as module (Zhipeng Wang). - Don't allocate Sparc's cpufreq_driver dynamically (Viresh Kumar). - Add support for TI's AM62A7 platform (Vibhore Vardhan). - Add support for Armada's ap807 platform (Russell King (Oracle)). - Add support for StarFive JH7110 SoC (Mason Huo). - Fix voltage selection for Mediatek Socs (Daniel Golle). - Fix error handling in Tegra's cpufreq driver (Christophe JAILLET). - Document Qualcomm's IPQ8074 in DT bindings (Robert Marko). - Don't warn for disabling a non-existing frequency for imx6q cpufreq driver (Christoph Niedermaier). - Use dev_err_probe() in Qualcomm's cpufreq driver (Andrew Halaney)."
| | * cpufreq: qcom-cpufreq-hw: Use dev_err_probe() when failing to get icc pathsAndrew Halaney2023-06-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This way, if there's an issue (in this case a -EPROBE_DEFER), you can get useful output: [root@dhcp19-243-150 ~]# cat /sys/kernel/debug/devices_deferred 18591000.cpufreq qcom-cpufreq-hw: Failed to find icc paths Signed-off-by: Andrew Halaney <ahalaney@redhat.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
| | * cpufreq: mediatek: correct voltages for MT7622 and MT7623Daniel Golle2023-06-191-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The MT6380 regulator typically used together with MT7622 does not support the current maximum processor and SRAM voltage in the cpufreq driver (1360000uV). For MT7622 limit processor and SRAM supply voltages to 1350000uV to avoid having the tracking algorithm request unsupported voltages from the regulator. On MT7623 there is no separate SRAM supply and the maximum voltage used is 1300000uV. Create dedicated platform data for MT7623 to cover that case as well. Fixes: 0883426fd07e3 ("cpufreq: mediatek: Raise proc and sram max voltage for MT7622/7623") Suggested-by: Jia-wei Chang <Jia-wei.Chang@mediatek.com> Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>