[PATCH 0/4] cpufreq: OMAP: fixes for v3.7-rc2

[PATCH 0/4] cpufreq: OMAP: fixes for v3.7-rc2

[Kevin Hilman]

From: Kevin Hilman <khilman@ti.com>

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

[PATCH 1/4] cpufreq: OMAP: ensure valid clock rate before scaling

[Kevin Hilman]

From: Kevin Hilman <khilman@ti.com>

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.

Reported-by: Joni Lapilainen <joni.lapilainen@gmail.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
---
 drivers/cpufreq/omap-cpufreq.c |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 65f8e9a..0fe395a 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -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

[PATCH 2/4] cpufreq: OMAP: remove unused <plat/omap-pm.h>

[Kevin Hilman]

From: Kevin Hilman <khilman@ti.com>

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

Signed-off-by: Kevin Hilman <khilman@ti.com>
---
 drivers/cpufreq/omap-cpufreq.c |    1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 0fe395a..7d4d455 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -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

[PATCH 3/4] cpufreq: OMAP: fix clock usage to be SoC independent, remove plat/ includes

[Kevin Hilman]

From: Paul Walmsley <paul@pwsan.com>

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.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
[tony at atomide.com: updated already changed clock aliases]
Signed-off-by: Tony Lindgren <tony@atomide.com>
[khilman at ti.com: minor shortlog/changelog updates]
Signed-off-by: Kevin Hilman <khilman@ti.com>
---
 drivers/cpufreq/omap-cpufreq.c |   19 +------------------
 1 file changed, 1 insertion(+), 18 deletions(-)

diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 7d4d455..5d1f5e4 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -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

[PATCH 4/4] cpufreq: OMAP: use get_cpu_device() instead of omap_device API

[Kevin Hilman]

From: Kevin Hilman <khilman@ti.com>

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.

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
---
 drivers/cpufreq/omap-cpufreq.c |    8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 5d1f5e4..1f3417a 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -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

[PATCH 0/4] cpufreq: OMAP: fixes for v3.7-rc2

[Rafael J. Wysocki]

On Wednesday 03 of October 2012 16:00:25 Kevin Hilman wrote:
> From: Kevin Hilman <khilman@ti.com>
> 
> 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.

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.

[PATCH 0/4] cpufreq: OMAP: fixes for v3.7-rc2

[Kevin Hilman]

"Rafael J. Wysocki" <rjw@sisk.pl> writes:

> On Wednesday 03 of October 2012 16:00:25 Kevin Hilman wrote:
>> From: Kevin Hilman <khilman@ti.com>
>> 
>> 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.
>
> 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, I'll get them queued.

Kevin