summaryrefslogtreecommitdiff
path: root/drivers/cpufreq
AgeCommit message (Collapse)AuthorFilesLines
2022-06-03Merge tag 'arm-multiplatform-5.19-2' of ↵Linus Torvalds2-33/+38
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull more ARM multiplatform updates from Arnd Bergmann: "The second part of the multiplatform changes now converts the Intel/Marvell PXA platform along with the rest. The patches went through several rebases before the merge window as bugs were found, so they remained separate. This has to touch a lot of drivers, in particular the touchscreen, pcmcia, sound and clk bits, to detach the driver files from the platform and board specific header files" * tag 'arm-multiplatform-5.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (48 commits) ARM: pxa/mmp: remove traces of plat-pxa ARM: pxa: convert to multiplatform ARM: pxa/sa1100: move I/O space to PCI_IOBASE ARM: pxa: remove support for MTD_XIP ARM: pxa: move mach/*.h to mach-pxa/ ARM: PXA: fix multi-cpu build of xsc3 ARM: pxa: move plat-pxa to drivers/soc/ ARM: mmp: rename pxa_register_device ARM: mmp: remove tavorevb board support ARM: pxa: remove unused mach/bitfield.h ARM: pxa: move clk register definitions to driver ARM: pxa: move smemc register access from clk to platform cpufreq: pxa3: move clk register access to clk driver ARM: pxa: remove get_clk_frequency_khz() ARM: pxa: pcmcia: move smemc configuration back to arch ASoC: pxa: i2s: use normal MMIO accessors ASoC: pxa: ac97: use normal MMIO accessors ASoC: pxa: use pdev resource for FIFO regs Input: wm97xx - get rid of irq_enable method in wm97xx_mach_ops Input: wm97xx - switch to using threaded IRQ ...
2022-05-30cpufreq: CPPC: Fix unused-function warningPierre Gondois1-9/+8
Building the cppc_cpufreq driver with for arm64 with CONFIG_ENERGY_MODEL=n triggers the following warnings: drivers/cpufreq/cppc_cpufreq.c:550:12: error: ‘cppc_get_cpu_cost’ defined but not used [-Werror=unused-function] 550 | static int cppc_get_cpu_cost(struct device *cpu_dev, unsigned long KHz, | ^~~~~~~~~~~~~~~~~ drivers/cpufreq/cppc_cpufreq.c:481:12: error: ‘cppc_get_cpu_power’ defined but not used [-Werror=unused-function] 481 | static int cppc_get_cpu_power(struct device *cpu_dev, | ^~~~~~~~~~~~~~~~~~ Move the Energy Model related functions into specific guards. This allows to fix the warning and prevent doing extra work when the Energy Model is not present. Fixes: 740fcdc2c20e ("cpufreq: CPPC: Register EM based on efficiency class information") Reported-by: Shaokun Zhang <zhangshaokun@hisilicon.com> Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Tested-by: Shaokun Zhang <zhangshaokun@hisilicon.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-30cpufreq: CPPC: Fix build error without CONFIG_ACPI_CPPC_CPUFREQ_FIEZheng Bin1-1/+2
If CONFIG_ACPI_CPPC_CPUFREQ_FIE is not set, building fails: drivers/cpufreq/cppc_cpufreq.c: In function ‘populate_efficiency_class’: drivers/cpufreq/cppc_cpufreq.c:584:2: error: ‘cppc_cpufreq_driver’ undeclared (first use in this function); did you mean ‘cpufreq_driver’? cppc_cpufreq_driver.register_em = cppc_cpufreq_register_em; ^~~~~~~~~~~~~~~~~~~ cpufreq_driver Make declare of cppc_cpufreq_driver out of CONFIG_ACPI_CPPC_CPUFREQ_FIE to fix this. Fixes: 740fcdc2c20e ("cpufreq: CPPC: Register EM based on efficiency class information") Signed-off-by: Zheng Bin <zhengbin13@huawei.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-25Merge tag 'cpufreq-arm-5.19-rc1' of ↵Rafael J. Wysocki2-259/+623
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm Pull ARM cpufreq updates for 5.19-rc1 from Viresh Kumar: - Tegra234 cpufreq support (Sumit Gupta). - Mediatek cleanups and enhancements (Wan Jiabing, Rex-BC Chen, and Jia-Wei Chang). * tag 'cpufreq-arm-5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: (21 commits) cpufreq: mediatek: Add support for MT8186 cpufreq: mediatek: Link CCI device to CPU dt-bindings: cpufreq: mediatek: Add MediaTek CCI property cpufreq: mediatek: Fix potential deadlock problem in mtk_cpufreq_set_target cpufreq: mediatek: Add opp notification support cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking() cpufreq: mediatek: Move voltage limits to platform data cpufreq: mediatek: Unregister platform device on exit cpufreq: mediatek: Fix NULL pointer dereference in mediatek-cpufreq cpufreq: mediatek: Make sram regulator optional cpufreq: mediatek: Record previous target vproc value cpufreq: mediatek: Replace old_* with pre_* cpufreq: mediatek: Use device print to show logs cpufreq: mediatek: Enable clocks and regulators cpufreq: mediatek: Remove unused headers cpufreq: mediatek: Cleanup variables and error handling in mtk_cpu_dvfs_info_init() cpufreq: mediatek: Use module_init and add module_exit arm64: tegra: add node for tegra234 cpufreq cpufreq: tegra194: Add support for Tegra234 cpufreq: tegra194: add soc data to support multiple soc ...
2022-05-19cpufreq: CPPC: Enable dvfs_possible_from_any_cpuPierre Gondois1-0/+1
The communication mean of the _CPC desired performance can be PCC, System Memory, System IO, or Functional Fixed Hardware (FFH). PCC, SystemMemory and SystemIo address spaces are available from any CPU. Thus, dvfs_possible_from_any_cpu should be enabled in such case. For FFH, let the FFH implementation do smp_call_function_*() calls. Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19cpufreq: CPPC: Enable fast_switchPierre Gondois1-0/+24
The communication mean of the _CPC desired performance can be PCC, System Memory, System IO, or Functional Fixed Hardware. commit b7898fda5bc7 ("cpufreq: Support for fast frequency switching") fast_switching is 'for switching CPU frequencies from interrupt context'. Writes to SystemMemory and SystemIo are fast and suitable this. This is not the case for PCC and might not be the case for FFH. Enable fast_switching for the cppc_cpufreq driver in above cases. Add cppc_allow_fast_switch() to check the desired performance register address space and set fast_switching accordingly. Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-17cpufreq: make interface functions and lock holding state clearSchspa Shi1-3/+3
cpufreq_offline() calls offline() and exit() under the policy rwsem But they are called outside the rwsem in cpufreq_online(). Make cpufreq_online() call offline() and exit() as well as online() and init() under the policy rwsem to achieve a clear lock relationship. All of the init() and online() implementations in the tree only initialize the policy object without attempting to acquire the policy rwsem and they won't call cpufreq APIs attempting to acquire it. Signed-off-by: Schspa Shi <schspa@gmail.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-17cpufreq: Abort show()/store() for half-initialized policiesSchspa Shi1-4/+7
If policy initialization fails after the sysfs files are created, there is a possibility to end up running show()/store() callbacks for half-initialized policies, which may have unpredictable outcomes. Abort show()/store() in such a case by making sure the policy is active. Also dectivate the policy on such failures. Signed-off-by: Schspa Shi <schspa@gmail.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-12cpufreq: Rearrange locking in cpufreq_remove_dev()Rafael J. Wysocki1-7/+14
Currently, cpufreq_remove_dev() invokes the ->exit() driver callback without holding the policy rwsem which is inconsistent with what happens if ->exit() is invoked directly from cpufreq_offline(). It also manipulates the real_cpus mask and removes the CPU device symlink without holding the policy rwsem, but cpufreq_offline() holds the rwsem around the modifications thereof. For consistency, modify cpufreq_remove_dev() to hold the policy rwsem until the ->exit() callback has been called (or it has been determined that it is not necessary to call it). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-05-12cpufreq: Split cpufreq_offline()Rafael J. Wysocki1-14/+19
Split the "core" part running under the policy rwsem out of cpufreq_offline() to allow the locking in cpufreq_remove_dev() to be rearranged more easily. As a side-effect this eliminates the unlock label that's not needed any more. No expected functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-05-12cpufreq: Reorganize checks in cpufreq_offline()Rafael J. Wysocki1-12/+12
Notice that cpufreq_offline() only needs to check policy_is_inactive() once and rearrange the code in there to make that happen. No expected functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-05-12cpufreq: mediatek: Add support for MT8186Jia-Wei Chang1-0/+10
The platform data of MT8186 is different from previous MediaTek SoCs, so we add a new compatible and platform data for it. Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com> Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-05-12cpufreq: mediatek: Link CCI device to CPURex-BC Chen1-1/+81
In some MediaTek SoCs, like MT8183, CPU and CCI share the same power supplies. Cpufreq needs to check if CCI devfreq exists and wait until CCI devfreq ready before scaling frequency. Before CCI devfreq is ready, we record the voltage when booting to kernel and use the max(cpu target voltage, booting voltage) to prevent cpufreq adjust to the lower voltage which will cause the CCI crash because of high frequency and low voltage. - Add is_ccifreq_ready() to link CCI device to CPI, and CPU will start DVFS when CCI is ready. - Add platform data for MT8183. Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com> Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-05-11cpufreq: Clear real_cpus mask from remove_cpu_dev_symlink()Viresh Kumar1-4/+4
add_cpu_dev_symlink() is responsible for setting the CPUs in the real_cpus mask, the reverse of which should be done from remove_cpu_dev_symlink() to make it look clean and avoid any breakage later on. Move the call to clear the mask to remove_cpu_dev_symlink(). Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-11cpufreq: intel_pstate: Support Sapphire Rapids OOB modeSrinivas Pandruvada1-0/+1
Prevent intel_pstate to load when OOB (Out Of Band) P-states mode is enabled in Sapphire Rapids. The OOB identifying bits are same as the prior generation CPUs like Ice Lake servers. So, also add Sapphire Rapids to intel_pstate_cpu_oob_ids list. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-10cpufreq: mediatek: Fix potential deadlock problem in mtk_cpufreq_set_targetWan Jiabing1-2/+4
Fix following coccichek error: ./drivers/cpufreq/mediatek-cpufreq.c:199:2-8: preceding lock on line ./drivers/cpufreq/mediatek-cpufreq.c:208:2-8: preceding lock on line mutex_lock is acquired but not released before return. Use 'goto out' to help releasing the mutex_lock. Fixes: c210063b40ac ("cpufreq: mediatek: Add opp notification support") Signed-off-by: Wan Jiabing <wanjiabing@vivo.com> Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-05-09Revert "cpufreq: Fix possible race in cpufreq online error path"Viresh Kumar1-3/+2
This reverts commit f346e96267cd76175d6c201b40f770c0116a8a04. The commit tried to fix a possible real bug but it made it even worse. The fix was simply buggy as now an error out to out_offline_policy or out_exit_policy will try to release a semaphore which was never taken in the first place. This works fine only if we failed late, i.e. via out_destroy_policy. Fixes: f346e96267cd ("cpufreq: Fix possible race in cpufreq online error path") Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-07cpufreq: pxa3: move clk register access to clk driverArnd Bergmann2-31/+36
The driver needs some low-level register access for setting the core and bus frequencies. These registers are owned by the clk driver, so move the low-level access into that driver with a slightly higher-level interface and avoid any machine header file dependencies. Cc: Michael Turquette <mturquette@baylibre.com> Cc: Stephen Boyd <sboyd@kernel.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Cc: linux-clk@vger.kernel.org Cc: linux-pm@vger.kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-05-07ARM: pxa: remove get_clk_frequency_khz()Arnd Bergmann1-2/+0
get_clk_frequency_khz() is not a proper name for a global function, and there is only one caller. Convert viper to use the properly namespaced pxa25x_get_clk_frequency_khz() and remove the other references. Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> Cc: linux-pm@vger.kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-05-06cpufreq: CPPC: Register EM based on efficiency class informationPierre Gondois1-0/+144
Performance states and energy consumption values are not advertised in ACPI. In the GicC structure of the MADT table, the "Processor Power Efficiency Class field" (called efficiency class from now) allows to describe the relative energy efficiency of CPUs. To leverage the EM and EAS, the CPPC driver creates a set of artificial performance states and registers them in the Energy Model (EM), such as: - Every 20 capacity unit, a performance state is created. - The energy cost of each performance state gradually increases. No power value is generated as only the cost is used in the EM. During task placement, a task can raise the frequency of its whole pd. This can make EAS place a task on a pd with CPUs that are individually less energy efficient. As cost values are artificial, and to place tasks on CPUs with the lower efficiency class, a gap in cost values is generated for adjacent efficiency classes. E.g.: - efficiency class = 0, capacity is in [0-1024], so cost values are in [0: 51] (one performance state every 20 capacity unit) - efficiency class = 1, capacity is in [0-1024], cost values are in [1*gap+0: 1*gap+51]. The value of the cost gap is chosen to absorb a the energy of 4 CPUs at their maximum capacity. This means that between: 1- a pd of 4 CPUs, each of them being used at almost their full capacity. Their efficiency class is N. 2- a CPU using almost none of its capacity. Its efficiency class is N+1 EAS will choose the first option. This patch also populates the (struct cpufreq_driver).register_em callback if the valid efficiency_class ACPI values are provided. Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-06cpufreq: CPPC: Add per_cpu efficiency_classPierre Gondois1-0/+42
In ACPI, describing power efficiency of CPUs can be done through the following arm specific field: ACPI 6.4, s5.2.12.14 'GIC CPU Interface (GICC) Structure', 'Processor Power Efficiency Class field': Describes the relative power efficiency of the associated pro- cessor. Lower efficiency class numbers are more efficient than higher ones (e.g. efficiency class 0 should be treated as more efficient than efficiency class 1). However, absolute values of this number have no meaning: 2 isn’t necessarily half as efficient as 1. The efficiency_class field is stored in the GicC structure of the ACPI MADT table and it's currently supported in Linux for arm64 only. Thus, this new functionality is introduced for arm64 only. To allow the cppc_cpufreq driver to know and preprocess the efficiency_class values of all the CPUs, add a per_cpu efficiency_class variable to store them. At least 2 different efficiency classes must be present, otherwise there is no use in creating an Energy Model. The efficiency_class values are squeezed in [0:#efficiency_class-1] while conserving the order. For instance, efficiency classes of: [111, 212, 250] will be mapped to: [0 (was 111), 1 (was 212), 2 (was 250)]. Each policy being independently registered in the driver, populating the per_cpu efficiency_class is done only once at the driver initialization. This prevents from having each policy re-searching the efficiency_class values of other CPUs. The EM will be registered in a following patch. The patch also exports acpi_cpu_get_madt_gicc() to fetch the GicC structure of the ACPI MADT table for each CPU. Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-06Merge Energy Model material for 5.19 to satisfy dependencies.Rafael J. Wysocki2-4/+4
2022-05-06cpufreq: Avoid unnecessary frequency updates due to mismatchViresh Kumar1-0/+11
For some platforms, the frequency returned by hardware may be slightly different from what is provided in the frequency table. For example, hardware may return 499 MHz instead of 500 MHz. In such cases it is better to avoid getting into unnecessary frequency updates, as we may end up switching policy->cur between the two and sending unnecessary pre/post update notifications, etc. This patch has chosen allows the hardware frequency and table frequency to deviate by 1 MHz for now, we may want to increase it a bit later on if someone still complains. Reported-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Jia-wei Chang <jia-wei.chang@mediatek.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-06cpufreq: mediatek: Add opp notification supportRex-BC Chen1-8/+82
From this opp notifier, cpufreq should listen to opp notification and do proper actions when receiving events of disable and voltage adjustment. One of the user for this opp notifier is MediaTek SVS. The MediaTek Smart Voltage Scaling (SVS) is a hardware which calculates suitable SVS bank voltages to OPP voltage table. Signed-off-by: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com> Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com> Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> [ Viresh: Renamed opp_freq as current_freq and moved its initialization ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-05-06cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()Jia-Wei Chang1-96/+51
Because the difference of sram and proc should in a range of min_volt_shift and max_volt_shift. We need to adjust the sram and proc step by step. We replace VOLT_TOL (voltage tolerance) with the platform data and update the logic to determine the voltage boundary and invoking regulator_set_voltage. - Use 'sram_min_volt' and 'sram_max_volt' to determine the voltage boundary of sram regulator. - Use (sram_min_volt - min_volt_shift) and 'proc_max_volt' to determine the voltage boundary of vproc regulator. Moreover, to prevent infinite loop when tracking voltage, we calculate the maximum value for each platform data. We assume min voltage is 0 and tracking target voltage using min_volt_shift for each iteration. The retry_max is 3 times of expeted iteration count. Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com> Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-05-06cpufreq: mediatek: Move voltage limits to platform dataRex-BC Chen1-26/+58
Voltages and shifts are defined as macros originally. There are different requirements of these values for each MediaTek SoCs. Therefore, we add the platform data and move these values into it. Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com> Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-05-06cpufreq: mediatek: Unregister platform device on exitRex-BC Chen1-4/+6
We register the platform device when driver inits. However, we do not unregister it when driver exits. To resolve this, we declare the platform data to be a global static variable and rename it to be "cpufreq_pdev". With this global variable, we can do platform_device_unregister() when driver exits. Fixes: 501c574f4e3a ("cpufreq: mediatek: Add support of cpufreq to MT2701/MT7623 SoC") Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com> [ Viresh: Commit log and Subject ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-05-05Merge back earlier cpufreq changes for 5.19.Rafael J. Wysocki9-14/+21
2022-04-27cpufreq: mediatek: Fix NULL pointer dereference in mediatek-cpufreqWan Jiabing1-2/+2
Fix following coccicheck error: drivers/cpufreq/mediatek-cpufreq.c:464:16-23: ERROR: info is NULL but dereferenced. Use pr_err instead of dev_err to avoid dereferring a NULL pointer. Fixes: f52b16ba9fe4 ("cpufreq: mediatek: Use device print to show logs") Signed-off-by: Wan Jiabing <wanjiabing@vivo.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-04-26cpufreq: mediatek: Make sram regulator optionalJia-Wei Chang1-1/+1
For some MediaTek SoCs, like MT8186, it's possible that the sram regulator is shared between CPU and CCI. We hope regulator framework can return error for error handling rather than a dummy handler from regulator_get api. Therefore, we choose to use regulator_get_optional. Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com> Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-04-26cpufreq: mediatek: Record previous target vproc valueJia-Wei Chang1-4/+16
We found the buck voltage may not be exactly the same with what we set because CPU may share the same buck with other module. Therefore, we need to record the previous desired value instead of reading it from regulators. Signed-off-by: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com> Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com> Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-04-26cpufreq: mediatek: Replace old_* with pre_*Rex-BC Chen1-42/+42
To make driver more readable, replace old_* with pre_*. Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-04-26cpufreq: mediatek: Use device print to show logsRex-BC Chen1-26/+28
- Replace pr_* with dev_* to show logs. - Remove usage of __func__. Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-04-26cpufreq: mediatek: Enable clocks and regulatorsJia-Wei Chang1-5/+45
We need to enable regulators so that the max and min requested values will be recorded. The intermediate clock is not always enabled by CCF in different projects, so we should enable it in the cpufreq driver. Signed-off-by: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com> Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com> Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-04-26cpufreq: mediatek: Remove unused headersJia-Wei Chang1-2/+0
Remove unused headers. Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-04-26cpufreq: mediatek: Cleanup variables and error handling in ↵Jia-Wei Chang1-55/+34
mtk_cpu_dvfs_info_init() - Remove several unnecessary varaibles in mtk_cpu_dvfs_info_init(). - Unify error message format and use dev_err_probe() if possible. Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com> Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-04-26cpufreq: mediatek: Use module_init and add module_exitJia-Wei Chang1-1/+7
- Use module_init instead of device_initcall. - Add a function for module_exit to unregister driver. Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-04-26cpufreq: tegra194: Add support for Tegra234Sumit Gupta1-0/+104
This patch adds driver support for Tegra234 cpufreq. Tegra234 has per core MMIO registers instead of system registers for cpu frequency requests and to read the counters for re-constructing the cpu frequency. Also, MPIDR affinity info in Tegra234 is different from Tegra194. Added ops hooks and soc data for Tegra234. This will help to easily add variants of Tegra234 and future SoC's which use similar logic to {get|set} the cpu frequency. Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-04-26cpufreq: tegra194: add soc data to support multiple socSumit Gupta1-37/+105
Adding SoC data and ops to support multiple SoC's in same driver. Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-04-26cpufreq: qcom-cpufreq-hw: Clear dcvs interruptsVladimir Zapolskiy1-0/+8
It's noted that dcvs interrupts are not self-clearing, thus an interrupt handler runs constantly, which leads to a severe regression in runtime. To fix the problem an explicit write to clear interrupt register is required, note that on OSM platforms the register may not be present. Fixes: 275157b367f4 ("cpufreq: qcom-cpufreq-hw: Add dcvs interrupt support") Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-04-25cpufreq: fix memory leak in sun50i_cpufreq_nvmem_probeXiaobing Luo1-1/+3
-------------------------------------------- unreferenced object 0xffff000010742a00 (size 128): comm "swapper/0", pid 1, jiffies 4294902015 (age 1187.652s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000b4dfebaa>] __kmalloc+0x338/0x474 [<00000000d6e716db>] sun50i_cpufreq_nvmem_probe+0xc4/0x36c [<000000007d6082a0>] platform_probe+0x98/0x11c [<00000000c990f549>] really_probe+0x234/0x5a0 [<000000002d9fecc6>] __driver_probe_device+0x194/0x224 [<00000000cf0b94fa>] driver_probe_device+0x64/0x13c [<00000000f238e4cf>] __device_attach_driver+0xf8/0x180 [<000000006720e418>] bus_for_each_drv+0xf8/0x160 [<00000000df4f14f6>] __device_attach+0x174/0x29c [<00000000782002fb>] device_initial_probe+0x20/0x30 [<00000000c2681b06>] bus_probe_device+0xfc/0x110 [<00000000964cf3bd>] device_add+0x5f0/0xcd0 [<000000004b9264e3>] platform_device_add+0x198/0x390 [<00000000fa82a9d0>] platform_device_register_full+0x178/0x210 [<000000009a5daf13>] sun50i_cpufreq_init+0xf8/0x168 [<000000000377cc7c>] do_one_initcall+0xe4/0x570 -------------------------------------------- if sun50i_cpufreq_get_efuse failed, then opp_tables leak. Fixes: f328584f7bff ("cpufreq: Add sun50i nvmem based CPU scaling driver") Signed-off-by: Xiaobing Luo <luoxiaobing0926@gmail.com> Reviewed-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-04-22cpufreq: Fix possible race in cpufreq online error pathSchspa Shi1-2/+3
When cpufreq online fails, the policy->cpus mask is not cleared and policy->rwsem is released too early, so the driver can be invoked via the cpuinfo_cur_freq sysfs attribute while its ->offline() or ->exit() callbacks are being run. Take policy->clk as an example: static int cpufreq_online(unsigned int cpu) { ... // policy->cpus != 0 at this time down_write(&policy->rwsem); ret = cpufreq_add_dev_interface(policy); up_write(&policy->rwsem); return 0; out_destroy_policy: for_each_cpu(j, policy->real_cpus) remove_cpu_dev_symlink(policy, get_cpu_device(j)); up_write(&policy->rwsem); ... out_exit_policy: if (cpufreq_driver->exit) cpufreq_driver->exit(policy); clk_put(policy->clk); // policy->clk is a wild pointer ... ^ | Another process access __cpufreq_get cpufreq_verify_current_freq cpufreq_generic_get // acces wild pointer of policy->clk; | | out_offline_policy: | cpufreq_policy_free(policy); | // deleted here, and will wait for no body reference cpufreq_policy_put_kobj(policy); } Address this by modifying cpufreq_online() to release policy->rwsem in the error path after the driver callbacks have run and to clear policy->cpus before releasing the semaphore. Fixes: 7106e02baed4 ("cpufreq: release policy->rwsem on error") Signed-off-by: Schspa Shi <schspa@gmail.com> [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-04-19ARM: pxa: split up mach/hardware.hArnd Bergmann2-0/+2
The mach/hardware.h is included in lots of places, and it provides three different things on pxa: - the cpu_is_pxa* macros - an indirect inclusion of mach/addr-map.h - the __REG() and io_pv2() helper macros Split it up into separate <linux/soc/pxa/cpu.h> and mach/pxa-regs.h headers, then change all the files that use mach/hardware.h to include the exact set of those three headers that they actually need, allowing for further more targeted cleanup. linux/soc/pxa/cpu.h can remain permanently exported and is now in a global location along with similar headers. pxa-regs.h and addr-map.h are only used in a very small number of drivers now and can be moved to arch/arm/mach-pxa/ directly when those drivers are to pass the necessary data as resources. Cc: Michael Turquette <mturquette@baylibre.com> Cc: Stephen Boyd <sboyd@kernel.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com> Cc: Pavel Machek <pavel@ucw.cz> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Guenter Roeck <linux@roeck-us.net> Acked-by: Mark Brown <broonie@kernel.org> Cc: linux-clk@vger.kernel.org Cc: linux-pm@vger.kernel.org Cc: linux-input@vger.kernel.org Cc: linux-leds@vger.kernel.org Cc: linux-mmc@vger.kernel.org Cc: linux-mtd@lists.infradead.org Cc: linux-rtc@vger.kernel.org Cc: linux-usb@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linux-fbdev@vger.kernel.org Cc: linux-watchdog@vger.kernel.org Cc: alsa-devel@alsa-project.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-04-13cpufreq: intel_pstate: Handle no_turbo in frequency invarianceChen Yu1-0/+1
Problem statement: Once the user has disabled turbo frequency by # echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo the cfs_rq's util_avg becomes quite small when compared with CPU capacity. Step to reproduce: # echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo # ./x86_cpuload --count 1 --start 3 --timeout 100 --busy 99 would launch 1 thread and bind it to CPU3, lasting for 100 seconds, with a CPU utilization of 99%. [1] top result: %Cpu3 : 98.4 us, 0.0 sy, 0.0 ni, 1.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st check util_avg: cat /sys/kernel/debug/sched/debug | grep "cfs_rq\[3\]" -A 20 | grep util_avg .util_avg : 611 So the util_avg/cpu capacity is 611/1024, which is much smaller than 98.4% shown in the top result. This might impact some logic in the scheduler. For example, group_is_overloaded() would compare the group_capacity and group_util in the sched group, to check if this sched group is overloaded or not. With this gap, even when there is a nearly 100% workload, the sched group will not be regarded as overloaded. Besides group_is_overloaded(), there are also other victims. There is a ongoing work that aims to optimize the task wakeup in a LLC domain. The main idea is to stop searching idle CPUs if the sched domain is overloaded[2]. This proposal also relies on the util_avg/CPU capacity to decide whether the LLC domain is overloaded. Analysis: CPU frequency invariance has caused this difference. In summary, the util_sum of cfs rq would decay quite fast when the CPU is in idle, when the CPU frequency invariance is enabled. The detail is as followed: As depicted in update_rq_clock_pelt(), when the frequency invariance is enabled, there would be two clock variables on each rq, clock_task and clock_pelt: The clock_pelt scales the time to reflect the effective amount of computation done during the running delta time but then syncs back to clock_task when rq is idle. absolute time | 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15|16 @ max frequency ------******---------------******--------------- @ half frequency ------************---------************--------- clock pelt | 1| 2| 3| 4| 7| 8| 9| 10| 11|14|15|16 The fast decay of util_sum during idle is due to: 1. rq->clock_pelt is always behind rq->clock_task 2. rq->last_update is updated to rq->clock_pelt' after invoking ___update_load_sum() 3. Then the CPU becomes idle, the rq->clock_pelt' would be suddenly increased a lot to rq->clock_task 4. Enters ___update_load_sum() again, the idle period is calculated by rq->clock_task - rq->last_update, AKA, rq->clock_task - rq->clock_pelt'. The lower the CPU frequency is, the larger the delta = rq->clock_task - rq->clock_pelt' will be. Since the idle period will be used to decay the util_sum only, the util_sum drops significantly during idle period. Proposal: This symptom is not only caused by disabling turbo frequency, but it would also appear if the user limits the max frequency at runtime. Because, if the frequency is always lower than the max frequency, CPU frequency invariance would decay the util_sum quite fast during idle. As some end users would disable turbo after boot up, this patch aims to present this symptom and deals with turbo scenarios for now. It might be ideal if CPU frequency invariance is aware of the max CPU frequency (user specified) at runtime in the future. Link: https://github.com/yu-chen-surf/x86_cpuload.git #1 Link: https://lore.kernel.org/lkml/20220310005228.11737-1-yu.c.chen@intel.com/ #2 Signed-off-by: Chen Yu <yu.c.chen@intel.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Giovanni Gherdovich <ggherdovich@suse.cz> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-04-13cpufreq: Prepare cleanup of powerpc's asm/prom.hChristophe Leroy5-5/+3
powerpc's asm/prom.h brings some headers that it doesn't need itself. In order to clean it up, first add missing headers in users of asm/prom.h Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-04-13PM: EM: Change the order of arguments in the .active_power() callbackLukasz Luba2-4/+4
The .active_power() callback passes the device pointer when it's called. Aligned with a convetion present in other subsystems and pass the 'dev' as a first argument. It looks more cleaner. Adjust all affected drivers which implement that API callback. Suggested-by: Ionela Voinescu <ionela.voinescu@arm.com> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Reviewed-by: Ionela Voinescu <ionela.voinescu@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-04-13cpufreq: governor: Use kobject release() method to free dbs_dataKevin Hao2-7/+14
The struct dbs_data embeds a struct gov_attr_set and the struct gov_attr_set embeds a kobject. Since every kobject must have a release() method and we can't use kfree() to free it directly, so introduce cpufreq_dbs_data_release() to release the dbs_data via the kobject::release() method. This fixes the calltrace like below: ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34 WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100 Modules linked in: CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536 Hardware name: Marvell OcteonTX CN96XX board (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : debug_print_object+0xb8/0x100 lr : debug_print_object+0xb8/0x100 sp : ffff80001dfcf9a0 x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000 x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210 x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118 x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000 x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8 x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14 x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0 x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001 x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040 Call trace: debug_print_object+0xb8/0x100 __debug_check_no_obj_freed+0x1d0/0x25c debug_check_no_obj_freed+0x24/0xa0 kfree+0x11c/0x440 cpufreq_dbs_governor_exit+0xa8/0xac cpufreq_exit_governor+0x44/0x90 cpufreq_set_policy+0x29c/0x570 store_scaling_governor+0x110/0x154 store+0xb0/0xe0 sysfs_kf_write+0x58/0x84 kernfs_fop_write_iter+0x12c/0x1c0 new_sync_write+0xf0/0x18c vfs_write+0x1cc/0x220 ksys_write+0x74/0x100 __arm64_sys_write+0x28/0x3c invoke_syscall.constprop.0+0x58/0xf0 do_el0_svc+0x70/0x170 el0_svc+0x54/0x190 el0t_64_sync_handler+0xa4/0x130 el0t_64_sync+0x1a0/0x1a4 irq event stamp: 189006 hardirqs last enabled at (189005): [<ffff8000080849d0>] finish_task_switch.isra.0+0xe0/0x2c0 hardirqs last disabled at (189006): [<ffff8000090667a4>] el1_dbg+0x24/0xa0 softirqs last enabled at (188966): [<ffff8000080106d0>] __do_softirq+0x4b0/0x6a0 softirqs last disabled at (188957): [<ffff80000804a618>] __irq_exit_rcu+0x108/0x1a4 [ rjw: Because can be freed by the gov_attr_set_put() in cpufreq_dbs_governor_exit() now, it is also necessary to put the invocation of the governor ->exit() callback into the new cpufreq_dbs_data_release() function. ] Fixes: c4435630361d ("cpufreq: governor: New sysfs show/store callbacks for governor tunables") Signed-off-by: Kevin Hao <haokexin@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-04-04cpufreq: qcom-cpufreq-hw: Fix throttle frequency value on EPSS platformsVladimir Zapolskiy1-6/+11
On QCOM platforms with EPSS flavour of cpufreq IP a throttled frequency is obtained from another register REG_DOMAIN_STATE, thus the helper function qcom_lmh_get_throttle_freq() should be modified accordingly, as for now it returns gibberish since .reg_current_vote is unset for EPSS hardware. To exclude a hardcoded magic number 19200 it is replaced by "xo" clock rate in KHz. Fixes: 275157b367f4 ("cpufreq: qcom-cpufreq-hw: Add dcvs interrupt support") Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-04-04cpufreq: qcom-hw: provide online/offline operationsDmitry Baryshkov1-2/+26
Provide lightweight online and offline operations. This saves us from parsing and tearing down the OPP tables each time the CPU is put online or offline. Tested-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-04-04cpufreq: qcom-hw: fix the opp entries refcountingDmitry Baryshkov1-4/+10
The qcom_lmh_dcvs_notify() will get the dev_pm_opp instance for throttling, but will not put it, ending up with leaking a reference count and the following backtrace when putting the CPU offline. Correctly put the reference count of the returned opp instance. [ 84.418025] ------------[ cut here ]------------ [ 84.422770] WARNING: CPU: 7 PID: 43 at drivers/opp/core.c:1396 _opp_table_kref_release+0x188/0x190 [ 84.431966] Modules linked in: [ 84.435106] CPU: 7 PID: 43 Comm: cpuhp/7 Tainted: G S 5.17.0-rc6-00388-g7cf3c0d89c44-dirty #721 [ 84.451631] pstate: 82400005 (Nzcv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--) [ 84.458781] pc : _opp_table_kref_release+0x188/0x190 [ 84.463878] lr : _opp_table_kref_release+0x78/0x190 [ 84.468885] sp : ffff80000841bc70 [ 84.472294] x29: ffff80000841bc70 x28: ffff6664afe3d000 x27: ffff1db6729e5908 [ 84.479621] x26: 0000000000000000 x25: 0000000000000000 x24: ffff1db6729e58e0 [ 84.486946] x23: ffff8000080a5000 x22: ffff1db40aad80e0 x21: ffff1db4002fec80 [ 84.494277] x20: ffff1db40aad8000 x19: ffffb751c3186300 x18: ffffffffffffffff [ 84.501603] x17: 5300326563697665 x16: 645f676e696c6f6f x15: 00001186c1df5448 [ 84.508928] x14: 00000000000002e9 x13: 0000000000000000 x12: 0000000000000000 [ 84.516256] x11: ffffb751c3186368 x10: ffffb751c39a2a70 x9 : 0000000000000000 [ 84.523585] x8 : ffff1db4008edf00 x7 : ffffb751c328c000 x6 : 0000000000000001 [ 84.530916] x5 : 0000000000040000 x4 : 0000000000000001 x3 : ffff1db4008edf00 [ 84.538247] x2 : 0000000000000000 x1 : ffff1db400aa6100 x0 : ffff1db40aad80d0 [ 84.545579] Call trace: [ 84.548101] _opp_table_kref_release+0x188/0x190 [ 84.552842] dev_pm_opp_remove_all_dynamic+0x8c/0xc0 [ 84.557949] qcom_cpufreq_hw_cpu_exit+0x30/0xdc [ 84.562608] cpufreq_offline.isra.0+0x1b4/0x1d8 [ 84.567270] cpuhp_cpufreq_offline+0x10/0x6c [ 84.571663] cpuhp_invoke_callback+0x16c/0x2b0 [ 84.576231] cpuhp_thread_fun+0x190/0x250 [ 84.580353] smpboot_thread_fn+0x12c/0x230 [ 84.584568] kthread+0xfc/0x100 [ 84.587810] ret_from_fork+0x10/0x20 [ 84.591490] irq event stamp: 3482 [ 84.594901] hardirqs last enabled at (3481): [<ffffb751c13c3db0>] call_rcu+0x39c/0x50c [ 84.603119] hardirqs last disabled at (3482): [<ffffb751c236b518>] el1_dbg+0x24/0x8c [ 84.611074] softirqs last enabled at (310): [<ffffb751c1290410>] _stext+0x410/0x588 [ 84.619028] softirqs last disabled at (305): [<ffffb751c131bf68>] __irq_exit_rcu+0x158/0x174 [ 84.627691] ---[ end trace 0000000000000000 ]--- Fixes: 275157b367f4 ("cpufreq: qcom-cpufreq-hw: Add dcvs interrupt support") Reported-by: kernel test robot <lkp@intel.com> Tested-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>