linux/drivers/cpufreq/omap-cpufreq.c

231 lines
5.5 KiB
C
Raw Normal View History

/*
* CPU frequency scaling for OMAP using OPP information
*
* Copyright (C) 2005 Nokia Corporation
* Written by Tony Lindgren <tony@atomide.com>
*
* Based on cpu-sa1110.c, Copyright (C) 2001 Russell King
*
* Copyright (C) 2007-2011 Texas Instruments, Inc.
* - OMAP3/4 support by Rajendra Nayak, Santosh Shilimkar
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
#include <linux/types.h>
#include <linux/kernel.h>
#include <linux/sched.h>
#include <linux/cpufreq.h>
#include <linux/delay.h>
#include <linux/init.h>
#include <linux/err.h>
#include <linux/clk.h>
#include <linux/io.h>
#include <linux/pm_opp.h>
#include <linux/cpu.h>
#include <linux/module.h>
cpufreq: OMAP: instantiate omap-cpufreq as a platform_driver As multi-platform build is being adopted by more and more ARM platforms, initcall function should be used very carefully. For example, when CONFIG_ARM_OMAP2PLUS_CPUFREQ is built in the kernel, omap_cpufreq_init() will be called on all the platforms to initialize omap-cpufreq driver. Further, on OMAP, we now use Soc generic cpufreq-cpu0 driver using device tree entries. To allow cpufreq-cpu0 and omap-cpufreq drivers to co-exist for OMAP in a single image, we need to ensure the following: 1. With device tree boot, we use cpufreq-cpu0 2. With non device tree boot, we use omap-cpufreq In the case of (1), we will have cpu OPPs and regulator registered as part of the device tree nodes, to ensure that omap-cpufreq and cpufreq-cpu0 don't conflict in managing the frequency of the same CPU, we should not permit omap-cpufreq to be probed. In the case of (2), we will not have the cpufreq-cpu0 device, hence only omap-cpufreq will be active. To eliminate this undesired these effects, we change omap-cpufreq driver to have it instantiated as a platform_driver and register "omap-cpufreq" device only when booted without device tree nodes on OMAP platforms. This allows the following: a) Will only run on platforms that create the platform_device "omap-cpufreq". b) Since the platform_device is registered only when device tree nodes are *not* populated, omap-cpufreq driver does not conflict with the usage of cpufreq-cpu0 driver which is used on OMAP platforms when device tree nodes are present. Inspired by commit 5553f9e26f6f49a93ba732fd222eac6973a4cf35 (cpufreq: instantiate cpufreq-cpu0 as a platform_driver) [robherring2@gmail.com: reported conflict of omap-cpufreq vs other driver in an non-device tree supported boot] Reported-by: Rob Herring <robherring2@gmail.com> Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-10 03:22:01 +04:00
#include <linux/platform_device.h>
#include <linux/regulator/consumer.h>
#include <asm/smp_plat.h>
#include <asm/cpu.h>
/* OPP tolerance in percentage */
#define OPP_TOLERANCE 4
static struct cpufreq_frequency_table *freq_table;
static atomic_t freq_table_users = ATOMIC_INIT(0);
static struct clk *mpu_clk;
static struct device *mpu_dev;
static struct regulator *mpu_reg;
OMAP: plat-omap: Fix static function warnings This patch fixes sparse warnings due non declarations of static functions. arch/arm/plat-omap/sram.c:130:13: warning: symbol 'omap_detect_sram' was not declared. Should it be static? arch/arm/plat-omap/sram.c:216:13: warning: symbol 'omap_map_sram' was not declared. Should it be static? arch/arm/plat-omap/sram.c:450:12: warning: symbol 'omap_sram_init' was not declared. Should it be static? arch/arm/plat-omap/sram.c:348:12: warning: symbol 'omap242x_sram_init' was not declared. Should it be static? arch/arm/plat-omap/sram.c:369:12: warning: symbol 'omap243x_sram_init' was not declared. Should it be static? arch/arm/plat-omap/sram.c:425:12: warning: symbol 'omap34xx_sram_init' was not declared. Should it be static? arch/arm/plat-omap/sram.c:441:12: warning: symbol 'omap44xx_sram_init' was not declared. Should it be static arch/arm/plat-omap/mcbsp.c:36:6: warning: symbol 'omap_mcbsp_write' was not declared. Should it be static? arch/arm/plat-omap/mcbsp.c:50:5: warning: symbol 'omap_mcbsp_read' was not declared. Should it be static? arch/arm/plat-omap/mcbsp.c:65:6: warning: symbol 'omap_mcbsp_st_write' was not declared. Should it be static? arch/arm/plat-omap/mcbsp.c:70:5: warning: symbol 'omap_mcbsp_st_read' was not declared. Should it be static? arch/arm/plat-omap/mcbsp.c:1648:15: warning: symbol 'omap_st_add' was not declared. Should it be static? arch/arm/plat-omap/fb.c:414:15: warning: symbol 'omapfb_reserve_sram' was not declared. Should it be static? arch/arm/plat-omap/cpu-omap.c:43:5: warning: symbol 'omap_verify_speed' was not declared. Should it be static? arch/arm/plat-omap/cpu-omap.c:61:14: warning: symbol 'omap_getspeed' was not declared. Should it be static? Signed-off-by: Manjunath Kondaiah G <manjugk@ti.com> Cc: linux-arm-kernel@lists.infradead.org Cc: Nishanth Menon <nm@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-10-08 21:00:19 +04:00
static unsigned int omap_getspeed(unsigned int cpu)
{
unsigned long rate;
if (cpu >= NR_CPUS)
return 0;
rate = clk_get_rate(mpu_clk) / 1000;
return rate;
}
cpufreq: Implement light weight ->target_index() routine Currently, the prototype of cpufreq_drivers target routines is: int target(struct cpufreq_policy *policy, unsigned int target_freq, unsigned int relation); And most of the drivers call cpufreq_frequency_table_target() to get a valid index of their frequency table which is closest to the target_freq. And they don't use target_freq and relation after that. So, it makes sense to just do this work in cpufreq core before calling cpufreq_frequency_table_target() and simply pass index instead. But this can be done only with drivers which expose their frequency table with cpufreq core. For others we need to stick with the old prototype of target() until those drivers are converted to expose frequency tables. This patch implements the new light weight prototype for target_index() routine. It looks like this: int target_index(struct cpufreq_policy *policy, unsigned int index); CPUFreq core will call cpufreq_frequency_table_target() before calling this routine and pass index to it. Because CPUFreq core now requires to call routines present in freq_table.c CONFIG_CPU_FREQ_TABLE must be enabled all the time. This also marks target() interface as deprecated. So, that new drivers avoid using it. And Documentation is updated accordingly. It also converts existing .target() to newly defined light weight .target_index() routine for many driver. Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no> Acked-by: Jesper Nilsson <jesper.nilsson@axis.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Russell King <linux@arm.linux.org.uk> Acked-by: David S. Miller <davem@davemloft.net> Tested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rjw@rjwysocki.net>
2013-10-25 18:15:48 +04:00
static int omap_target(struct cpufreq_policy *policy, unsigned int index)
{
int r, ret = 0;
struct cpufreq_freqs freqs;
struct dev_pm_opp *opp;
unsigned long freq, volt = 0, volt_old = 0, tol = 0;
freqs.old = omap_getspeed(policy->cpu);
cpufreq: Implement light weight ->target_index() routine Currently, the prototype of cpufreq_drivers target routines is: int target(struct cpufreq_policy *policy, unsigned int target_freq, unsigned int relation); And most of the drivers call cpufreq_frequency_table_target() to get a valid index of their frequency table which is closest to the target_freq. And they don't use target_freq and relation after that. So, it makes sense to just do this work in cpufreq core before calling cpufreq_frequency_table_target() and simply pass index instead. But this can be done only with drivers which expose their frequency table with cpufreq core. For others we need to stick with the old prototype of target() until those drivers are converted to expose frequency tables. This patch implements the new light weight prototype for target_index() routine. It looks like this: int target_index(struct cpufreq_policy *policy, unsigned int index); CPUFreq core will call cpufreq_frequency_table_target() before calling this routine and pass index to it. Because CPUFreq core now requires to call routines present in freq_table.c CONFIG_CPU_FREQ_TABLE must be enabled all the time. This also marks target() interface as deprecated. So, that new drivers avoid using it. And Documentation is updated accordingly. It also converts existing .target() to newly defined light weight .target_index() routine for many driver. Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no> Acked-by: Jesper Nilsson <jesper.nilsson@axis.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Russell King <linux@arm.linux.org.uk> Acked-by: David S. Miller <davem@davemloft.net> Tested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rjw@rjwysocki.net>
2013-10-25 18:15:48 +04:00
freqs.new = freq_table[index].frequency;
freq = freqs.new * 1000;
ret = clk_round_rate(mpu_clk, freq);
if (IS_ERR_VALUE(ret)) {
dev_warn(mpu_dev,
"CPUfreq: Cannot find matching frequency for %lu\n",
freq);
return ret;
}
freq = ret;
if (mpu_reg) {
rcu_read_lock();
opp = dev_pm_opp_find_freq_ceil(mpu_dev, &freq);
if (IS_ERR(opp)) {
rcu_read_unlock();
dev_err(mpu_dev, "%s: unable to find MPU OPP for %d\n",
__func__, freqs.new);
return -EINVAL;
}
volt = dev_pm_opp_get_voltage(opp);
rcu_read_unlock();
tol = volt * OPP_TOLERANCE / 100;
volt_old = regulator_get_voltage(mpu_reg);
}
dev_dbg(mpu_dev, "cpufreq-omap: %u MHz, %ld mV --> %u MHz, %ld mV\n",
freqs.old / 1000, volt_old ? volt_old / 1000 : -1,
freqs.new / 1000, volt ? volt / 1000 : -1);
/* notifiers */
cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* scaling up? scale voltage before frequency */
if (mpu_reg && (freqs.new > freqs.old)) {
r = regulator_set_voltage(mpu_reg, volt - tol, volt + tol);
if (r < 0) {
dev_warn(mpu_dev, "%s: unable to scale voltage up.\n",
__func__);
freqs.new = freqs.old;
goto done;
}
}
ret = clk_set_rate(mpu_clk, freqs.new * 1000);
/* scaling down? scale voltage after frequency */
if (mpu_reg && (freqs.new < freqs.old)) {
r = regulator_set_voltage(mpu_reg, volt - tol, volt + tol);
if (r < 0) {
dev_warn(mpu_dev, "%s: unable to scale voltage down.\n",
__func__);
ret = clk_set_rate(mpu_clk, freqs.old * 1000);
freqs.new = freqs.old;
goto done;
}
}
freqs.new = omap_getspeed(policy->cpu);
done:
/* notifiers */
cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
return ret;
}
static inline void freq_table_free(void)
{
if (atomic_dec_and_test(&freq_table_users))
dev_pm_opp_free_cpufreq_table(mpu_dev, &freq_table);
}
static int omap_cpu_init(struct cpufreq_policy *policy)
{
int result;
mpu_clk = clk_get(NULL, "cpufreq_ck");
if (IS_ERR(mpu_clk))
return PTR_ERR(mpu_clk);
if (!freq_table) {
result = dev_pm_opp_init_cpufreq_table(mpu_dev, &freq_table);
if (result) {
dev_err(mpu_dev,
"%s: cpu%d: failed creating freq table[%d]\n",
__func__, policy->cpu, result);
goto fail;
}
}
atomic_inc_return(&freq_table_users);
/* FIXME: what's the actual transition time? */
result = cpufreq_generic_init(policy, freq_table, 300 * 1000);
if (!result)
return 0;
freq_table_free();
fail:
clk_put(mpu_clk);
return result;
}
static int omap_cpu_exit(struct cpufreq_policy *policy)
{
cpufreq_frequency_table_put_attr(policy->cpu);
freq_table_free();
clk_put(mpu_clk);
return 0;
}
static struct cpufreq_driver omap_driver = {
.flags = CPUFREQ_STICKY,
.verify = cpufreq_generic_frequency_table_verify,
cpufreq: Implement light weight ->target_index() routine Currently, the prototype of cpufreq_drivers target routines is: int target(struct cpufreq_policy *policy, unsigned int target_freq, unsigned int relation); And most of the drivers call cpufreq_frequency_table_target() to get a valid index of their frequency table which is closest to the target_freq. And they don't use target_freq and relation after that. So, it makes sense to just do this work in cpufreq core before calling cpufreq_frequency_table_target() and simply pass index instead. But this can be done only with drivers which expose their frequency table with cpufreq core. For others we need to stick with the old prototype of target() until those drivers are converted to expose frequency tables. This patch implements the new light weight prototype for target_index() routine. It looks like this: int target_index(struct cpufreq_policy *policy, unsigned int index); CPUFreq core will call cpufreq_frequency_table_target() before calling this routine and pass index to it. Because CPUFreq core now requires to call routines present in freq_table.c CONFIG_CPU_FREQ_TABLE must be enabled all the time. This also marks target() interface as deprecated. So, that new drivers avoid using it. And Documentation is updated accordingly. It also converts existing .target() to newly defined light weight .target_index() routine for many driver. Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no> Acked-by: Jesper Nilsson <jesper.nilsson@axis.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Russell King <linux@arm.linux.org.uk> Acked-by: David S. Miller <davem@davemloft.net> Tested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rjw@rjwysocki.net>
2013-10-25 18:15:48 +04:00
.target_index = omap_target,
.get = omap_getspeed,
.init = omap_cpu_init,
.exit = omap_cpu_exit,
.name = "omap",
.attr = cpufreq_generic_attr,
};
cpufreq: OMAP: instantiate omap-cpufreq as a platform_driver As multi-platform build is being adopted by more and more ARM platforms, initcall function should be used very carefully. For example, when CONFIG_ARM_OMAP2PLUS_CPUFREQ is built in the kernel, omap_cpufreq_init() will be called on all the platforms to initialize omap-cpufreq driver. Further, on OMAP, we now use Soc generic cpufreq-cpu0 driver using device tree entries. To allow cpufreq-cpu0 and omap-cpufreq drivers to co-exist for OMAP in a single image, we need to ensure the following: 1. With device tree boot, we use cpufreq-cpu0 2. With non device tree boot, we use omap-cpufreq In the case of (1), we will have cpu OPPs and regulator registered as part of the device tree nodes, to ensure that omap-cpufreq and cpufreq-cpu0 don't conflict in managing the frequency of the same CPU, we should not permit omap-cpufreq to be probed. In the case of (2), we will not have the cpufreq-cpu0 device, hence only omap-cpufreq will be active. To eliminate this undesired these effects, we change omap-cpufreq driver to have it instantiated as a platform_driver and register "omap-cpufreq" device only when booted without device tree nodes on OMAP platforms. This allows the following: a) Will only run on platforms that create the platform_device "omap-cpufreq". b) Since the platform_device is registered only when device tree nodes are *not* populated, omap-cpufreq driver does not conflict with the usage of cpufreq-cpu0 driver which is used on OMAP platforms when device tree nodes are present. Inspired by commit 5553f9e26f6f49a93ba732fd222eac6973a4cf35 (cpufreq: instantiate cpufreq-cpu0 as a platform_driver) [robherring2@gmail.com: reported conflict of omap-cpufreq vs other driver in an non-device tree supported boot] Reported-by: Rob Herring <robherring2@gmail.com> Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-10 03:22:01 +04:00
static int omap_cpufreq_probe(struct platform_device *pdev)
{
mpu_dev = get_cpu_device(0);
if (!mpu_dev) {
pr_warning("%s: unable to get the mpu device\n", __func__);
return -EINVAL;
}
mpu_reg = regulator_get(mpu_dev, "vcc");
if (IS_ERR(mpu_reg)) {
pr_warning("%s: unable to get MPU regulator\n", __func__);
mpu_reg = NULL;
} else {
/*
* Ensure physical regulator is present.
* (e.g. could be dummy regulator.)
*/
if (regulator_get_voltage(mpu_reg) < 0) {
pr_warn("%s: physical regulator not present for MPU\n",
__func__);
regulator_put(mpu_reg);
mpu_reg = NULL;
}
}
return cpufreq_register_driver(&omap_driver);
}
cpufreq: OMAP: instantiate omap-cpufreq as a platform_driver As multi-platform build is being adopted by more and more ARM platforms, initcall function should be used very carefully. For example, when CONFIG_ARM_OMAP2PLUS_CPUFREQ is built in the kernel, omap_cpufreq_init() will be called on all the platforms to initialize omap-cpufreq driver. Further, on OMAP, we now use Soc generic cpufreq-cpu0 driver using device tree entries. To allow cpufreq-cpu0 and omap-cpufreq drivers to co-exist for OMAP in a single image, we need to ensure the following: 1. With device tree boot, we use cpufreq-cpu0 2. With non device tree boot, we use omap-cpufreq In the case of (1), we will have cpu OPPs and regulator registered as part of the device tree nodes, to ensure that omap-cpufreq and cpufreq-cpu0 don't conflict in managing the frequency of the same CPU, we should not permit omap-cpufreq to be probed. In the case of (2), we will not have the cpufreq-cpu0 device, hence only omap-cpufreq will be active. To eliminate this undesired these effects, we change omap-cpufreq driver to have it instantiated as a platform_driver and register "omap-cpufreq" device only when booted without device tree nodes on OMAP platforms. This allows the following: a) Will only run on platforms that create the platform_device "omap-cpufreq". b) Since the platform_device is registered only when device tree nodes are *not* populated, omap-cpufreq driver does not conflict with the usage of cpufreq-cpu0 driver which is used on OMAP platforms when device tree nodes are present. Inspired by commit 5553f9e26f6f49a93ba732fd222eac6973a4cf35 (cpufreq: instantiate cpufreq-cpu0 as a platform_driver) [robherring2@gmail.com: reported conflict of omap-cpufreq vs other driver in an non-device tree supported boot] Reported-by: Rob Herring <robherring2@gmail.com> Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-10 03:22:01 +04:00
static int omap_cpufreq_remove(struct platform_device *pdev)
{
cpufreq: OMAP: instantiate omap-cpufreq as a platform_driver As multi-platform build is being adopted by more and more ARM platforms, initcall function should be used very carefully. For example, when CONFIG_ARM_OMAP2PLUS_CPUFREQ is built in the kernel, omap_cpufreq_init() will be called on all the platforms to initialize omap-cpufreq driver. Further, on OMAP, we now use Soc generic cpufreq-cpu0 driver using device tree entries. To allow cpufreq-cpu0 and omap-cpufreq drivers to co-exist for OMAP in a single image, we need to ensure the following: 1. With device tree boot, we use cpufreq-cpu0 2. With non device tree boot, we use omap-cpufreq In the case of (1), we will have cpu OPPs and regulator registered as part of the device tree nodes, to ensure that omap-cpufreq and cpufreq-cpu0 don't conflict in managing the frequency of the same CPU, we should not permit omap-cpufreq to be probed. In the case of (2), we will not have the cpufreq-cpu0 device, hence only omap-cpufreq will be active. To eliminate this undesired these effects, we change omap-cpufreq driver to have it instantiated as a platform_driver and register "omap-cpufreq" device only when booted without device tree nodes on OMAP platforms. This allows the following: a) Will only run on platforms that create the platform_device "omap-cpufreq". b) Since the platform_device is registered only when device tree nodes are *not* populated, omap-cpufreq driver does not conflict with the usage of cpufreq-cpu0 driver which is used on OMAP platforms when device tree nodes are present. Inspired by commit 5553f9e26f6f49a93ba732fd222eac6973a4cf35 (cpufreq: instantiate cpufreq-cpu0 as a platform_driver) [robherring2@gmail.com: reported conflict of omap-cpufreq vs other driver in an non-device tree supported boot] Reported-by: Rob Herring <robherring2@gmail.com> Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-10 03:22:01 +04:00
return cpufreq_unregister_driver(&omap_driver);
}
cpufreq: OMAP: instantiate omap-cpufreq as a platform_driver As multi-platform build is being adopted by more and more ARM platforms, initcall function should be used very carefully. For example, when CONFIG_ARM_OMAP2PLUS_CPUFREQ is built in the kernel, omap_cpufreq_init() will be called on all the platforms to initialize omap-cpufreq driver. Further, on OMAP, we now use Soc generic cpufreq-cpu0 driver using device tree entries. To allow cpufreq-cpu0 and omap-cpufreq drivers to co-exist for OMAP in a single image, we need to ensure the following: 1. With device tree boot, we use cpufreq-cpu0 2. With non device tree boot, we use omap-cpufreq In the case of (1), we will have cpu OPPs and regulator registered as part of the device tree nodes, to ensure that omap-cpufreq and cpufreq-cpu0 don't conflict in managing the frequency of the same CPU, we should not permit omap-cpufreq to be probed. In the case of (2), we will not have the cpufreq-cpu0 device, hence only omap-cpufreq will be active. To eliminate this undesired these effects, we change omap-cpufreq driver to have it instantiated as a platform_driver and register "omap-cpufreq" device only when booted without device tree nodes on OMAP platforms. This allows the following: a) Will only run on platforms that create the platform_device "omap-cpufreq". b) Since the platform_device is registered only when device tree nodes are *not* populated, omap-cpufreq driver does not conflict with the usage of cpufreq-cpu0 driver which is used on OMAP platforms when device tree nodes are present. Inspired by commit 5553f9e26f6f49a93ba732fd222eac6973a4cf35 (cpufreq: instantiate cpufreq-cpu0 as a platform_driver) [robherring2@gmail.com: reported conflict of omap-cpufreq vs other driver in an non-device tree supported boot] Reported-by: Rob Herring <robherring2@gmail.com> Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-10 03:22:01 +04:00
static struct platform_driver omap_cpufreq_platdrv = {
.driver = {
.name = "omap-cpufreq",
.owner = THIS_MODULE,
},
.probe = omap_cpufreq_probe,
.remove = omap_cpufreq_remove,
};
module_platform_driver(omap_cpufreq_platdrv);
MODULE_DESCRIPTION("cpufreq driver for OMAP SoCs");
MODULE_LICENSE("GPL");