2019-05-27 06:55:02 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2007-07-20 19:39:22 +00:00
|
|
|
/*
|
|
|
|
* pmi backend for the cbe_cpufreq driver
|
|
|
|
*
|
|
|
|
* (C) Copyright IBM Deutschland Entwicklung GmbH 2005-2007
|
|
|
|
*
|
|
|
|
* Author: Christian Krafft <krafft@de.ibm.com>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/types.h>
|
|
|
|
#include <linux/timer.h>
|
2016-03-27 22:08:17 +00:00
|
|
|
#include <linux/init.h>
|
2007-11-13 17:10:58 +00:00
|
|
|
#include <linux/of_platform.h>
|
2019-07-05 10:19:48 +00:00
|
|
|
#include <linux/pm_qos.h>
|
2007-11-13 17:10:58 +00:00
|
|
|
|
2007-07-20 19:39:22 +00:00
|
|
|
#include <asm/processor.h>
|
|
|
|
#include <asm/prom.h>
|
|
|
|
#include <asm/pmi.h>
|
2007-10-04 05:40:42 +00:00
|
|
|
#include <asm/cell-regs.h>
|
2007-07-20 19:39:22 +00:00
|
|
|
|
|
|
|
#ifdef DEBUG
|
|
|
|
#include <asm/time.h>
|
|
|
|
#endif
|
|
|
|
|
2013-03-25 05:50:23 +00:00
|
|
|
#include "ppc_cbe_cpufreq.h"
|
2007-07-20 19:39:22 +00:00
|
|
|
|
|
|
|
bool cbe_cpufreq_has_pmi = false;
|
|
|
|
EXPORT_SYMBOL_GPL(cbe_cpufreq_has_pmi);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* hardware specific functions
|
|
|
|
*/
|
|
|
|
|
|
|
|
int cbe_cpufreq_set_pmode_pmi(int cpu, unsigned int pmode)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
pmi_message_t pmi_msg;
|
|
|
|
#ifdef DEBUG
|
|
|
|
long time;
|
|
|
|
#endif
|
|
|
|
pmi_msg.type = PMI_TYPE_FREQ_CHANGE;
|
|
|
|
pmi_msg.data1 = cbe_cpu_to_node(cpu);
|
|
|
|
pmi_msg.data2 = pmode;
|
|
|
|
|
|
|
|
#ifdef DEBUG
|
|
|
|
time = jiffies;
|
|
|
|
#endif
|
|
|
|
pmi_send_message(pmi_msg);
|
|
|
|
|
|
|
|
#ifdef DEBUG
|
|
|
|
time = jiffies - time;
|
|
|
|
time = jiffies_to_msecs(time);
|
|
|
|
pr_debug("had to wait %lu ms for a transition using " \
|
|
|
|
"PMI\n", time);
|
|
|
|
#endif
|
|
|
|
ret = pmi_msg.data2;
|
|
|
|
pr_debug("PMI returned slow mode %d\n", ret);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(cbe_cpufreq_set_pmode_pmi);
|
|
|
|
|
|
|
|
|
|
|
|
static void cbe_cpufreq_handle_pmi(pmi_message_t pmi_msg)
|
|
|
|
{
|
2019-07-05 10:19:48 +00:00
|
|
|
struct cpufreq_policy *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 10:47:06 +00:00
|
|
|
struct freq_qos_request *req;
|
2007-07-20 19:39:22 +00:00
|
|
|
u8 node, slow_mode;
|
2019-07-05 10:19:48 +00:00
|
|
|
int cpu, ret;
|
2007-07-20 19:39:22 +00:00
|
|
|
|
|
|
|
BUG_ON(pmi_msg.type != PMI_TYPE_FREQ_CHANGE);
|
|
|
|
|
|
|
|
node = pmi_msg.data1;
|
|
|
|
slow_mode = pmi_msg.data2;
|
|
|
|
|
2019-07-05 10:19:48 +00:00
|
|
|
cpu = cbe_node_to_cpu(node);
|
2007-07-20 19:39:22 +00:00
|
|
|
|
|
|
|
pr_debug("cbe_handle_pmi: node: %d max_freq: %d\n", node, slow_mode);
|
|
|
|
|
2019-07-05 10:19:48 +00:00
|
|
|
policy = cpufreq_cpu_get(cpu);
|
|
|
|
if (!policy) {
|
|
|
|
pr_warn("cpufreq policy not found cpu%d\n", cpu);
|
|
|
|
return;
|
|
|
|
}
|
2007-07-20 19:39:22 +00:00
|
|
|
|
2019-07-05 10:19:48 +00:00
|
|
|
req = policy->driver_data;
|
2007-07-20 19:39:22 +00: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 10:47:06 +00:00
|
|
|
ret = freq_qos_update_request(req,
|
2019-07-05 10:19:48 +00:00
|
|
|
policy->freq_table[slow_mode].frequency);
|
|
|
|
if (ret < 0)
|
|
|
|
pr_warn("Failed to update freq constraint: %d\n", ret);
|
|
|
|
else
|
|
|
|
pr_debug("limiting node %d to slow mode %d\n", node, slow_mode);
|
2007-07-20 19:39:22 +00:00
|
|
|
|
2019-07-05 10:19:48 +00:00
|
|
|
cpufreq_cpu_put(policy);
|
2007-07-20 19:39:22 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static struct pmi_handler cbe_pmi_handler = {
|
|
|
|
.type = PMI_TYPE_FREQ_CHANGE,
|
|
|
|
.handle_pmi_message = cbe_cpufreq_handle_pmi,
|
|
|
|
};
|
|
|
|
|
2019-07-05 10:19:48 +00:00
|
|
|
void cbe_cpufreq_pmi_policy_init(struct cpufreq_policy *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 10:47:06 +00:00
|
|
|
struct freq_qos_request *req;
|
2019-07-05 10:19:48 +00:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (!cbe_cpufreq_has_pmi)
|
|
|
|
return;
|
|
|
|
|
|
|
|
req = kzalloc(sizeof(*req), GFP_KERNEL);
|
|
|
|
if (!req)
|
|
|
|
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 10:47:06 +00:00
|
|
|
ret = freq_qos_add_request(&policy->constraints, req, FREQ_QOS_MAX,
|
|
|
|
policy->freq_table[0].frequency);
|
2019-07-05 10:19:48 +00:00
|
|
|
if (ret < 0) {
|
|
|
|
pr_err("Failed to add freq constraint (%d)\n", ret);
|
|
|
|
kfree(req);
|
|
|
|
return;
|
|
|
|
}
|
2007-07-20 19:39:22 +00:00
|
|
|
|
2019-07-05 10:19:48 +00:00
|
|
|
policy->driver_data = req;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(cbe_cpufreq_pmi_policy_init);
|
2007-07-20 19:39:22 +00:00
|
|
|
|
2019-07-05 10:19:48 +00:00
|
|
|
void cbe_cpufreq_pmi_policy_exit(struct cpufreq_policy *policy)
|
2007-07-20 19:39:22 +00: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 10:47:06 +00:00
|
|
|
struct freq_qos_request *req = policy->driver_data;
|
2007-07-20 19:39:22 +00:00
|
|
|
|
2019-07-05 10:19:48 +00:00
|
|
|
if (cbe_cpufreq_has_pmi) {
|
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 10:47:06 +00:00
|
|
|
freq_qos_remove_request(req);
|
2019-07-05 10:19:48 +00:00
|
|
|
kfree(req);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(cbe_cpufreq_pmi_policy_exit);
|
2007-07-20 19:39:22 +00:00
|
|
|
|
2019-07-05 10:19:48 +00:00
|
|
|
void cbe_cpufreq_pmi_init(void)
|
|
|
|
{
|
|
|
|
if (!pmi_register_handler(&cbe_pmi_handler))
|
|
|
|
cbe_cpufreq_has_pmi = true;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(cbe_cpufreq_pmi_init);
|
2007-07-20 19:39:22 +00:00
|
|
|
|
2019-07-05 10:19:48 +00:00
|
|
|
void cbe_cpufreq_pmi_exit(void)
|
|
|
|
{
|
|
|
|
pmi_unregister_handler(&cbe_pmi_handler);
|
|
|
|
cbe_cpufreq_has_pmi = false;
|
2007-07-20 19:39:22 +00:00
|
|
|
}
|
2019-07-05 10:19:48 +00:00
|
|
|
EXPORT_SYMBOL_GPL(cbe_cpufreq_pmi_exit);
|