2019-05-27 14:55:06 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
* processor_thermal.c - Passive cooling submodule of the ACPI processor driver
|
|
|
|
*
|
|
|
|
* Copyright (C) 2001, 2002 Andy Grover <andrew.grover@intel.com>
|
|
|
|
* Copyright (C) 2001, 2002 Paul Diefenbaugh <paul.s.diefenbaugh@intel.com>
|
|
|
|
* Copyright (C) 2004 Dominik Brodowski <linux@brodo.de>
|
|
|
|
* Copyright (C) 2004 Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
|
|
|
|
* - Added processor hotplug support
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/cpufreq.h>
|
2013-12-03 08:49:16 +08:00
|
|
|
#include <linux/acpi.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <acpi/processor.h>
|
2016-12-25 03:46:01 +08:00
|
|
|
#include <linux/uaccess.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2009-07-29 04:45:54 +08:00
|
|
|
#define PREFIX "ACPI: "
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
#define ACPI_PROCESSOR_CLASS "processor"
|
|
|
|
#define _COMPONENT ACPI_PROCESSOR_COMPONENT
|
2007-02-13 11:42:12 +08:00
|
|
|
ACPI_MODULE_NAME("processor_thermal");
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
#ifdef CONFIG_CPU_FREQ
|
|
|
|
|
|
|
|
/* If a passive cooling situation is detected, primarily CPUfreq is used, as it
|
|
|
|
* offers (in most cases) voltage scaling in addition to frequency scaling, and
|
|
|
|
* thus a cubic (instead of linear) reduction of energy. Also, we allow for
|
|
|
|
* _any_ cpufreq driver and not only the acpi-cpufreq driver.
|
|
|
|
*/
|
|
|
|
|
2008-01-17 15:51:23 +08:00
|
|
|
#define CPUFREQ_THERMAL_MIN_STEP 0
|
|
|
|
#define CPUFREQ_THERMAL_MAX_STEP 3
|
|
|
|
|
2008-03-06 00:31:29 +08:00
|
|
|
static DEFINE_PER_CPU(unsigned int, cpufreq_thermal_reduction_pctg);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2012-02-07 00:17:11 +08:00
|
|
|
#define reduction_pctg(cpu) \
|
|
|
|
per_cpu(cpufreq_thermal_reduction_pctg, phys_package_first_cpu(cpu))
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Emulate "per package data" using per cpu data (which should really be
|
|
|
|
* provided elsewhere)
|
|
|
|
*
|
|
|
|
* Note we can lose a CPU on cpu hotunplug, in this case we forget the state
|
|
|
|
* temporarily. Fortunately that's not a big issue here (I hope)
|
|
|
|
*/
|
|
|
|
static int phys_package_first_cpu(int cpu)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
int id = topology_physical_package_id(cpu);
|
|
|
|
|
|
|
|
for_each_online_cpu(i)
|
|
|
|
if (topology_physical_package_id(i) == id)
|
|
|
|
return i;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
static int cpu_has_cpufreq(unsigned int cpu)
|
|
|
|
{
|
|
|
|
struct cpufreq_policy policy;
|
2019-08-28 16:50:13 +08:00
|
|
|
if (!acpi_processor_cpufreq_init || cpufreq_get_policy(&policy, cpu))
|
2005-12-21 14:29:00 +08:00
|
|
|
return 0;
|
|
|
|
return 1;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2008-01-17 15:51:23 +08:00
|
|
|
static int cpufreq_get_max_state(unsigned int cpu)
|
|
|
|
{
|
|
|
|
if (!cpu_has_cpufreq(cpu))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return CPUFREQ_THERMAL_MAX_STEP;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int cpufreq_get_cur_state(unsigned int cpu)
|
|
|
|
{
|
|
|
|
if (!cpu_has_cpufreq(cpu))
|
|
|
|
return 0;
|
|
|
|
|
2012-02-07 00:17:11 +08:00
|
|
|
return reduction_pctg(cpu);
|
2008-01-17 15:51:23 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int cpufreq_set_cur_state(unsigned int cpu, int state)
|
|
|
|
{
|
2019-08-28 16:50:13 +08:00
|
|
|
struct cpufreq_policy *policy;
|
|
|
|
struct acpi_processor *pr;
|
|
|
|
unsigned long max_freq;
|
|
|
|
int i, ret;
|
2012-02-07 00:17:11 +08:00
|
|
|
|
2008-01-17 15:51:23 +08:00
|
|
|
if (!cpu_has_cpufreq(cpu))
|
|
|
|
return 0;
|
|
|
|
|
2012-02-07 00:17:11 +08:00
|
|
|
reduction_pctg(cpu) = state;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Update all the CPUs in the same package because they all
|
|
|
|
* contribute to the temperature and often share the same
|
|
|
|
* frequency.
|
|
|
|
*/
|
|
|
|
for_each_online_cpu(i) {
|
2019-08-28 16:50:13 +08:00
|
|
|
if (topology_physical_package_id(i) !=
|
2012-02-07 00:17:11 +08:00
|
|
|
topology_physical_package_id(cpu))
|
2019-08-28 16:50:13 +08:00
|
|
|
continue;
|
|
|
|
|
|
|
|
pr = per_cpu(processors, i);
|
|
|
|
|
cpufreq: Use per-policy frequency QoS
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-10-16 18:47:06 +08:00
|
|
|
if (unlikely(!freq_qos_request_active(&pr->thermal_req)))
|
2019-08-28 16:50:13 +08:00
|
|
|
continue;
|
|
|
|
|
|
|
|
policy = cpufreq_cpu_get(i);
|
|
|
|
if (!policy)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
max_freq = (policy->cpuinfo.max_freq * (100 - reduction_pctg(i) * 20)) / 100;
|
|
|
|
|
|
|
|
cpufreq_cpu_put(policy);
|
|
|
|
|
cpufreq: Use per-policy frequency QoS
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-10-16 18:47:06 +08:00
|
|
|
ret = freq_qos_update_request(&pr->thermal_req, max_freq);
|
2019-08-28 16:50:13 +08:00
|
|
|
if (ret < 0) {
|
|
|
|
pr_warn("Failed to update thermal freq constraint: CPU%d (%d)\n",
|
|
|
|
pr->id, ret);
|
|
|
|
}
|
2012-02-07 00:17:11 +08:00
|
|
|
}
|
2008-01-17 15:51:23 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
cpufreq: Use per-policy frequency QoS
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-10-16 18:47:06 +08:00
|
|
|
void acpi_thermal_cpufreq_init(struct cpufreq_policy *policy)
|
2005-08-05 12:44:28 +08:00
|
|
|
{
|
cpufreq: Use per-policy frequency QoS
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-10-16 18:47:06 +08:00
|
|
|
int cpu = policy->cpu;
|
2019-08-28 16:50:13 +08:00
|
|
|
struct acpi_processor *pr = per_cpu(processors, cpu);
|
|
|
|
int ret;
|
|
|
|
|
2019-10-16 01:35:20 +08:00
|
|
|
if (!pr)
|
|
|
|
return;
|
|
|
|
|
cpufreq: Use per-policy frequency QoS
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-10-16 18:47:06 +08:00
|
|
|
ret = freq_qos_add_request(&policy->constraints, &pr->thermal_req,
|
|
|
|
FREQ_QOS_MAX, INT_MAX);
|
2019-10-16 01:35:20 +08:00
|
|
|
if (ret < 0)
|
2019-08-28 16:50:13 +08:00
|
|
|
pr_err("Failed to add freq constraint for CPU%d (%d)\n", cpu,
|
|
|
|
ret);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
cpufreq: Use per-policy frequency QoS
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-10-16 18:47:06 +08:00
|
|
|
void acpi_thermal_cpufreq_exit(struct cpufreq_policy *policy)
|
2005-08-05 12:44:28 +08:00
|
|
|
{
|
cpufreq: Use per-policy frequency QoS
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-10-16 18:47:06 +08:00
|
|
|
struct acpi_processor *pr = per_cpu(processors, policy->cpu);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2019-10-16 01:35:20 +08:00
|
|
|
if (pr)
|
cpufreq: Use per-policy frequency QoS
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-10-16 18:47:06 +08:00
|
|
|
freq_qos_remove_request(&pr->thermal_req);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2005-08-05 12:44:28 +08:00
|
|
|
#else /* ! CONFIG_CPU_FREQ */
|
2008-01-17 15:51:23 +08:00
|
|
|
static int cpufreq_get_max_state(unsigned int cpu)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int cpufreq_get_cur_state(unsigned int cpu)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int cpufreq_set_cur_state(unsigned int cpu, int state)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
#endif
|
|
|
|
|
2013-12-06 02:14:16 +08:00
|
|
|
/* thermal cooling device callbacks */
|
2008-01-17 15:51:23 +08:00
|
|
|
static int acpi_processor_max_state(struct acpi_processor *pr)
|
|
|
|
{
|
|
|
|
int max_state = 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* There exists four states according to
|
2013-12-06 02:14:16 +08:00
|
|
|
* cpufreq_thermal_reduction_pctg. 0, 1, 2, 3
|
2008-01-17 15:51:23 +08:00
|
|
|
*/
|
|
|
|
max_state += cpufreq_get_max_state(pr->id);
|
|
|
|
if (pr->flags.throttling)
|
|
|
|
max_state += (pr->throttling.state_count -1);
|
|
|
|
|
|
|
|
return max_state;
|
|
|
|
}
|
|
|
|
static int
|
2008-11-28 01:48:13 +08:00
|
|
|
processor_get_max_state(struct thermal_cooling_device *cdev,
|
|
|
|
unsigned long *state)
|
2008-01-17 15:51:23 +08:00
|
|
|
{
|
|
|
|
struct acpi_device *device = cdev->devdata;
|
2013-03-25 18:50:06 +08:00
|
|
|
struct acpi_processor *pr;
|
2008-01-17 15:51:23 +08:00
|
|
|
|
2013-03-25 18:50:06 +08:00
|
|
|
if (!device)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
pr = acpi_driver_data(device);
|
|
|
|
if (!pr)
|
2008-01-17 15:51:23 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
2008-11-28 01:48:13 +08:00
|
|
|
*state = acpi_processor_max_state(pr);
|
|
|
|
return 0;
|
2008-01-17 15:51:23 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2008-11-28 01:48:13 +08:00
|
|
|
processor_get_cur_state(struct thermal_cooling_device *cdev,
|
|
|
|
unsigned long *cur_state)
|
2008-01-17 15:51:23 +08:00
|
|
|
{
|
|
|
|
struct acpi_device *device = cdev->devdata;
|
2013-03-25 18:50:06 +08:00
|
|
|
struct acpi_processor *pr;
|
2008-01-17 15:51:23 +08:00
|
|
|
|
2013-03-25 18:50:06 +08:00
|
|
|
if (!device)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
pr = acpi_driver_data(device);
|
|
|
|
if (!pr)
|
2008-01-17 15:51:23 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
2008-11-28 01:48:13 +08:00
|
|
|
*cur_state = cpufreq_get_cur_state(pr->id);
|
2008-01-17 15:51:23 +08:00
|
|
|
if (pr->flags.throttling)
|
2008-11-28 01:48:13 +08:00
|
|
|
*cur_state += pr->throttling.state;
|
|
|
|
return 0;
|
2008-01-17 15:51:23 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2008-11-28 01:48:13 +08:00
|
|
|
processor_set_cur_state(struct thermal_cooling_device *cdev,
|
|
|
|
unsigned long state)
|
2008-01-17 15:51:23 +08:00
|
|
|
{
|
|
|
|
struct acpi_device *device = cdev->devdata;
|
2013-03-25 18:50:06 +08:00
|
|
|
struct acpi_processor *pr;
|
2008-01-17 15:51:23 +08:00
|
|
|
int result = 0;
|
|
|
|
int max_pstate;
|
|
|
|
|
2013-03-25 18:50:06 +08:00
|
|
|
if (!device)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
pr = acpi_driver_data(device);
|
|
|
|
if (!pr)
|
2008-01-17 15:51:23 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
max_pstate = cpufreq_get_max_state(pr->id);
|
|
|
|
|
|
|
|
if (state > acpi_processor_max_state(pr))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (state <= max_pstate) {
|
|
|
|
if (pr->flags.throttling && pr->throttling.state)
|
2009-08-27 05:29:29 +08:00
|
|
|
result = acpi_processor_set_throttling(pr, 0, false);
|
2008-01-17 15:51:23 +08:00
|
|
|
cpufreq_set_cur_state(pr->id, state);
|
|
|
|
} else {
|
|
|
|
cpufreq_set_cur_state(pr->id, max_pstate);
|
|
|
|
result = acpi_processor_set_throttling(pr,
|
2009-08-27 05:29:29 +08:00
|
|
|
state - max_pstate, false);
|
2008-01-17 15:51:23 +08:00
|
|
|
}
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
2011-06-26 01:07:52 +08:00
|
|
|
const struct thermal_cooling_device_ops processor_cooling_ops = {
|
2008-01-17 15:51:23 +08:00
|
|
|
.get_max_state = processor_get_max_state,
|
|
|
|
.get_cur_state = processor_get_cur_state,
|
|
|
|
.set_cur_state = processor_set_cur_state,
|
|
|
|
};
|