2022-06-07 22:11:32 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2015-03-30 17:59:52 +08:00
|
|
|
/*
|
|
|
|
* System Control and Power Interface (SCPI) based CPUFreq Interface driver
|
|
|
|
*
|
|
|
|
* Copyright (C) 2015 ARM Ltd.
|
|
|
|
* Sudeep Holla <sudeep.holla@arm.com>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
|
|
|
|
|
2018-01-11 00:44:15 +08:00
|
|
|
#include <linux/clk.h>
|
cpufreq: arm_big_little: use generic OPP functions for {init, free}_opp_table
Currently when performing random CPU hot-plugs and suspend-to-ram(S2R)
on systems using arm_big_little cpufreq driver, we get warnings similar
to something like below:
cpu cpu1: _opp_add: duplicate OPPs detected. Existing: freq: 600000000,
volt: 800000, enabled: 1. New: freq: 600000000, volt: 800000, enabled: 1
This is mainly because the OPPs for the shared cpus are not set. We can
just use dev_pm_opp_of_cpumask_add_table in case the OPPs are obtained
from DT(arm_big_little_dt.c) or use dev_pm_opp_set_sharing_cpus if the
OPPs are obtained by other means like firmware(e.g. scpi-cpufreq.c)
Also now that the generic dev_pm_opp{,_of}_cpumask_remove_table can
handle removal of opp table and entries for all associated CPUs, we can
re-use dev_pm_opp{,_of}_cpumask_remove_table as free_opp_table in
cpufreq_arm_bL_ops.
This patch makes necessary changes to reuse the generic OPP functions for
{init,free}_opp_table and thereby eliminating the warnings.
Signed-off-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>
2016-05-03 22:05:05 +08:00
|
|
|
#include <linux/cpu.h>
|
2015-03-30 17:59:52 +08:00
|
|
|
#include <linux/cpufreq.h>
|
2018-01-11 00:44:15 +08:00
|
|
|
#include <linux/cpumask.h>
|
|
|
|
#include <linux/export.h>
|
2015-03-30 17:59:52 +08:00
|
|
|
#include <linux/module.h>
|
2018-01-11 00:44:15 +08:00
|
|
|
#include <linux/of_platform.h>
|
2015-03-30 17:59:52 +08:00
|
|
|
#include <linux/pm_opp.h>
|
|
|
|
#include <linux/scpi_protocol.h>
|
2018-01-11 00:44:15 +08:00
|
|
|
#include <linux/slab.h>
|
2015-03-30 17:59:52 +08:00
|
|
|
#include <linux/types.h>
|
|
|
|
|
2018-01-11 00:44:15 +08:00
|
|
|
struct scpi_data {
|
|
|
|
struct clk *clk;
|
|
|
|
struct device *cpu_dev;
|
|
|
|
};
|
2015-03-30 17:59:52 +08:00
|
|
|
|
|
|
|
static struct scpi_ops *scpi_ops;
|
|
|
|
|
2018-01-11 00:44:15 +08:00
|
|
|
static unsigned int scpi_cpufreq_get_rate(unsigned int cpu)
|
|
|
|
{
|
|
|
|
struct cpufreq_policy *policy = cpufreq_cpu_get_raw(cpu);
|
|
|
|
struct scpi_data *priv = policy->driver_data;
|
|
|
|
unsigned long rate = clk_get_rate(priv->clk);
|
|
|
|
|
|
|
|
return rate / 1000;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
scpi_cpufreq_set_target(struct cpufreq_policy *policy, unsigned int index)
|
|
|
|
{
|
cpufreq: move invariance setter calls in cpufreq core
To properly scale its per-entity load-tracking signals, the task scheduler
needs to be given a frequency scale factor, i.e. some image of the current
frequency the CPU is running at. Currently, this scale can be computed
either by using counters (APERF/MPERF on x86, AMU on arm64), or by
piggy-backing on the frequency selection done by cpufreq.
For the latter, drivers have to explicitly set the scale factor
themselves, despite it being purely boiler-plate code: the required
information depends entirely on the kind of frequency switch callback
implemented by the driver, i.e. either of: target_index(), target(),
fast_switch() and setpolicy().
The fitness of those callbacks with regard to driving the Frequency
Invariance Engine (FIE) is studied below:
target_index()
==============
Documentation states that the chosen frequency "must be determined by
freq_table[index].frequency". It isn't clear if it *has* to be that
frequency, or if it can use that frequency value to do some computation
that ultimately leads to a different frequency selection. All drivers
go for the former, while the vexpress-spc-cpufreq has an atypical
implementation which is handled separately.
Therefore, the hook works on the assumption the core can use
freq_table[index].frequency.
target()
=======
This has been flagged as deprecated since:
commit 9c0ebcf78fde ("cpufreq: Implement light weight ->target_index() routine")
It also doesn't have that many users:
gx-suspmod.c:439: .target = cpufreq_gx_target,
s3c24xx-cpufreq.c:428: .target = s3c_cpufreq_target,
intel_pstate.c:2528: .target = intel_cpufreq_target,
cppc_cpufreq.c:401: .target = cppc_cpufreq_set_target,
cpufreq-nforce2.c:371: .target = nforce2_target,
sh-cpufreq.c:163: .target = sh_cpufreq_target,
pcc-cpufreq.c:573: .target = pcc_cpufreq_target,
Similarly to the path taken for target_index() calls in the cpufreq core
during a frequency change, all of the drivers above will mark the end of a
frequency change by a call to cpufreq_freq_transition_end().
Therefore, cpufreq_freq_transition_end() can be used as the location for
the arch_set_freq_scale() call to potentially inform the scheduler of the
frequency change.
This change maintains the previous functionality for the drivers that
implement the target_index() callback, while also adding support for the
few drivers that implement the deprecated target() callback.
fast_switch()
=============
This callback *has* to return the frequency that was selected.
setpolicy()
===========
This callback does not have any designated way of informing what was the
end choice. But there are only two drivers using setpolicy(), and none
of them have current FIE support:
drivers/cpufreq/longrun.c:281: .setpolicy = longrun_set_policy,
drivers/cpufreq/intel_pstate.c:2215: .setpolicy = intel_pstate_set_policy,
The intel_pstate is known to use counter-driven frequency invariance.
Conclusion
==========
Given that the significant majority of current FIE enabled drivers use
callbacks that lend themselves to triggering the setting of the FIE scale
factor in a generic way, move the invariance setter calls to cpufreq core.
As a result of setting the frequency scale factor in cpufreq core, after
callbacks that lend themselves to trigger it, remove this functionality
from the driver side.
To be noted that despite marking a successful frequency change, many
cpufreq drivers will consider the new frequency as the requested
frequency, although this is might not be the one granted by the hardware.
Therefore, the call to arch_set_freq_scale() is a "best effort" one, and
it is up to the architecture if the new frequency is used in the new
frequency scale factor setting (determined by the implementation of
arch_set_freq_scale()) or eventually used by the scheduler (determined
by the implementation of arch_scale_freq_capacity()). The architecture
is in a better position to decide if it has better methods to obtain
more accurate information regarding the current frequency and use that
information instead (for example, the use of counters).
Also, the implementation to arch_set_freq_scale() will now have to handle
error conditions (current frequency == 0) in order to prevent the
overhead in cpufreq core when the default arch_set_freq_scale()
implementation is used.
Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com>
Suggested-by: Valentin Schneider <valentin.schneider@arm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-09-02 04:55:46 +08:00
|
|
|
u64 rate = policy->freq_table[index].frequency * 1000;
|
2018-01-11 00:44:15 +08:00
|
|
|
struct scpi_data *priv = policy->driver_data;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = clk_set_rate(priv->clk, rate);
|
|
|
|
|
2018-02-26 21:11:03 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
if (clk_get_rate(priv->clk) != rate)
|
|
|
|
return -EIO;
|
|
|
|
|
|
|
|
return 0;
|
2018-01-11 00:44:15 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
scpi_get_sharing_cpus(struct device *cpu_dev, struct cpumask *cpumask)
|
2015-03-30 17:59:52 +08:00
|
|
|
{
|
2018-01-11 00:44:15 +08:00
|
|
|
int cpu, domain, tdomain;
|
|
|
|
struct device *tcpu_dev;
|
|
|
|
|
|
|
|
domain = scpi_ops->device_domain_id(cpu_dev);
|
|
|
|
if (domain < 0)
|
|
|
|
return domain;
|
|
|
|
|
|
|
|
for_each_possible_cpu(cpu) {
|
|
|
|
if (cpu == cpu_dev->id)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
tcpu_dev = get_cpu_device(cpu);
|
|
|
|
if (!tcpu_dev)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
tdomain = scpi_ops->device_domain_id(tcpu_dev);
|
|
|
|
if (tdomain == domain)
|
|
|
|
cpumask_set_cpu(cpu, cpumask);
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
cpufreq: arm_big_little: use generic OPP functions for {init, free}_opp_table
Currently when performing random CPU hot-plugs and suspend-to-ram(S2R)
on systems using arm_big_little cpufreq driver, we get warnings similar
to something like below:
cpu cpu1: _opp_add: duplicate OPPs detected. Existing: freq: 600000000,
volt: 800000, enabled: 1. New: freq: 600000000, volt: 800000, enabled: 1
This is mainly because the OPPs for the shared cpus are not set. We can
just use dev_pm_opp_of_cpumask_add_table in case the OPPs are obtained
from DT(arm_big_little_dt.c) or use dev_pm_opp_set_sharing_cpus if the
OPPs are obtained by other means like firmware(e.g. scpi-cpufreq.c)
Also now that the generic dev_pm_opp{,_of}_cpumask_remove_table can
handle removal of opp table and entries for all associated CPUs, we can
re-use dev_pm_opp{,_of}_cpumask_remove_table as free_opp_table in
cpufreq_arm_bL_ops.
This patch makes necessary changes to reuse the generic OPP functions for
{init,free}_opp_table and thereby eliminating the warnings.
Signed-off-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>
2016-05-03 22:05:05 +08:00
|
|
|
}
|
|
|
|
|
2018-01-11 00:44:15 +08:00
|
|
|
static int scpi_cpufreq_init(struct cpufreq_policy *policy)
|
cpufreq: arm_big_little: use generic OPP functions for {init, free}_opp_table
Currently when performing random CPU hot-plugs and suspend-to-ram(S2R)
on systems using arm_big_little cpufreq driver, we get warnings similar
to something like below:
cpu cpu1: _opp_add: duplicate OPPs detected. Existing: freq: 600000000,
volt: 800000, enabled: 1. New: freq: 600000000, volt: 800000, enabled: 1
This is mainly because the OPPs for the shared cpus are not set. We can
just use dev_pm_opp_of_cpumask_add_table in case the OPPs are obtained
from DT(arm_big_little_dt.c) or use dev_pm_opp_set_sharing_cpus if the
OPPs are obtained by other means like firmware(e.g. scpi-cpufreq.c)
Also now that the generic dev_pm_opp{,_of}_cpumask_remove_table can
handle removal of opp table and entries for all associated CPUs, we can
re-use dev_pm_opp{,_of}_cpumask_remove_table as free_opp_table in
cpufreq_arm_bL_ops.
This patch makes necessary changes to reuse the generic OPP functions for
{init,free}_opp_table and thereby eliminating the warnings.
Signed-off-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>
2016-05-03 22:05:05 +08:00
|
|
|
{
|
2017-04-27 22:20:37 +08:00
|
|
|
int ret;
|
2018-01-11 00:44:15 +08:00
|
|
|
unsigned int latency;
|
|
|
|
struct device *cpu_dev;
|
|
|
|
struct scpi_data *priv;
|
|
|
|
struct cpufreq_frequency_table *freq_table;
|
|
|
|
|
|
|
|
cpu_dev = get_cpu_device(policy->cpu);
|
|
|
|
if (!cpu_dev) {
|
|
|
|
pr_err("failed to get cpu%d device\n", policy->cpu);
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
2015-03-30 17:59:52 +08:00
|
|
|
|
2017-04-27 22:20:37 +08:00
|
|
|
ret = scpi_ops->add_opps_to_device(cpu_dev);
|
|
|
|
if (ret) {
|
|
|
|
dev_warn(cpu_dev, "failed to add opps to the device\n");
|
|
|
|
return ret;
|
2015-03-30 17:59:52 +08:00
|
|
|
}
|
|
|
|
|
2018-01-11 00:44:15 +08:00
|
|
|
ret = scpi_get_sharing_cpus(cpu_dev, policy->cpus);
|
|
|
|
if (ret) {
|
|
|
|
dev_warn(cpu_dev, "failed to get sharing cpumask\n");
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = dev_pm_opp_set_sharing_cpus(cpu_dev, policy->cpus);
|
|
|
|
if (ret) {
|
cpufreq: arm_big_little: use generic OPP functions for {init, free}_opp_table
Currently when performing random CPU hot-plugs and suspend-to-ram(S2R)
on systems using arm_big_little cpufreq driver, we get warnings similar
to something like below:
cpu cpu1: _opp_add: duplicate OPPs detected. Existing: freq: 600000000,
volt: 800000, enabled: 1. New: freq: 600000000, volt: 800000, enabled: 1
This is mainly because the OPPs for the shared cpus are not set. We can
just use dev_pm_opp_of_cpumask_add_table in case the OPPs are obtained
from DT(arm_big_little_dt.c) or use dev_pm_opp_set_sharing_cpus if the
OPPs are obtained by other means like firmware(e.g. scpi-cpufreq.c)
Also now that the generic dev_pm_opp{,_of}_cpumask_remove_table can
handle removal of opp table and entries for all associated CPUs, we can
re-use dev_pm_opp{,_of}_cpumask_remove_table as free_opp_table in
cpufreq_arm_bL_ops.
This patch makes necessary changes to reuse the generic OPP functions for
{init,free}_opp_table and thereby eliminating the warnings.
Signed-off-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>
2016-05-03 22:05:05 +08:00
|
|
|
dev_err(cpu_dev, "%s: failed to mark OPPs as shared: %d\n",
|
|
|
|
__func__, ret);
|
2018-01-11 00:44:15 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = dev_pm_opp_get_opp_count(cpu_dev);
|
|
|
|
if (ret <= 0) {
|
|
|
|
dev_dbg(cpu_dev, "OPP table is not ready, deferring probe\n");
|
|
|
|
ret = -EPROBE_DEFER;
|
|
|
|
goto out_free_opp;
|
|
|
|
}
|
|
|
|
|
|
|
|
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
|
|
|
|
if (!priv) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto out_free_opp;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = dev_pm_opp_init_cpufreq_table(cpu_dev, &freq_table);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(cpu_dev, "failed to init cpufreq table: %d\n", ret);
|
|
|
|
goto out_free_priv;
|
|
|
|
}
|
|
|
|
|
|
|
|
priv->cpu_dev = cpu_dev;
|
|
|
|
priv->clk = clk_get(cpu_dev, NULL);
|
|
|
|
if (IS_ERR(priv->clk)) {
|
|
|
|
dev_err(cpu_dev, "%s: Failed to get clk for cpu: %d\n",
|
|
|
|
__func__, cpu_dev->id);
|
2018-01-23 10:09:02 +08:00
|
|
|
ret = PTR_ERR(priv->clk);
|
2018-01-11 00:44:15 +08:00
|
|
|
goto out_free_cpufreq_table;
|
|
|
|
}
|
|
|
|
|
|
|
|
policy->driver_data = priv;
|
2018-02-26 13:09:04 +08:00
|
|
|
policy->freq_table = freq_table;
|
2018-01-11 00:44:15 +08:00
|
|
|
|
|
|
|
/* scpi allows DVFS request for any domain from any CPU */
|
|
|
|
policy->dvfs_possible_from_any_cpu = true;
|
|
|
|
|
|
|
|
latency = scpi_ops->get_transition_latency(cpu_dev);
|
|
|
|
if (!latency)
|
|
|
|
latency = CPUFREQ_ETERNAL;
|
|
|
|
|
|
|
|
policy->cpuinfo.transition_latency = latency;
|
|
|
|
|
|
|
|
policy->fast_switch_possible = false;
|
2019-02-04 19:09:50 +08:00
|
|
|
|
2018-01-11 00:44:15 +08:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
out_free_cpufreq_table:
|
|
|
|
dev_pm_opp_free_cpufreq_table(cpu_dev, &freq_table);
|
|
|
|
out_free_priv:
|
|
|
|
kfree(priv);
|
|
|
|
out_free_opp:
|
2019-01-04 17:44:33 +08:00
|
|
|
dev_pm_opp_remove_all_dynamic(cpu_dev);
|
2018-01-11 00:44:15 +08:00
|
|
|
|
cpufreq: arm_big_little: use generic OPP functions for {init, free}_opp_table
Currently when performing random CPU hot-plugs and suspend-to-ram(S2R)
on systems using arm_big_little cpufreq driver, we get warnings similar
to something like below:
cpu cpu1: _opp_add: duplicate OPPs detected. Existing: freq: 600000000,
volt: 800000, enabled: 1. New: freq: 600000000, volt: 800000, enabled: 1
This is mainly because the OPPs for the shared cpus are not set. We can
just use dev_pm_opp_of_cpumask_add_table in case the OPPs are obtained
from DT(arm_big_little_dt.c) or use dev_pm_opp_set_sharing_cpus if the
OPPs are obtained by other means like firmware(e.g. scpi-cpufreq.c)
Also now that the generic dev_pm_opp{,_of}_cpumask_remove_table can
handle removal of opp table and entries for all associated CPUs, we can
re-use dev_pm_opp{,_of}_cpumask_remove_table as free_opp_table in
cpufreq_arm_bL_ops.
This patch makes necessary changes to reuse the generic OPP functions for
{init,free}_opp_table and thereby eliminating the warnings.
Signed-off-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>
2016-05-03 22:05:05 +08:00
|
|
|
return ret;
|
2015-03-30 17:59:52 +08:00
|
|
|
}
|
|
|
|
|
2018-01-11 00:44:15 +08:00
|
|
|
static int scpi_cpufreq_exit(struct cpufreq_policy *policy)
|
|
|
|
{
|
|
|
|
struct scpi_data *priv = policy->driver_data;
|
|
|
|
|
|
|
|
clk_put(priv->clk);
|
|
|
|
dev_pm_opp_free_cpufreq_table(priv->cpu_dev, &policy->freq_table);
|
2019-01-04 17:44:33 +08:00
|
|
|
dev_pm_opp_remove_all_dynamic(priv->cpu_dev);
|
2019-03-28 06:06:42 +08:00
|
|
|
kfree(priv);
|
2018-01-11 00:44:15 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct cpufreq_driver scpi_cpufreq_driver = {
|
|
|
|
.name = "scpi-cpufreq",
|
2021-02-02 12:55:11 +08:00
|
|
|
.flags = CPUFREQ_HAVE_GOVERNOR_PER_POLICY |
|
2019-01-29 12:55:15 +08:00
|
|
|
CPUFREQ_NEED_INITIAL_FREQ_CHECK |
|
|
|
|
CPUFREQ_IS_COOLING_DEV,
|
2018-01-11 00:44:15 +08:00
|
|
|
.verify = cpufreq_generic_frequency_table_verify,
|
|
|
|
.attr = cpufreq_generic_attr,
|
|
|
|
.get = scpi_cpufreq_get_rate,
|
|
|
|
.init = scpi_cpufreq_init,
|
|
|
|
.exit = scpi_cpufreq_exit,
|
|
|
|
.target_index = scpi_cpufreq_set_target,
|
2021-08-10 14:54:36 +08:00
|
|
|
.register_em = cpufreq_register_em_with_opp,
|
2015-03-30 17:59:52 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
static int scpi_cpufreq_probe(struct platform_device *pdev)
|
|
|
|
{
|
2018-01-11 00:44:15 +08:00
|
|
|
int ret;
|
|
|
|
|
2015-03-30 17:59:52 +08:00
|
|
|
scpi_ops = get_scpi_ops();
|
|
|
|
if (!scpi_ops)
|
|
|
|
return -EIO;
|
|
|
|
|
2018-01-11 00:44:15 +08:00
|
|
|
ret = cpufreq_register_driver(&scpi_cpufreq_driver);
|
|
|
|
if (ret)
|
|
|
|
dev_err(&pdev->dev, "%s: registering cpufreq failed, err: %d\n",
|
|
|
|
__func__, ret);
|
|
|
|
return ret;
|
2015-03-30 17:59:52 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int scpi_cpufreq_remove(struct platform_device *pdev)
|
|
|
|
{
|
2018-01-11 00:44:15 +08:00
|
|
|
cpufreq_unregister_driver(&scpi_cpufreq_driver);
|
2015-03-30 17:59:52 +08:00
|
|
|
scpi_ops = NULL;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct platform_driver scpi_cpufreq_platdrv = {
|
|
|
|
.driver = {
|
|
|
|
.name = "scpi-cpufreq",
|
|
|
|
},
|
|
|
|
.probe = scpi_cpufreq_probe,
|
|
|
|
.remove = scpi_cpufreq_remove,
|
|
|
|
};
|
|
|
|
module_platform_driver(scpi_cpufreq_platdrv);
|
|
|
|
|
2020-11-03 23:11:38 +08:00
|
|
|
MODULE_ALIAS("platform:scpi-cpufreq");
|
2015-03-30 17:59:52 +08:00
|
|
|
MODULE_AUTHOR("Sudeep Holla <sudeep.holla@arm.com>");
|
|
|
|
MODULE_DESCRIPTION("ARM SCPI CPUFreq interface driver");
|
|
|
|
MODULE_LICENSE("GPL v2");
|