cpufreq: OMAP: fixes for v3.7-rc2

From: Kevin Hilman <[email protected]>

Here's a series with a couple bug fixes and a couple fixes that make this driver support newer OMAP-based SoCs.

The 'get_cpu_device' patch is needed due to a change in the OMAP OMAP PM core code which enforces use of get_cpu_device() instead of a deprecated OMAP-specific API.

The usage of plat/*.h headers breaks single zImage, so platforms are cleaning up and/or removing plat/*.h so the driver needs to be fixed accordingly.

This series is based on the merge of Rafael's pm-for-3.7-rc1 tag into Linus' master branch: commit 16642a2e7be23bbda013fc32d8f6c68982eab603.

Tested CPUfreq on OMAP platforms: 3430/n900, 3530/Overo, 3730/OveroSTORM, 3730/Beagle-XM, 4430/Panda.

Rafael, if you're OK with this series, I'll get a pull request ASAP so it can be included for v3.7-rc2.

Kevin Hilman (3):
cpufreq: OMAP: ensure valid clock rate before scaling
cpufreq: OMAP: remove unused <plat/omap-pm.h>
cpufreq: OMAP: use get_cpu_device() instead of omap_device API

Paul Walmsley (1):
cpufreq: OMAP: fix clock usage to be SoC independent, remove plat/
includes

 drivers/cpufreq/omap-cpufreq.c |   36 ++++++++++++------------------------
 1 file changed, 12 insertions(+), 24 deletions(-)

1.7.9.2

From: Kevin Hilman <[email protected]>

Ensure the clock rate that will be used is a valid one before attempting to scale the voltage. Currently the driver assumes it has a valid frequency from the OPP table, but boards using different system oscillators might not have exact matches with the OPP table, and result in a failing call to clk_set_rate().

This is particularily bad because the voltage may be scaled even though the frequency is not. This will obviously lead to some unpredictable behavior, especially if the frequency is high and the voltage is dropped.

Thanks to Joni Lapilainen for reporting crashes seen on 3430/n900.

---
 drivers/cpufreq/omap-cpufreq.c |    8 ++++++++
 1 file changed, 8 insertions(+)

index 65f8e9a..0fe395a 100644
@@ -108,6 +108,14 @@ static int omap_target(struct cpufreq_policy *policy,
 	}
 
 	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) {
 		opp = opp_find_freq_ceil(mpu_dev, &freq);

1.7.9.2

From: Kevin Hilman <[email protected]>

The <plat/*.h> headers are going away, and this one is not used. remove it.

---
 drivers/cpufreq/omap-cpufreq.c |    1 -
 1 file changed, 1 deletion(-)

index 0fe395a..7d4d455 100644
@@ -31,7 +31,6 @@
 #include <asm/cpu.h>
 
 #include <plat/clock.h>
-#include <plat/omap-pm.h>
 #include <plat/common.h>
 #include <plat/omap_device.h>
 

1.7.9.2

From: Paul Walmsley <[email protected]>

OMAP core code now has SoC-independent clock alias for the scalable CPU clock. Using it means driver is SoC independent and will work for AM3xxx SoCs as well as OMAP1/3/4.

While here, remove some unnecessary plat/ includes that are interfering with multi-subarch ARM kernels.

---
 drivers/cpufreq/omap-cpufreq.c |   19 +------------------
 1 file changed, 1 insertion(+), 18 deletions(-)

index 7d4d455..5d1f5e4 100644
@@ -30,19 +30,14 @@
 #include <asm/smp_plat.h>
 #include <asm/cpu.h>
 
-#include <plat/clock.h>
-#include <plat/common.h>
 #include <plat/omap_device.h>
 
-#include <mach/hardware.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 char *mpu_clk_name;
 static struct device *mpu_dev;
 static struct regulator *mpu_reg;
 

@@ -179,7 +174,7 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy *policy)
 {
 	int result = 0;
 
-	mpu_clk = clk_get(NULL, mpu_clk_name);
+	mpu_clk = clk_get(NULL, "cpufreq_ck");
 	if (IS_ERR(mpu_clk))
 		return PTR_ERR(mpu_clk);
 

@@ -260,18 +255,6 @@ static struct cpufreq_driver omap_driver = {
 
 static int __init omap_cpufreq_init(void)
 {
-	if (cpu_is_omap24xx())
-		mpu_clk_name = "virt_prcm_set";
-	else if (cpu_is_omap34xx())
-		mpu_clk_name = "dpll1_ck";
-	else if (cpu_is_omap44xx())
-		mpu_clk_name = "dpll_mpu_ck";
-
-	if (!mpu_clk_name) {
-		pr_err("%s: unsupported Silicon?\n", __func__);
-		return -EINVAL;
-	}
-
 	mpu_dev = omap_device_get_by_hwmod_name("mpu");
 	if (IS_ERR(mpu_dev)) {
 		pr_warning("%s: unable to get the mpu device\n", __func__);

1.7.9.2

From: Kevin Hilman <[email protected]>

OMAP PM core code has moved to using the existing, generic CPU devices for attaching OPPs, so the CPUfreq driver can now use the generic get_cpu_device() API instead of the OMAP-specific omap_device API.

This allows us to remove the last <plat/*> include from this driver.

---
 drivers/cpufreq/omap-cpufreq.c |    8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

index 5d1f5e4..1f3417a 100644
@@ -30,8 +30,6 @@
 #include <asm/smp_plat.h>
 #include <asm/cpu.h>
 
-#include <plat/omap_device.h>
-
 /* OPP tolerance in percentage */
 #define	OPP_TOLERANCE	4
 

@@ -255,10 +253,10 @@ static struct cpufreq_driver omap_driver = {
 
 static int __init omap_cpufreq_init(void)
 {
-	mpu_dev = omap_device_get_by_hwmod_name("mpu");
-	if (IS_ERR(mpu_dev)) {
+	mpu_dev = get_cpu_device(0);
+	if (!mpu_dev) {
 		pr_warning("%s: unable to get the mpu device\n", __func__);
-		return PTR_ERR(mpu_dev);
+		return -EINVAL;
 	}
 
 	mpu_reg = regulator_get(mpu_dev, "vcc");

1.7.9.2

The patches are fine by me, but there may be a bit of a timing issue with them, because I'll be travelling between October 12 and October 21 inclusive and I won't be pushing stuff to kernel.org during that time.

So I think it would be better to merge this material through the arm-soc tree, if that's not a problem. If you decide to do so, please feel free to add my ACK to the patches.

Thanks,
Rafael

I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Thanks, I'll get them queued.

Kevin