aboutsummaryrefslogtreecommitdiff
path: root/drivers/cpufreq
AgeCommit message (Collapse)AuthorFilesLines
2021-10-05cpufreq: Make policy min/max hard requirementsVincent Donnefort1-0/+7
When applying the policy min/max limits, the requested frequency is simply clamped to not be out of range. It means, however, if one of the boundaries isn't an available frequency, the frequency resolution can return a value out of those limits, depending on the relation used. e.g. freq{0,1,2} being available frequencies. freq0 policy->min freq1 policy->max freq2 | | | | | 17kHz 18kHz 19kHz 20kHz 21kHz __resolve_freq(21kHz, CPUFREQ_RELATION_L) -> 21kHz (out of bounds) __resolve_freq(17kHz, CPUFREQ_RELATION_H) -> 17kHz (out of bounds) If, during the policy init, we resolve the requested min/max to existing frequencies, we ensure that any CPUFREQ_RELATION_* would resolve to a frequency which is inside the policy min/max range. Making the policy limits rigid helps to introduce the inefficient frequencies support. Resolving an inefficient frequency to an efficient one should not transgress policy->max (which can be set for thermal reason) and having a value we can trust simplify this comparison. Signed-off-by: Vincent Donnefort <[email protected]> Acked-by: Viresh Kumar <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2021-10-05cpufreq: intel_pstate: Process HWP Guaranteed change notificationSrinivas Pandruvada1-6/+111
It is possible that HWP guaranteed ratio is changed in response to change in power and thermal limits. For example when Intel Speed Select performance profile is changed or there is change in TDP, hardware can send notifications. It is possible that the guaranteed ratio is increased. This creates an issue when turbo is disabled, as the old limits set in MSR_HWP_REQUEST are still lower and hardware will clip to older limits. This change enables HWP interrupt and process HWP interrupts. When guaranteed is changed, calls cpufreq_update_policy() so that driver callbacks are called to update to new HWP limits. This callback is called from a delayed workqueue of 10ms to avoid frequent updates. Although the scope of IA32_HWP_INTERRUPT is per logical cpu, on some plaforms interrupt is generated on all CPUs. This is particularly a problem during initialization, when the driver didn't allocated data for other CPUs. So this change uses a cpumask of enabled CPUs and process interrupts on those CPUs only. When the cpufreq offline() or suspend() callback is called, HWP interrupt is disabled on those CPUs and also cancels any pending work item. Spin lock is used to protect data and processing shared with interrupt handler. Here READ_ONCE(), WRITE_ONCE() macros are used to designate shared data, even though spin lock act as an optimization barrier here. Signed-off-by: Srinivas Pandruvada <[email protected]> Tested-by: [email protected] Signed-off-by: Rafael J. Wysocki <[email protected]>
2021-10-04cpufreq: tegra186/tegra194: Handle errors in BPMP responseMikko Perttunen2-1/+11
The return value from tegra_bpmp_transfer indicates the success or failure of the IPC transaction with BPMP. If the transaction succeeded, we also need to check the actual command's result code. Add code to do this. While at it, explicitly handle missing CPU clusters, which can occur on floorswept chips. This worked before as well, but possibly only by accident. Signed-off-by: Mikko Perttunen <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2021-10-04cpufreq: remove useless INIT_LIST_HEAD()Han Wang1-2/+0
list cpu_data_list has been inited staticly through LIST_HEAD, so there's no need to call another INIT_LIST_HEAD. Simply remove it from cppc_cpufreq_init. Signed-off-by: Han Wang <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2021-10-04cpufreq: s3c244x: add fallthrough comments for switchArnd Bergmann1-0/+2
Apparently nobody has so far caught this warning, I hit it in randconfig build testing: drivers/cpufreq/s3c2440-cpufreq.c: In function 's3c2440_cpufreq_setdivs': drivers/cpufreq/s3c2440-cpufreq.c:175:10: error: this statement may fall through [-Werror=implicit-fallthrough=] camdiv |= S3C2440_CAMDIVN_HCLK3_HALF; ^ drivers/cpufreq/s3c2440-cpufreq.c:176:2: note: here case 3: ^~~~ drivers/cpufreq/s3c2440-cpufreq.c:181:10: error: this statement may fall through [-Werror=implicit-fallthrough=] camdiv |= S3C2440_CAMDIVN_HCLK4_HALF; ^ drivers/cpufreq/s3c2440-cpufreq.c:182:2: note: here case 4: ^~~~ Both look like the fallthrough is intentional, so add the new "fallthrough;" keyword. Signed-off-by: Arnd Bergmann <[email protected]> Acked-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2021-10-04cpufreq: vexpress: Drop unused variableGuenter Roeck1-1/+0
arm:allmodconfig fails to build with the following error. drivers/cpufreq/vexpress-spc-cpufreq.c:454:13: error: unused variable 'cur_cluster' Remove the unused variable. Fixes: bb8c26d9387f ("cpufreq: vexpress: Set CPUFREQ_IS_COOLING_DEV flag") Cc: Viresh Kumar <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2021-09-17Merge tag 'pm-5.15-rc2' of ↵Linus Torvalds2-9/+15
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fixes from Rafael Wysocki: "These fix two cpufreq issues, one in the intel_pstate driver and one in the core. Specifics: - Prevent intel_pstate from avoiding to use HWP, even if instructed to do so via the kernel command line, when HWP has been enabled already by the platform firmware (Doug Smythies). - Prevent use-after-free from occurring in the schedutil cpufreq governor on exit by fixing a core helper function that attempts to access memory associated with a kobject after calling kobject_put() on it (James Morse)" * tag 'pm-5.15-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: cpufreq: schedutil: Destroy mutex before kobject_put() frees the memory cpufreq: intel_pstate: Override parameters if HWP forced by BIOS
2021-09-16cpufreq: vexpress: Drop unused variableGuenter Roeck1-1/+0
arm:allmodconfig fails to build with the following error. drivers/cpufreq/vexpress-spc-cpufreq.c:454:13: error: unused variable 'cur_cluster' Remove the unused variable. Fixes: bb8c26d9387f ("cpufreq: vexpress: Set CPUFREQ_IS_COOLING_DEV flag") Cc: Viresh Kumar <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-09-14cpufreq: schedutil: Destroy mutex before kobject_put() frees the memoryJames Morse1-1/+1
Since commit e5c6b312ce3c ("cpufreq: schedutil: Use kobject release() method to free sugov_tunables") kobject_put() has kfree()d the attr_set before gov_attr_set_put() returns. kobject_put() isn't the last user of attr_set in gov_attr_set_put(), the subsequent mutex_destroy() triggers a use-after-free: | BUG: KASAN: use-after-free in mutex_is_locked+0x20/0x60 | Read of size 8 at addr ffff000800ca4250 by task cpuhp/2/20 | | CPU: 2 PID: 20 Comm: cpuhp/2 Not tainted 5.15.0-rc1 #12369 | Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development | Platform, BIOS EDK II Jul 30 2018 | Call trace: | dump_backtrace+0x0/0x380 | show_stack+0x1c/0x30 | dump_stack_lvl+0x8c/0xb8 | print_address_description.constprop.0+0x74/0x2b8 | kasan_report+0x1f4/0x210 | kasan_check_range+0xfc/0x1a4 | __kasan_check_read+0x38/0x60 | mutex_is_locked+0x20/0x60 | mutex_destroy+0x80/0x100 | gov_attr_set_put+0xfc/0x150 | sugov_exit+0x78/0x190 | cpufreq_offline.isra.0+0x2c0/0x660 | cpuhp_cpufreq_offline+0x14/0x24 | cpuhp_invoke_callback+0x430/0x6d0 | cpuhp_thread_fun+0x1b0/0x624 | smpboot_thread_fn+0x5e0/0xa6c | kthread+0x3a0/0x450 | ret_from_fork+0x10/0x20 Swap the order of the calls. Fixes: e5c6b312ce3c ("cpufreq: schedutil: Use kobject release() method to free sugov_tunables") Cc: 4.7+ <[email protected]> # 4.7+ Signed-off-by: James Morse <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2021-09-13cpufreq: intel_pstate: Override parameters if HWP forced by BIOSDoug Smythies1-8/+14
If HWP has been already been enabled by BIOS, it may be necessary to override some kernel command line parameters. Once it has been enabled it requires a reset to be disabled. Suggested-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Doug Smythies <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2021-09-10Merge branches 'pm-cpufreq', 'pm-sleep' and 'pm-em'Rafael J. Wysocki1-114/+71
* pm-cpufreq: cpufreq: intel_pstate: hybrid: Rework HWP calibration ACPI: CPPC: Introduce cppc_get_nominal_perf() * pm-sleep: PM: sleep: core: Avoid setting power.must_resume to false PM: sleep: wakeirq: drop useless parameter from dev_pm_attach_wake_irq() * pm-em: Documentation: power: include kernel-doc in Energy Model doc PM: EM: fix kernel-doc comments
2021-09-08Merge tag 'pm-5.15-rc1-2' of ↵Linus Torvalds16-119/+541
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull more power management updates from Rafael Wysocki: "These are mostly ARM cpufreq driver updates, including one new MediaTek driver that has just passed all of the reviews, with the addition of a revert of a recent intel_pstate commit, some core cpufreq changes and a DT-related update of the operating performance points (OPP) support code. Specifics: - Add new cpufreq driver for the MediaTek MT6779 platform called mediatek-hw along with corresponding DT bindings (Hector.Yuan). - Add DCVS interrupt support to the qcom-cpufreq-hw driver (Thara Gopinath). - Make the qcom-cpufreq-hw driver set the dvfs_possible_from_any_cpu policy flag (Taniya Das). - Blocklist more Qualcomm platforms in cpufreq-dt-platdev (Bjorn Andersson). - Make the vexpress cpufreq driver set the CPUFREQ_IS_COOLING_DEV flag (Viresh Kumar). - Add new cpufreq driver callback to allow drivers to register with the Energy Model in a consistent way and make several drivers use it (Viresh Kumar). - Change the remaining users of the .ready() cpufreq driver callback to move the code from it elsewhere and drop it from the cpufreq core (Viresh Kumar). - Revert recent intel_pstate change adding HWP guaranteed performance change notification support to it that led to problems, because the notification in question is triggered prematurely on some systems (Rafael Wysocki). - Convert the OPP DT bindings to DT schema and clean them up while at it (Rob Herring)" * tag 'pm-5.15-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (23 commits) Revert "cpufreq: intel_pstate: Process HWP Guaranteed change notification" cpufreq: mediatek-hw: Add support for CPUFREQ HW cpufreq: Add of_perf_domain_get_sharing_cpumask dt-bindings: cpufreq: add bindings for MediaTek cpufreq HW cpufreq: Remove ready() callback cpufreq: sh: Remove sh_cpufreq_cpu_ready() cpufreq: acpi: Remove acpi_cpufreq_cpu_ready() cpufreq: qcom-hw: Set dvfs_possible_from_any_cpu cpufreq driver flag cpufreq: blocklist more Qualcomm platforms in cpufreq-dt-platdev cpufreq: qcom-cpufreq-hw: Add dcvs interrupt support cpufreq: scmi: Use .register_em() to register with energy model cpufreq: vexpress: Use .register_em() to register with energy model cpufreq: scpi: Use .register_em() to register with energy model dt-bindings: opp: Convert to DT schema dt-bindings: Clean-up OPP binding node names in examples ARM: dts: omap: Drop references to opp.txt cpufreq: qcom-cpufreq-hw: Use .register_em() to register with energy model cpufreq: omap: Use .register_em() to register with energy model cpufreq: mediatek: Use .register_em() to register with energy model cpufreq: imx6q: Use .register_em() to register with energy model ...
2021-09-07cpufreq: intel_pstate: hybrid: Rework HWP calibrationRafael J. Wysocki1-114/+71
The current HWP calibration for hybrid processors in intel_pstate is fragile, because it depends too much on the information provided by the platform firmware via CPPC which may not be reliable enough. It also need not be so complicated. In order to improve that mechanism and make it more resistant to platform firmware issues, make it only use the CPPC nominal_perf values to compute the HWP-to-frequency scaling factors for all CPUs and possibly use the HWP_CAP highest_perf values to recompute them if the ones derived from the CPPC nominal_perf values alone appear to be too high. Namely, fetch CPC.nominal_perf for all CPUs present in the system, find the minimum one and use it as a reference for computing all of the CPUs' scaling factors (using the observation that for the CPUs having the minimum CPC.nominal_perf the HWP range of available performance levels should be the same as the range of available "legacy" P-states and so the HWP-to-frequency scaling factor for them should be the same as the corresponding scaling factor used for representing the P-state values in kHz). Signed-off-by: Rafael J. Wysocki <[email protected]> Tested-by: Zhang Rui <[email protected]>
2021-09-07Merge branch 'cpufreq/arm/linux-next' of ↵Rafael J. Wysocki3-0/+321
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm Pull more ARM cpufreq changes for v5.15-rc1 from Viresh Kumar: "This adds a new cpufreq driver for Mediatek, which had been going through reviews since last one year." * 'cpufreq/arm/linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: cpufreq: mediatek-hw: Add support for CPUFREQ HW cpufreq: Add of_perf_domain_get_sharing_cpumask dt-bindings: cpufreq: add bindings for MediaTek cpufreq HW
2021-09-07Revert "cpufreq: intel_pstate: Process HWP Guaranteed change notification"Rafael J. Wysocki1-39/+0
Revert commit d0e936adbd22 ("cpufreq: intel_pstate: Process HWP Guaranteed change notification"), because it causes a NULL pointer dereference to occur on Lenovo X1 gen9 laptops due to an HWP guaranteed performance change interrupt arriving prematurely. This feature will be revisited in the next cycle. Reported-by: Jens Axboe <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2021-09-06cpufreq: mediatek-hw: Add support for CPUFREQ HWHector.Yuan3-0/+321
Introduce cpufreq HW driver which can support CPU frequency adjust in MT6779 platform. Signed-off-by: Hector.Yuan <[email protected]> [ Viresh: Massaged the patch and cleaned some stuff. ] Signed-off-by: Viresh Kumar <[email protected]>
2021-09-03Merge tag 'powerpc-5.15-1' of ↵Linus Torvalds1-2/+14
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux Pull powerpc updates from Michael Ellerman: - Convert pseries & powernv to use MSI IRQ domains. - Rework the pseries CPU numbering so that CPUs that are removed, and later re-added, are given a CPU number on the same node as previously, when possible. - Add support for a new more flexible device-tree format for specifying NUMA distances. - Convert powerpc to GENERIC_PTDUMP. - Retire sbc8548 and sbc8641d board support. - Various other small features and fixes. Thanks to Alexey Kardashevskiy, Aneesh Kumar K.V, Anton Blanchard, Cédric Le Goater, Christophe Leroy, Emmanuel Gil Peyrot, Fabiano Rosas, Fangrui Song, Finn Thain, Gautham R. Shenoy, Hari Bathini, Joel Stanley, Jordan Niethe, Kajol Jain, Laurent Dufour, Leonardo Bras, Lukas Bulwahn, Marc Zyngier, Masahiro Yamada, Michal Suchanek, Nathan Chancellor, Nicholas Piggin, Parth Shah, Paul Gortmaker, Pratik R. Sampat, Randy Dunlap, Sebastian Andrzej Siewior, Srikar Dronamraju, Wan Jiabing, Xiongwei Song, and Zheng Yongjun. * tag 'powerpc-5.15-1' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: (154 commits) powerpc/bug: Cast to unsigned long before passing to inline asm powerpc/ptdump: Fix generic ptdump for 64-bit KVM: PPC: Fix clearing never mapped TCEs in realmode powerpc/pseries/iommu: Rename "direct window" to "dma window" powerpc/pseries/iommu: Make use of DDW for indirect mapping powerpc/pseries/iommu: Find existing DDW with given property name powerpc/pseries/iommu: Update remove_dma_window() to accept property name powerpc/pseries/iommu: Reorganize iommu_table_setparms*() with new helper powerpc/pseries/iommu: Add ddw_property_create() and refactor enable_ddw() powerpc/pseries/iommu: Allow DDW windows starting at 0x00 powerpc/pseries/iommu: Add ddw_list_new_entry() helper powerpc/pseries/iommu: Add iommu_pseries_alloc_table() helper powerpc/kernel/iommu: Add new iommu_table_in_use() helper powerpc/pseries/iommu: Replace hard-coded page shift powerpc/numa: Update cpu_cpu_map on CPU online/offline powerpc/numa: Print debug statements only when required powerpc/numa: convert printk to pr_xxx powerpc/numa: Drop dbg in favour of pr_debug powerpc/smp: Enable CACHE domain for shared processor powerpc/smp: Update cpu_core_map on all PowerPc systems ...
2021-09-02cpufreq: Remove ready() callbackViresh Kumar1-4/+0
This isn't used anymore, get rid of it. Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2021-09-02cpufreq: sh: Remove sh_cpufreq_cpu_ready()Viresh Kumar1-11/+0
The ->ready() callback is going away and since we don't do any important stuff in sh_cpufreq_cpu_ready(), remove it. Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2021-09-02cpufreq: acpi: Remove acpi_cpufreq_cpu_ready()Viresh Kumar1-11/+3
The ready() callback was implemented earlier for acpi-cpufreq driver as we wanted to use policy->cpuinfo.max_freq for which the policy was required to be verified. That is no longer the case and we can do the pr_warn() right from ->init() callback now. Remove acpi_cpufreq_cpu_ready(). Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2021-08-31Merge branch 'cpufreq/arm/linux-next' of ↵Rafael J. Wysocki10-54/+217
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm Pull ARM cpufreq driver changes for v5.15 from Viresh Kumar: "This contains: - Update cpufreq-dt blocklist with more platforms (Bjorn Andersson). - Allow freq changes from any CPU for qcom-hw driver (Taniya Das). - Add DSVS interrupt's support for qcom-hw driver (Thara Gopinath). - A new callback (->register_em()) to register EM at a more convenient point of time." * 'cpufreq/arm/linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: cpufreq: qcom-hw: Set dvfs_possible_from_any_cpu cpufreq driver flag cpufreq: blocklist more Qualcomm platforms in cpufreq-dt-platdev cpufreq: qcom-cpufreq-hw: Add dcvs interrupt support cpufreq: scmi: Use .register_em() to register with energy model cpufreq: vexpress: Use .register_em() to register with energy model cpufreq: scpi: Use .register_em() to register with energy model cpufreq: qcom-cpufreq-hw: Use .register_em() to register with energy model cpufreq: omap: Use .register_em() to register with energy model cpufreq: mediatek: Use .register_em() to register with energy model cpufreq: imx6q: Use .register_em() to register with energy model cpufreq: dt: Use .register_em() to register with energy model cpufreq: Add callback to register with energy model cpufreq: vexpress: Set CPUFREQ_IS_COOLING_DEV flag
2021-08-30cpufreq: qcom-hw: Set dvfs_possible_from_any_cpu cpufreq driver flagTaniya Das1-0/+1
As remote cpufreq updates are supported on QCOM platforms, set dvfs_possible_from_any_cpu cpufreq driver flag. Signed-off-by: Taniya Das <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2021-08-30cpufreq: blocklist more Qualcomm platforms in cpufreq-dt-platdevBjorn Andersson1-0/+4
The Qualcomm sa8155p, sm6350, sm8250 and sm8350 platforms also uses the qcom-cpufreq-hw driver, so add them to the cpufreq-dt-platdev driver's blocklist. Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2021-08-30cpufreq: qcom-cpufreq-hw: Add dcvs interrupt supportThara Gopinath1-0/+147
Add interrupt support to notify the kernel of h/w initiated frequency throttling by LMh. Convey this to scheduler via thermal presssure interface. Signed-off-by: Thara Gopinath <[email protected]> [Viresh: Added changes for arch_topology.c to fix build errors ] Signed-off-by: Viresh Kumar <[email protected]>
2021-08-30cpufreq: scmi: Use .register_em() to register with energy modelViresh Kumar1-23/+42
Set the newly added .register_em() callback to register with the EM after the cpufreq policy is properly initialized. Acked-by: Sudeep Holla <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2021-08-30cpufreq: vexpress: Use .register_em() to register with energy modelViresh Kumar1-2/+1
Set the newly added .register_em() callback with cpufreq_register_em_with_opp() to register with the EM core. Acked-by: Sudeep Holla <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2021-08-30cpufreq: scpi: Use .register_em() to register with energy modelViresh Kumar1-2/+1
Set the newly added .register_em() callback with cpufreq_register_em_with_opp() to register with the EM core. Acked-by: Sudeep Holla <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2021-08-25cpufreq: intel_pstate: Process HWP Guaranteed change notificationSrinivas Pandruvada1-0/+39
It is possible that HWP guaranteed ratio is changed in response to change in power and thermal limits. For example when Intel Speed Select performance profile is changed or there is change in TDP, hardware can send notifications. It is possible that the guaranteed ratio is increased. This creates an issue when turbo is disabled, as the old limits set in MSR_HWP_REQUEST are still lower and hardware will clip to older limits. This change enables HWP interrupt and process HWP interrupts. When guaranteed is changed, calls cpufreq_update_policy() so that driver callbacks are called to update to new HWP limits. This callback is called from a delayed workqueue of 10ms to avoid frequent updates. Signed-off-by: Srinivas Pandruvada <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2021-08-23Merge back cpufreq changes for v5.15.Rafael J. Wysocki6-14/+14
2021-08-17Merge branch 'cpufreq/arm/fixes' of ↵Rafael J. Wysocki3-2/+8
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm Pull ARM cpufreq fixes for v5.14 from Viresh Kumar: "This contains: - Addition of SoCs to blocklist for cpufreq-dt driver (Bjorn Andersson and Thara Gopinath). - Fix error path for scmi driver (Lukasz Luba). - Temporarily disable highest frequency for armada, its unsafe and breaks stuff." * 'cpufreq/arm/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: cpufreq: armada-37xx: forbid cpufreq for 1.2 GHz variant cpufreq: blocklist Qualcomm sm8150 in cpufreq-dt-platdev cpufreq: arm_scmi: Fix error path when allocation failed cpufreq: blacklist Qualcomm sc8180x in cpufreq-dt-platdev
2021-08-13cpufreq: powernv: Fix init_chip_info initialization in numa=offPratik R. Sampat1-2/+14
In the numa=off kernel command-line configuration init_chip_info() loops around the number of chips and attempts to copy the cpumask of that node which is NULL for all iterations after the first chip. Hence, store the cpu mask for each chip instead of derving cpumask from node while populating the "chips" struct array and copy that to the chips[i].mask Fixes: 053819e0bf84 ("cpufreq: powernv: Handle throttling due to Pmax capping at chip level") Cc: [email protected] # v4.3+ Reported-by: Shirisha Ganta <[email protected]> Signed-off-by: Pratik R. Sampat <[email protected]> Reviewed-by: Gautham R. Shenoy <[email protected]> [mpe: Rename goto label to out_free_chip_cpu_mask] Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-08-12cpufreq: qcom-cpufreq-hw: Use .register_em() to register with energy modelViresh Kumar1-2/+1
Set the newly added .register_em() callback with cpufreq_register_em_with_opp() to register with the EM core. Signed-off-by: Viresh Kumar <[email protected]>
2021-08-12cpufreq: omap: Use .register_em() to register with energy modelViresh Kumar1-1/+1
Set the newly added .register_em() callback with cpufreq_register_em_with_opp() to register with the EM core. Signed-off-by: Viresh Kumar <[email protected]>
2021-08-12cpufreq: mediatek: Use .register_em() to register with energy modelViresh Kumar1-2/+1
Set the newly added .register_em() callback with cpufreq_register_em_with_opp() to register with the EM core. Signed-off-by: Viresh Kumar <[email protected]>
2021-08-12cpufreq: imx6q: Use .register_em() to register with energy modelViresh Kumar1-1/+1
Set the newly added .register_em() callback with cpufreq_register_em_with_opp() to register with the EM core. Signed-off-by: Viresh Kumar <[email protected]>
2021-08-12cpufreq: dt: Use .register_em() to register with energy modelViresh Kumar1-2/+1
Set the newly added .register_em() callback with cpufreq_register_em_with_opp() to register with the EM core. Signed-off-by: Viresh Kumar <[email protected]>
2021-08-12cpufreq: Add callback to register with energy modelViresh Kumar1-0/+13
Many cpufreq drivers register with the energy model for each policy and do exactly the same thing. Follow the footsteps of thermal-cooling, to get it done from the cpufreq core itself. Provide a new callback, which will be called, if present, by the cpufreq core at the right moment (more on that in the code's comment). Also provide a generic implementation that uses dev_pm_opp_of_register_em(). This also allows us to register with the EM at a later point of time, compared to ->init(), from where the EM core can access cpufreq policy directly using cpufreq_cpu_get() type of helpers and perform other work, like marking few frequencies inefficient, this will be done separately. Reviewed-by: Quentin Perret <[email protected]> Reviewed-by: Lukasz Luba <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2021-08-12cpufreq: vexpress: Set CPUFREQ_IS_COOLING_DEV flagViresh Kumar1-19/+3
Reuse the cpufreq core's registration of cooling device by setting the CPUFREQ_IS_COOLING_DEV flag. Set this only if bL switcher isn't enabled. Signed-off-by: Viresh Kumar <[email protected]>
2021-08-09cpufreq: armada-37xx: forbid cpufreq for 1.2 GHz variantMarek Behún1-1/+5
The 1.2 GHz variant of the Armada 3720 SOC is unstable with DVFS: when the SOC boots, the WTMI firmware sets clocks and AVS values that work correctly with 1.2 GHz CPU frequency, but random crashes occur once cpufreq driver starts scaling. We do not know currently what is the reason: - it may be that the voltage value for L0 for 1.2 GHz variant provided by the vendor in the OTP is simply incorrect when scaling is used, - it may be that some delay is needed somewhere, - it may be something else. The most sane solution now seems to be to simply forbid the cpufreq driver on 1.2 GHz variant. Signed-off-by: Marek Behún <[email protected]> Fixes: 92ce45fb875d ("cpufreq: Add DVFS support for Armada 37xx") Signed-off-by: Viresh Kumar <[email protected]>
2021-08-05cpufreq: blocklist Qualcomm sm8150 in cpufreq-dt-platdevThara Gopinath1-0/+1
The Qualcomm sm8150 platform uses the qcom-cpufreq-hw driver, so add it to the cpufreq-dt-platdev driver's blocklist. Signed-off-by: Thara Gopinath <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2021-08-04cpufreq: Replace deprecated CPU-hotplug functionsSebastian Andrzej Siewior6-14/+14
The functions get_online_cpus() and put_online_cpus() have been deprecated during the CPU hotplug rework. They map directly to cpus_read_lock() and cpus_read_unlock(). Replace deprecated CPU-hotplug functions with the official version. The behavior remains unchanged. Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2021-08-04cpufreq: arm_scmi: Fix error path when allocation failedLukasz Luba1-1/+1
Stop the initialization when cpumask allocation failed and return an error. Fixes: 80a064dbd556 ("scmi-cpufreq: Get opp_shared_cpus from opp-v2 for EM") Signed-off-by: Lukasz Luba <[email protected]> Reviewed-by: Sudeep Holla <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2021-07-26cpufreq: blacklist Qualcomm sc8180x in cpufreq-dt-platdevBjorn Andersson1-0/+1
The Qualcomm SC8180x platform uses the qcom-cpufreq-hw driver, so it in the cpufreq-dt-platdev driver's blocklist. Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2021-07-13cpufreq: Fix fall-through warning for ClangGustavo A. R. Silva1-2/+0
In preparation to enable -Wimplicit-fallthrough for Clang, fix a fallthrough warning by simply dropping the empty default case at the bottom. Link: https://github.com/KSPP/linux/issues/115 Signed-off-by: Gustavo A. R. Silva <[email protected]>
2021-07-01Merge branch 'cpufreq/arm/linux-next' of ↵Rafael J. Wysocki5-31/+282
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm Pull ARM cpufreq updates for v5.14-rc1 from Viresh Kumar: "- Add frequency invariance support for CPPC driver again and related fixes/changes." - Minor changes/cleanups for Meditak driver (Fabien Parent and Seiya Wang), Qcom platform (Sibi Sankar), and SCMI driver (Christophe JAILLET). - New bindings for generic performance domains (Sudeep Holla). - Rename black/white-lists (Viresh Kumar)." * 'cpufreq/arm/linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: cpufreq: CPPC: Add support for frequency invariance arch_topology: Avoid use-after-free for scale_freq_data cpufreq: CPPC: Pass structure instance by reference cpufreq: CPPC: Fix potential memleak in cppc_cpufreq_cpu_init dt-bindings: cpufreq: update cpu type and clock name for MT8173 SoC clk: mediatek: remove deprecated CLK_INFRA_CA57SEL for MT8173 SoC cpufreq: dt: Rename black/white-lists cpufreq: scmi: Fix an error message cpufreq: mediatek: add support for mt8365 dt-bindings: dvfs: Add support for generic performance domains cpufreq: blacklist SC7280 in cpufreq-dt-platdev
2021-07-01Merge branch 'cpufreq/cppc-fie' into cpufreq/arm/linux-nextViresh Kumar8-136/+382
2021-07-01cpufreq: CPPC: Add support for frequency invarianceViresh Kumar2-13/+249
The Frequency Invariance Engine (FIE) is providing a frequency scaling correction factor that helps achieve more accurate load-tracking. Normally, this scaling factor can be obtained directly with the help of the cpufreq drivers as they know the exact frequency the hardware is running at. But that isn't the case for CPPC cpufreq driver. Another way of obtaining that is using the arch specific counter support, which is already present in kernel, but that hardware is optional for platforms. This patch updates the CPPC driver to register itself with the topology core to provide its own implementation (cppc_scale_freq_tick()) of topology_scale_freq_tick() which gets called by the scheduler on every tick. Note that the arch specific counters have higher priority than CPPC counters, if available, though the CPPC driver doesn't need to have any special handling for that. On an invocation of cppc_scale_freq_tick(), we schedule an irq work (since we reach here from hard-irq context), which then schedules a normal work item and cppc_scale_freq_workfn() updates the per_cpu arch_freq_scale variable based on the counter updates since the last tick. To allow platforms to disable this CPPC counter-based frequency invariance support, this is all done under CONFIG_ACPI_CPPC_CPUFREQ_FIE, which is enabled by default. This also exports sched_setattr_nocheck() as the CPPC driver can be built as a module. Cc: [email protected] Tested-by: Vincent Guittot <[email protected]> Reviewed-by: Ionela Voinescu <[email protected]> Tested-by: Qian Cai <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2021-07-01cpufreq: CPPC: Pass structure instance by referenceViresh Kumar1-8/+8
Don't pass structure instance by value, pass it by reference instead. Tested-by: Vincent Guittot <[email protected]> Reviewed-by: Ionela Voinescu <[email protected]> Tested-by: Qian Cai <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2021-07-01cpufreq: CPPC: Fix potential memleak in cppc_cpufreq_cpu_initViresh Kumar1-8/+20
It's a classic example of memleak, we allocate something, we fail and never free the resources. Make sure we free all resources on policy ->init() failures. Fixes: a28b2bfc099c ("cppc_cpufreq: replace per-cpu data array with a list") Tested-by: Vincent Guittot <[email protected]> Reviewed-by: Ionela Voinescu <[email protected]> Tested-by: Qian Cai <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2021-06-30cpufreq: Remove ->resolve_freq()Viresh Kumar1-13/+8
Commit e3c062360870 ("cpufreq: add cpufreq_driver_resolve_freq()") introduced this callback, back in 2016, for drivers that provide the ->target() callback. The kernel hasn't seen a single user of it in the past 5 years and it is not likely to be used any time soon. Remove it for now. Signed-off-by: Viresh Kumar <[email protected]> [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.