summaryrefslogtreecommitdiff
path: root/drivers/thermal/cpu_cooling.c
AgeCommit message (Collapse)Author
2020-01-27thermal/drivers/cpu_cooling: Rename to cpufreq_coolingDaniel Lezcano
As we introduced the idle injection cooling device called cpuidle_cooling, let's be consistent and rename the cpu_cooling to cpufreq_cooling as this one mitigates with OPPs changes. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org> Link: https://lore.kernel.org/r/20191219225317.17158-3-daniel.lezcano@linaro.org
2020-01-27thermal: cpu_cooling: Appease the kernel-doc deityAmit Kucheria
Describe the function parameter to fix the following warning with make W=1: linux.git/drivers/thermal/cpu_cooling.c:92: warning: Function parameter or member 'qos_req' not described in 'cpufreq_cooling_device' Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/ddb09e9728533c274edae7ff3da515b3cf7ef231.1574242756.git.amit.kucheria@linaro.org
2019-11-07thermal: cpu_cooling: Migrate to using the EM frameworkQuentin Perret
The newly introduced Energy Model framework manages power cost tables in a generic way. Moreover, it supports several types of models since the tables can come from DT or firmware (through SCMI) for example. On the other hand, the cpu_cooling subsystem manages its own power cost tables using only DT data. In order to avoid the duplication of data in the kernel, and in order to enable IPA with EMs coming from more than just DT, remove the private tables from cpu_cooling.c and migrate it to using the centralized EM framework. Doing so should have no visible functional impact for existing users of IPA since: - recent extenstions to the the PM_OPP infrastructure enable the registration of EMs in PM_EM using the DT property used by IPA; - the existing upstream cpufreq drivers marked with the 'CPUFREQ_IS_COOLING_DEV' flag all use the aforementioned PM_OPP infrastructure, which means they all support PM_EM. The only two exceptions are qoriq-cpufreq which doesn't in fact use an EM and scmi-cpufreq which doesn't use DT for power costs. For existing users of cpu_cooling, PM_EM tables will contain the exact same power values that IPA used to compute on its own until now. The only new dependency for them is to compile in CONFIG_ENERGY_MODEL. The case where the thermal subsystem is used without an Energy Model (cpufreq_cooling_ops) is handled by looking directly at CPUFreq's frequency table which is already a dependency for cpu_cooling.c anyway. Since the thermal framework expects the cooling states in a particular order, bail out whenever the CPUFreq table is unsorted, since that is fairly uncommon in general, and there are currently no users of cpu_cooling for this use-case. Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Quentin Perret <qperret@google.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20191030151451.7961-5-qperret@google.com
2019-11-07thermal: cpu_cooling: Make the power-related code depend on IPAQuentin Perret
The core CPU cooling infrastructure has power-related functions that have only one client: IPA. Since there can be no user of those functions if IPA is not compiled in, make sure to guard them with checks on CONFIG_THERMAL_GOV_POWER_ALLOCATOR to not waste space unnecessarily. Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Suggested-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Quentin Perret <qperret@google.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20191030151451.7961-4-qperret@google.com
2019-10-21cpufreq: Use per-policy frequency QoSRafael J. Wysocki
Replace the CPU device PM QoS used for the management of min and max frequency constraints in cpufreq (and its users) with per-policy frequency QoS to avoid problems with cpufreq policies covering more then one CPU. Namely, a cpufreq driver is registered with the subsys interface which calls cpufreq_add_dev() for each CPU, starting from CPU0, so currently the PM QoS notifiers are added to the first CPU in the policy (i.e. CPU0 in the majority of cases). In turn, when the cpufreq driver is unregistered, the subsys interface doing that calls cpufreq_remove_dev() for each CPU, starting from CPU0, and the PM QoS notifiers are only removed when cpufreq_remove_dev() is called for the last CPU in the policy, say CPUx, which as a rule is not CPU0 if the policy covers more than one CPU. Then, the PM QoS notifiers cannot be removed, because CPUx does not have them, and they are still there in the device PM QoS notifiers list of CPU0, which prevents new PM QoS notifiers from being registered for CPU0 on the next attempt to register the cpufreq driver. The same issue occurs when the first CPU in the policy goes offline before unregistering the driver. After this change it does not matter which CPU is the policy CPU at the driver registration time and whether or not it is online all the time, because the frequency QoS is per policy and not per CPU. Fixes: 67d874c3b2c6 ("cpufreq: Register notifiers with the PM QoS framework") Reported-by: Dmitry Osipenko <digetx@gmail.com> Tested-by: Dmitry Osipenko <digetx@gmail.com> Reported-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Diagnosed-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://lore.kernel.org/linux-pm/5ad2624194baa2f53acc1f1e627eb7684c577a19.1562210705.git.viresh.kumar@linaro.org/T/#md2d89e95906b8c91c15f582146173dce2e86e99f Link: https://lore.kernel.org/linux-pm/20191017094612.6tbkwoq4harsjcqv@vireshk-i7/T/#m30d48cc23b9a80467fbaa16e30f90b3828a5a29b Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-08-10thermal: cpu_cooling: Switch to QoS requests for freq limitsViresh Kumar
The cpufreq core now takes the min/max frequency constraints via QoS requests and the CPUFREQ_ADJUST notifier shall get removed later on. Switch over to using the QoS request for maximum frequency constraint for cpu_cooling driver. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> [ rjw: Subject ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-05-14thermal: cpu_cooling: Actually trace CPU load in thermal_power_cpu_get_powerMatthias Kaehlcke
The CPU load values passed to the thermal_power_cpu_get_power tracepoint are zero for all CPUs, unless, unless the thermal_power_cpu_limit tracepoint is enabled too: irq/41-rockchip-98 [000] .... 290.972410: thermal_power_cpu_get_power: cpus=0000000f freq=1800000 load={{0x0,0x0,0x0,0x0}} dynamic_power=4815 vs irq/41-rockchip-96 [000] .... 95.773585: thermal_power_cpu_get_power: cpus=0000000f freq=1800000 load={{0x56,0x64,0x64,0x5e}} dynamic_power=4959 irq/41-rockchip-96 [000] .... 95.773596: thermal_power_cpu_limit: cpus=0000000f freq=408000 cdev_state=10 power=416 There seems to be no good reason for omitting the CPU load information depending on another tracepoint. My guess is that the intention was to check whether thermal_power_cpu_get_power is (still) enabled, however 'load_cpu != NULL' already indicates that it was at least enabled when cpufreq_get_requested_power() was entered, there seems little gain from omitting the assignment if the tracepoint was just disabled, so just remove the check. Fixes: 6828a4711f99 ("thermal: add trace events to the power allocator governor") Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Javi Merino <javi.merino@kernel.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2019-05-14thermal/drivers/cpu_cooling: Remove pointless fieldDaniel Lezcano
The structure cpufreq_cooling_device provides a backpointer to the thermal device but this one is used for a trace and to unregister. For the trace, we don't really need this field and the unregister function as the same pointer passed as parameter. Remove it. Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2019-05-14thermal/drivers/cpu_cooling: Add Software Package Data Exchange (SPDX)Daniel Lezcano
For license auditing purpose, let's add the SPDX tag. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Philippe Ombredanne <pombredanne@nexb.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2019-05-14thermal/drivers/cpu_cooling: Fixup the header and copyrightDaniel Lezcano
The copyright format does not conform to the format requested by Linaro: https://wiki.linaro.org/Copyright Fix it. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2019-05-14thermal/drivers/cpu_cooling: Remove pointless test in power2state()Daniel Lezcano
When the static power computation was removed, the test with the power being negative was not removed. However, the substraction which was responsible of the negative value was removed and the variable is now an u32. A double reason to remove the test which does not make sense. Fixes: 84fe2cab48590 ("cpu_cooling: Drop static-power related stuff") Cc: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2019-03-18thermal: cpu_cooling: Remove unused cur_freq variableShaokun Zhang
The 'cur_freq' local variable became unused after commit 84fe2cab4859 ("cpu_cooling: Drop static-power related stuff"), let's remove it. Cc: Amit Daniel Kachhap <amit.kachhap@gmail.com> Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: Javi Merino <javi.merino@kernel.org> Cc: Zhang Rui <rui.zhang@intel.com> Cc: Eduardo Valentin <edubezval@gmail.com> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2019-02-05thermal: cpu_cooling: Clarify error messageAmit Kucheria
Make it clear that it is a failure if the cpufreq driver was unable to register as a cooling device. Makes it easier to find in logs and grepping for words like fail, err, warn. Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-12-07cpu_cooling: Drop static-power related stuffViresh Kumar
No one has used it for the last two and half years (since it was introduced by commit c36cf0717631 (thermal: cpu_cooling: implement the power cooling device API), get rid of it. Acked-by: Eduardo Valentin <edubezval@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-12-07cpu_cooling: Keep only one of_cpufreq*cooling_register() helperViresh Kumar
of_cpufreq_cooling_register() isn't used by anyone and so can be removed, but then we would be left with two routines: cpufreq_cooling_register() and of_cpufreq_power_cooling_register() that would look odd. Remove current implementation of of_cpufreq_cooling_register() and rename of_cpufreq_power_cooling_register() as of_cpufreq_cooling_register(). This simplifies lots of stuff. Acked-by: Eduardo Valentin <edubezval@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-12-07cpu_cooling: Remove unused cpufreq_power_cooling_register()Viresh Kumar
It isn't used by anyone, drop it. Acked-by: Eduardo Valentin <edubezval@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-12-07cpu_cooling: Make of_cpufreq_power_cooling_register() parse DTViresh Kumar
All the callers of of_cpufreq_power_cooling_register() have almost identical code and it makes more sense to move that code into the helper as its all about reading DT properties. This got rid of lot of redundant code. Acked-by: Eduardo Valentin <edubezval@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-10-31thermal: cpu_cooling: pr_err() strings should end with newlinesArvind Yadav
pr_err() messages should end with a new-line to avoid other messages being concatenated. Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Javi Merino <javi.merino@kernel.org> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-05-27thermal: cpu_cooling: Replace kmalloc with kmalloc_arrayViresh Kumar
Checkpatch reports following: WARNING: Prefer kmalloc_array over kmalloc with multiply + cpufreq_cdev->freq_table = kmalloc(sizeof(*cpufreq_cdev->freq_table) * i, Fix that. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-05-27thermal: cpu_cooling: Rearrange struct cpufreq_cooling_deviceViresh Kumar
This shrinks the size of the structure on arm64 by 8 bytes by avoiding padding of 4 bytes at two places. Also add missing doc comment for freq_table Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Tested-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-05-27thermal: cpu_cooling: 'freq' can't be zero in cpufreq_state2power()Viresh Kumar
The frequency table shouldn't have any zero frequency entries and so such a check isn't required. Though it would be better to make sure 'state' is within limits. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Tested-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-05-27thermal: cpu_cooling: don't store cpu_dev in cpufreq_cdevViresh Kumar
'cpu_dev' is used by only one function, get_static_power(), and it wouldn't be time consuming to get the cpu device structure within it. This would help removing cpu_dev from struct cpufreq_cooling_device. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Tested-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-05-27thermal: cpu_cooling: get_level() can't failViresh Kumar
The frequency passed to get_level() is returned by cpu_power_to_freq() and it is guaranteed that get_level() can't fail. Get rid of error code. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Tested-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-05-27thermal: cpu_cooling: create structure for idle time statsViresh Kumar
We keep two arrays for idle time stats and allocate memory for them separately. It would be much easier to follow if we create an array of idle stats structure instead and allocate it once. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Tested-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-05-27thermal: cpu_cooling: merge frequency and power tablesViresh Kumar
The cpu_cooling driver keeps two tables: - freq_table: table of frequencies in descending order, built from policy->freq_table. - power_table: table of frequencies and power in ascending order, built from OPP table. If the OPPs are used for the CPU device then both these tables are actually built using the OPP core and should have the same frequency entries. And there is no need to keep separate tables for this. Lets merge them both. Note that the new table is in descending order of frequencies and so the 'for' loops were required to be fixed at few places to make it work. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Tested-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-05-27thermal: cpu_cooling: get rid of 'allowed_cpus'Viresh Kumar
'allowed_cpus' is a copy of policy->related_cpus and can be replaced by it directly. At some places we are only concerned about online CPUs and policy->cpus can be used there. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Tested-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-05-27thermal: cpu_cooling: OPPs are registered for all CPUsViresh Kumar
The OPPs are registered for all CPUs of a cpufreq policy now and we don't need to run the loop in build_dyn_power_table(). Just check for the policy->cpu and we should be fine. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Tested-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-05-27thermal: cpu_cooling: store cpufreq policyViresh Kumar
The cpufreq policy can be used by the cpu_cooling driver, lets store it in the cpufreq_cooling_device structure. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Tested-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-05-27cpufreq: create cpufreq_table_count_valid_entries()Viresh Kumar
We need such a routine at two places already, lets create one. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Tested-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-05-27thermal: cpu_cooling: use cpufreq_policy to register cooling deviceViresh Kumar
The CPU cooling driver uses the cpufreq policy, to get clip_cpus, the frequency table, etc. Most of the callers of CPU cooling driver's registration routines have the cpufreq policy with them, but they only pass the policy->related_cpus cpumask. The __cpufreq_cooling_register() routine then gets the policy by itself and uses it. It would be much better if the callers can pass the policy instead directly. This also fixes a basic design flaw, where the policy can be freed while the CPU cooling driver is still active. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Tested-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-05-27thermal: cpu_cooling: get rid of a variable in cpufreq_set_cur_state()Viresh Kumar
'cpu' is used at only one place and there is no need to keep a separate variable for it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Tested-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-05-27thermal: cpu_cooling: remove cpufreq_cooling_get_level()Viresh Kumar
There is only one user of cpufreq_cooling_get_level() and that already has pointer to the cpufreq_cdev structure. It can directly call get_level() instead and we can get rid of cpufreq_cooling_get_level(). Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Tested-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-05-27thermal: cpu_cooling: replace cool_dev with cdevViresh Kumar
Objects of "struct thermal_cooling_device" are named a bit inconsistently. Lets use cdev everywhere. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Tested-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-05-27thermal: cpu_cooling: Name cpufreq cooling devices as cpufreq_cdevViresh Kumar
Objects of "struct cpufreq_cooling_device" are named a bit inconsistently. Lets use cpufreq_cdev everywhere. Also note that the lists containing such devices is renamed similarly too. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Tested-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-05-27thermal: cpu_cooling: rearrange globalsViresh Kumar
Just to make it look better. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Tested-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-05-27thermal: cpu_cooling: Avoid accessing potentially freed structuresViresh Kumar
After the lock is dropped, it is possible that the cpufreq_dev gets freed before we call get_level() and that can cause kernel to crash. Drop the lock after we are done using the structure. Cc: 4.2+ <stable@vger.kernel.org> # 4.2+ Fixes: 02373d7c69b4 ("thermal: cpu_cooling: fix lockdep problems in cpu_cooling") Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Tested-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-03-13thermal: cpu_cooling: Check OPP for errorsViresh Kumar
It is possible for dev_pm_opp_find_freq_exact() to return errors. It was all fine earlier as dev_pm_opp_get_voltage() had a check within it to check for invalid OPPs, but dev_pm_opp_put() doesn't have any similar checks and the callers need to make sure OPP is valid before calling them. Also update the later dev_warn_ratelimited() to not print the error message as the OPP is guaranteed to be valid now. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2017-03-13thermal: cpu_cooling: Replace dev_warn with dev_errViresh Kumar
There isn't much the user can do on seeing these warnings, as the hardware is actually okay. dev_err suits much better here. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2017-03-13thermal: Fix potential deadlock in cpu_coolingMatthew Wilcox
cooling_list_lock is covering not just cpufreq_dev_count, but also the calls to cpufreq_register_notifier() and cpufreq_unregister_notifier(). Since cooling_list_lock is also used within cpufreq_thermal_notifier(), lockdep reports a potential deadlock. Fix it by testing the condition under cooling_list_lock and dropping the lock before calling cpufreq_register_notifier(). And variable cpufreq_dev_count is removed at the same time, because it's no longer needed after the fix. Fixes: ae606089621e ("thermal: convert cpu_cooling to use an IDA") Reported-and-Tested-by: Russell King <linux@armlinux.org.uk> Signed-off-by: Matthew Wilcox <mawilcox@microsoft.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2017-03-01Merge branch 'next' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux Pull thermal management updates from Zhang Rui: - add thermal driver for R-Car Gen3 thermal sensors. - add thermal driver for ZTE' zx2967 family thermal sensors. - convert thermal ID allocation from IDR to IDA. - fix a possible NULL dereference in imx thermal driver. - fix a ti-soc-thermal driver dependency issue so that critical thermal control is still available when CPU_THERMAL is not defined. - update binding information for QorIQ thermal driver. - a couple of cleanups in thermal core, intel_powerclamp, exynos, dra752-thermal, mtk-thermal driver. * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux: powerpc/mpc85xx: Update TMU device tree node for T1023/T1024 powerpc/mpc85xx: Update TMU device tree node for T1040/T1042 dt-bindings: Update QorIQ TMU thermal bindings thermal: mtk_thermal: Staticise a number of data variables thermal: arm: dra752: Remove all TSHUT related definitions thermal: arm: dra752: Remove TSHUT configuration thermal: ti-soc-thermal: Remove CPU_THERMAL Dependency from TI_THERMAL thermal: imx: Fix possible NULL dereference. thermal: exynos: Remove parsing unused samsung,tmu_cal_mode property thermal: zx2967: add thermal driver for ZTE's zx2967 family thermal: use cpumask_var_t for on-stack cpu masks dt: bindings: add documentation for zx2967 family thermal sensor thermal/intel_powerclamp: Remove set-but-not-used variables thermal: rcar_gen3_thermal: Add R-Car Gen3 thermal driver thermal: rcar_gen3_thermal: Document the R-Car Gen3 thermal: convert devfreq_cooling to use an IDA thermal: convert cpu_cooling to use an IDA thermal: convert clock cooling to use an IDA thermal core: convert ID allocation to IDA
2017-02-22Merge branches 'thermal-core', 'thermal-soc', 'thermal-intel' and ↵Zhang Rui
'ida-conversion' into next
2017-02-10thermal: use cpumask_var_t for on-stack cpu masksArnd Bergmann
Putting a bare cpumask structure on the stack produces a warning on large SMP configurations: drivers/thermal/cpu_cooling.c: In function 'cpufreq_state2power': drivers/thermal/cpu_cooling.c:644:1: warning: the frame size of 1056 bytes is larger than 1024 bytes [-Wframe-larger-than=] drivers/thermal/cpu_cooling.c: In function '__cpufreq_cooling_register': drivers/thermal/cpu_cooling.c:898:1: warning: the frame size of 1104 bytes is larger than 1024 bytes [-Wframe-larger-than=] The recommended workaround is to use cpumask_var_t, which behaves just like a normal cpu mask in most cases, but turns into a dynamic allocation when CONFIG_CPUMASK_OFFSTACK is set. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2017-01-30PM / OPP: Update OPP users to put referenceViresh Kumar
This patch updates dev_pm_opp_find_freq_*() routines to get a reference to the OPPs returned by them. Also updates the users of dev_pm_opp_find_freq_*() routines to call dev_pm_opp_put() after they are done using the OPPs. As it is guaranteed the that OPPs wouldn't get freed while being used, the RCU read side locking present with the users isn't required anymore. Drop it as well. This patch also updates all users of devfreq_recommended_opp() which was returning an OPP received from the OPP core. Note that some of the OPP core routines have gained rcu_read_{lock|unlock}() calls, as those still use RCU specific APIs within them. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> [Devfreq] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-01-04thermal: convert cpu_cooling to use an IDAMatthew Wilcox
thermal cpu cooling does not use the ability to look up pointers by ID, so convert it from using an IDR to the more space-efficient IDA. The cooling_cpufreq_lock was being used to protect cpufreq_dev_count as well as the IDR. Rather than keep the mutex to protect a single integer, I expanded the scope of cooling_list_lock to also cover cpufreq_dev_count. We could also convert cpufreq_dev_count into an atomic. Signed-off-by: Matthew Wilcox <mawilcox@microsoft.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-09-27thermal: cpu_cooling: Fix wrong comment call function nameHugh Kang
The last_load is updated not cpufreq_get_actual_power() function call but cpufreq_get_requested_power() function call. Signed-off-by: Inhyuk Kang <hugh.kang@lge.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Javi Merino <javi.merino@arm.com> Acked-by: Javi Merino <javi.merino@arm.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-08-19thermal: cpu_cooling: Fix NULL dereference in cpufreq_state2powerBrendan Jackman
Currently all CPU cooling devices share a `struct thermal_cooling_device_ops` instance. The thermal core uses the presence of functions in this struct to determine if a cooling device has a power model (see cdev_is_power_actor). cpu_cooling.c adds the power model functions to the shared struct when a device is registered with a power model. Therefore, if a CPU cooling device is registered using [of_]cpufreq_power_cooling_register, _all_ devices will be determined to have a power model, including any registered with [of_]cpufreq_cooling_register. This can result in cpufreq_state2power being called on a device where dyn_power_table is NULL. With this commit, instead of having a shared thermal_cooling_device_ops which is mutated, we have two versions: one with the power functions and one without. Signed-off-by: Brendan Jackman <brendan.jackman@arm.com> Cc: Amit Daniel Kachhap <amit.kachhap@gmail.com> Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: Javi Merino <javi.merino@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Javi Merino <javi.merino@arm.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-06-13Merge back earlier cpufreq changes for v4.8.Rafael J. Wysocki
2016-06-09cpufreq: Remove cpufreq_frequency_get_table()Viresh Kumar
Most of the callers of cpufreq_frequency_get_table() already have the pointer to a valid 'policy' structure and they don't really need to go through the per-cpu variable first and then a check to validate the frequency, in order to find the freq-table for the policy. Directly use the policy->freq_table field instead for them. Only one user of that API is left after above changes, cpu_cooling.c and it accesses the freq_table in a racy way as the policy can get freed in between. Fix it by using cpufreq_cpu_get() properly. Since there are no more users of cpufreq_frequency_get_table() left, get rid of it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Javi Merino <javi.merino@arm.com> (cpu_cooling.c) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-06-01thermal: cpu_cooling: fix improper order during initializationLukasz Luba
The freq_table array is not populated before calling thermal_of_cooling_register. The code which populates the freq table was introduced in commit f6859014. This should be done before registering new thermal cooling device. The log shows effects of this wrong decision. [ 2.172614] cpu cpu1: Failed to get voltage for frequency 1984518656000: -34 [ 2.220863] cpu cpu0: Failed to get voltage for frequency 1984524416000: -34 Cc: <stable@vger.kernel.org> # 3.19+ Fixes: f6859014c7e7 ("thermal: cpu_cooling: Store frequencies in descending order") Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Acked-by: Javi Merino <javi.merino@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-02-11thermal: cpu_cooling: fix out of bounds access in time_in_idleJavi Merino
In __cpufreq_cooling_register() we allocate the arrays for time_in_idle and time_in_idle_timestamp to be as big as the number of cpus in this cpufreq device. However, in get_load() we access this array using the cpu number as index, which can result in an out of bound access. Index time_in_idle{,_timestamp} using the index in the cpufreq_device's allowed_cpus mask, as we do for the load_cpu array in cpufreq_get_requested_power() Reported-by: Nicolas Boichat <drinkcat@chromium.org> Cc: Amit Daniel Kachhap <amit.kachhap@gmail.com> Cc: Zhang Rui <rui.zhang@intel.com> Cc: Eduardo Valentin <edubezval@gmail.com> Tested-by: Nicolas Boichat <drinkcat@chromium.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Javi Merino <javi.merino@arm.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>