All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2 0/2] [pm-wip/cpufreq] OMAP: CPUfreq cleanup and SMP support
@ 2011-03-14 11:38 Santosh Shilimkar
  2011-03-14 11:38 ` [PATCH v2 1/2] OMAP: cpufreq: Split OMAP1 and OMAP2PLUS CPUfreq drivers Santosh Shilimkar
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Santosh Shilimkar @ 2011-03-14 11:38 UTC (permalink / raw)
  To: linux-omap; +Cc: khilman, Santosh Shilimkar

This series is an attempt to clean-up OMAP CPUfreq driver.
	- The OMAP1 and OMAP2PLUS cpufreq support is split to avoid
	  any #ifdefery
	- The omap2plus_cupfreq support is updated to work on
	  SMP_ON_UP builds
	- SMP support is added which can be used on OMAP4

The series is generated against Kevin's latest cpufreq branch.

The following changes since commit 444a22eb04ae07aef45cd4d0154f6f2bbe76daa9:
  Kevin Hilman (1):
        cpufreq: fixup after new OPP layer merged

Santosh Shilimkar (2):
  OMAP: cpufreq: Split OMAP1 and OMAP2PLUS CPUfreq drivers.
  OMAP2PLUS: cpufreq: Add SMP support to cater OMAP4430

 arch/arm/mach-omap1/Makefile                       |    3 +
 .../cpu-omap.c => mach-omap1/omap1-cpufreq.c}      |   68 +++------
 arch/arm/mach-omap2/Makefile                       |    3 +
 .../cpu-omap.c => mach-omap2/omap2plus-cpufreq.c}  |  156 +++++++++++++-------
 arch/arm/plat-omap/Makefile                        |    1 -
 5 files changed, 128 insertions(+), 103 deletions(-)
 copy arch/arm/{plat-omap/cpu-omap.c => mach-omap1/omap1-cpufreq.c} (75%)
 rename arch/arm/{plat-omap/cpu-omap.c => mach-omap2/omap2plus-cpufreq.c} (55%)


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [PATCH v2 1/2] OMAP: cpufreq: Split OMAP1 and OMAP2PLUS CPUfreq drivers.
  2011-03-14 11:38 [PATCH v2 0/2] [pm-wip/cpufreq] OMAP: CPUfreq cleanup and SMP support Santosh Shilimkar
@ 2011-03-14 11:38 ` Santosh Shilimkar
  2011-03-14 11:38 ` [PATCH v2 2/2] OMAP2PLUS: cpufreq: Add SMP support to cater OMAP4430 Santosh Shilimkar
  2011-03-17 21:50 ` [PATCH v2 0/2] [pm-wip/cpufreq] OMAP: CPUfreq cleanup and SMP support Kevin Hilman
  2 siblings, 0 replies; 6+ messages in thread
From: Santosh Shilimkar @ 2011-03-14 11:38 UTC (permalink / raw)
  To: linux-omap; +Cc: khilman, Santosh Shilimkar, Vishwanath BS

This patch is an attempt to cleanup the #ifdeferry in the
omap CPUfreq drivers.

The split betwenn OMAP1 and OMAP2PLUS is logical because
	- OMAP1 doesn't support opp layer.
	- OMAP1 build is seperate from omap2plus.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Vishwanath BS <vishwanath.bs@ti.com>
---
 arch/arm/mach-omap1/Makefile                       |    3 +
 .../cpu-omap.c => mach-omap1/omap1-cpufreq.c}      |   68 +++++----------
 arch/arm/mach-omap2/Makefile                       |    3 +
 .../cpu-omap.c => mach-omap2/omap2plus-cpufreq.c}  |   91 ++++++++++----------
 arch/arm/plat-omap/Makefile                        |    1 -
 5 files changed, 70 insertions(+), 96 deletions(-)
 copy arch/arm/{plat-omap/cpu-omap.c => mach-omap1/omap1-cpufreq.c} (75%)
 rename arch/arm/{plat-omap/cpu-omap.c => mach-omap2/omap2plus-cpufreq.c} (76%)

diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
index ba6009f..cb2d3a6 100644
--- a/arch/arm/mach-omap1/Makefile
+++ b/arch/arm/mach-omap1/Makefile
@@ -10,6 +10,9 @@ obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
 
 obj-$(CONFIG_OMAP_32K_TIMER)	+= timer32k.o
 
+# CPUFREQ driver
+obj-$(CONFIG_CPU_FREQ) += omap1-cpufreq.o
+
 # Power Management
 obj-$(CONFIG_PM) += pm.o sleep.o pm_bus.o
 
diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/mach-omap1/omap1-cpufreq.c
similarity index 75%
copy from arch/arm/plat-omap/cpu-omap.c
copy to arch/arm/mach-omap1/omap1-cpufreq.c
index 1c1b80b..682cdc8 100644
--- a/arch/arm/plat-omap/cpu-omap.c
+++ b/arch/arm/mach-omap1/omap1-cpufreq.c
@@ -1,5 +1,5 @@
 /*
- *  linux/arch/arm/plat-omap/cpu-omap.c
+ *  OMAP1 cpufreq driver
  *
  *  CPU frequency scaling for OMAP
  *
@@ -27,31 +27,18 @@
 #include <linux/io.h>
 #include <linux/opp.h>
 
-#include <mach/hardware.h>
-#include <plat/clock.h>
 #include <asm/system.h>
 
-#if defined(CONFIG_ARCH_OMAP3) && !defined(CONFIG_OMAP_PM_NONE)
+#include <plat/clock.h>
 #include <plat/omap-pm.h>
-#include <plat/common.h>
-#endif
+
+#include <mach/hardware.h>
 
 #define VERY_HI_RATE	900000000
 
 static struct cpufreq_frequency_table *freq_table;
-
-#ifdef CONFIG_ARCH_OMAP1
-#define MPU_CLK		"mpu"
-#elif defined(CONFIG_ARCH_OMAP3)
-#define MPU_CLK		"arm_fck"
-#else
-#define MPU_CLK		"virt_prcm_set"
-#endif
-
 static struct clk *mpu_clk;
 
-/* TODO: Add support for SDRAM timing changes */
-
 static int omap_verify_speed(struct cpufreq_policy *policy)
 {
 	if (freq_table)
@@ -85,13 +72,7 @@ static int omap_target(struct cpufreq_policy *policy,
 		       unsigned int target_freq,
 		       unsigned int relation)
 {
-#ifdef CONFIG_ARCH_OMAP1
 	struct cpufreq_freqs freqs;
-#endif
-#if defined(CONFIG_ARCH_OMAP3) && !defined(CONFIG_OMAP_PM_NONE)
-	unsigned long freq;
-	struct device *mpu_dev = omap2_get_mpuss_device();
-#endif
 	int ret = 0;
 
 	/* Ensure desired rate is within allowed range.  Some govenors
@@ -101,25 +82,22 @@ static int omap_target(struct cpufreq_policy *policy,
 	if (target_freq > policy->max)
 		target_freq = policy->max;
 
-#ifdef CONFIG_ARCH_OMAP1
 	freqs.old = omap_getspeed(0);
 	freqs.new = clk_round_rate(mpu_clk, target_freq * 1000) / 1000;
 	freqs.cpu = 0;
 
 	if (freqs.old == freqs.new)
 		return ret;
+
 	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+
 #ifdef CONFIG_CPU_FREQ_DEBUG
-	printk(KERN_DEBUG "cpufreq-omap: transition: %u --> %u\n",
-	       freqs.old, freqs.new);
+	pr_info("cpufreq-omap: transition: %u --> %u\n", freqs.old, freqs.new);
 #endif
 	ret = clk_set_rate(mpu_clk, freqs.new * 1000);
+
 	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
-#elif defined(CONFIG_ARCH_OMAP3) && !defined(CONFIG_OMAP_PM_NONE)
-	freq = target_freq * 1000;
-	if (opp_find_freq_ceil(mpu_dev, &freq))
-		omap_pm_cpu_set_freq(freq);
-#endif
+
 	return ret;
 }
 
@@ -127,7 +105,7 @@ static int __init omap_cpu_init(struct cpufreq_policy *policy)
 {
 	int result = 0;
 
-	mpu_clk = clk_get(NULL, MPU_CLK);
+	mpu_clk = clk_get(NULL, "mpu");
 	if (IS_ERR(mpu_clk))
 		return PTR_ERR(mpu_clk);
 
@@ -136,13 +114,7 @@ static int __init omap_cpu_init(struct cpufreq_policy *policy)
 
 	policy->cur = policy->min = policy->max = omap_getspeed(0);
 
-	if (!cpu_is_omap34xx()) {
-		clk_init_cpufreq_table(&freq_table);
-	} else {
-		struct device *mpu_dev = omap2_get_mpuss_device();
-
-		opp_init_cpufreq_table(mpu_dev, &freq_table);
-	}
+	clk_init_cpufreq_table(&freq_table);
 
 	if (freq_table) {
 		result = cpufreq_frequency_table_cpuinfo(policy, freq_table);
@@ -184,7 +156,7 @@ static struct cpufreq_driver omap_driver = {
 	.get		= omap_getspeed,
 	.init		= omap_cpu_init,
 	.exit		= omap_cpu_exit,
-	.name		= "omap",
+	.name		= "omap1",
 	.attr		= omap_cpufreq_attr,
 };
 
@@ -193,12 +165,12 @@ static int __init omap_cpufreq_init(void)
 	return cpufreq_register_driver(&omap_driver);
 }
 
-late_initcall(omap_cpufreq_init);
-
-/*
- * if ever we want to remove this, upon cleanup call:
- *
- * cpufreq_unregister_driver()
- * cpufreq_frequency_table_put_attr()
- */
+static void __exit omap_cpufreq_exit(void)
+{
+	cpufreq_unregister_driver(&omap_driver);
+}
 
+MODULE_DESCRIPTION("cpufreq driver for OMAP1 SOCs");
+MODULE_LICENSE("GPL");
+module_init(omap_cpufreq_init);
+module_exit(omap_cpufreq_exit);
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 1c0c2b0..b1187f9 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -56,6 +56,9 @@ obj-$(CONFIG_ARCH_OMAP3)		+= opp3xxx_data.o
 obj-$(CONFIG_ARCH_OMAP4)		+= opp4xxx_data.o
 endif
 
+# CPUFREQ driver
+obj-$(CONFIG_CPU_FREQ)			+= omap2plus-cpufreq.o
+
 # Power Management
 ifeq ($(CONFIG_PM),y)
 obj-$(CONFIG_ARCH_OMAP2)		+= pm24xx.o
diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/mach-omap2/omap2plus-cpufreq.c
similarity index 76%
rename from arch/arm/plat-omap/cpu-omap.c
rename to arch/arm/mach-omap2/omap2plus-cpufreq.c
index 1c1b80b..216704e 100644
--- a/arch/arm/plat-omap/cpu-omap.c
+++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c
@@ -1,5 +1,5 @@
 /*
- *  linux/arch/arm/plat-omap/cpu-omap.c
+ *  OMAP2PLUS cpufreq driver
  *
  *  CPU frequency scaling for OMAP
  *
@@ -27,31 +27,20 @@
 #include <linux/io.h>
 #include <linux/opp.h>
 
-#include <mach/hardware.h>
-#include <plat/clock.h>
 #include <asm/system.h>
+#include <asm/smp_plat.h>
 
-#if defined(CONFIG_ARCH_OMAP3) && !defined(CONFIG_OMAP_PM_NONE)
+#include <plat/clock.h>
 #include <plat/omap-pm.h>
 #include <plat/common.h>
-#endif
+
+#include <mach/hardware.h>
 
 #define VERY_HI_RATE	900000000
 
 static struct cpufreq_frequency_table *freq_table;
-
-#ifdef CONFIG_ARCH_OMAP1
-#define MPU_CLK		"mpu"
-#elif defined(CONFIG_ARCH_OMAP3)
-#define MPU_CLK		"arm_fck"
-#else
-#define MPU_CLK		"virt_prcm_set"
-#endif
-
 static struct clk *mpu_clk;
 
-/* TODO: Add support for SDRAM timing changes */
-
 static int omap_verify_speed(struct cpufreq_policy *policy)
 {
 	if (freq_table)
@@ -85,14 +74,8 @@ static int omap_target(struct cpufreq_policy *policy,
 		       unsigned int target_freq,
 		       unsigned int relation)
 {
-#ifdef CONFIG_ARCH_OMAP1
-	struct cpufreq_freqs freqs;
-#endif
-#if defined(CONFIG_ARCH_OMAP3) && !defined(CONFIG_OMAP_PM_NONE)
-	unsigned long freq;
-	struct device *mpu_dev = omap2_get_mpuss_device();
-#endif
 	int ret = 0;
+	struct cpufreq_freqs freqs;
 
 	/* Ensure desired rate is within allowed range.  Some govenors
 	 * (ondemand) will just pass target_freq=0 to get the minimum. */
@@ -101,33 +84,48 @@ static int omap_target(struct cpufreq_policy *policy,
 	if (target_freq > policy->max)
 		target_freq = policy->max;
 
-#ifdef CONFIG_ARCH_OMAP1
 	freqs.old = omap_getspeed(0);
 	freqs.new = clk_round_rate(mpu_clk, target_freq * 1000) / 1000;
 	freqs.cpu = 0;
 
 	if (freqs.old == freqs.new)
 		return ret;
+
 	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+
 #ifdef CONFIG_CPU_FREQ_DEBUG
-	printk(KERN_DEBUG "cpufreq-omap: transition: %u --> %u\n",
-	       freqs.old, freqs.new);
+	pr_info("cpufreq-omap: transition: %u --> %u\n", freqs.old, freqs.new);
 #endif
+
 	ret = clk_set_rate(mpu_clk, freqs.new * 1000);
+
+	/*
+	 * Generic CPUFREQ driver jiffy update is under !SMP. So jiffies
+	 * won't get updated when UP machine cpufreq build with
+	 * CONFIG_SMP enabled. Below code is added only to manage that
+	 * scenario
+	 */
+	if (!is_smp())
+		loops_per_jiffy =
+			 cpufreq_scale(loops_per_jiffy, freqs.old, freqs.new);
+
 	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
-#elif defined(CONFIG_ARCH_OMAP3) && !defined(CONFIG_OMAP_PM_NONE)
-	freq = target_freq * 1000;
-	if (opp_find_freq_ceil(mpu_dev, &freq))
-		omap_pm_cpu_set_freq(freq);
-#endif
+
 	return ret;
 }
 
 static int __init omap_cpu_init(struct cpufreq_policy *policy)
 {
 	int result = 0;
+	struct device *mpu_dev;
+
+	if (cpu_is_omap24xx())
+		mpu_clk = clk_get(NULL, "virt_prcm_set");
+	else if (cpu_is_omap34xx())
+		mpu_clk = clk_get(NULL, "dpll1_ck");
+	else if (cpu_is_omap34xx())
+		mpu_clk = clk_get(NULL, "dpll_mpu_ck");
 
-	mpu_clk = clk_get(NULL, MPU_CLK);
 	if (IS_ERR(mpu_clk))
 		return PTR_ERR(mpu_clk);
 
@@ -136,13 +134,12 @@ static int __init omap_cpu_init(struct cpufreq_policy *policy)
 
 	policy->cur = policy->min = policy->max = omap_getspeed(0);
 
-	if (!cpu_is_omap34xx()) {
-		clk_init_cpufreq_table(&freq_table);
-	} else {
-		struct device *mpu_dev = omap2_get_mpuss_device();
-
-		opp_init_cpufreq_table(mpu_dev, &freq_table);
+	mpu_dev = omap2_get_mpuss_device();
+	if (!mpu_dev) {
+		pr_warning("%s: unable to get the mpu device\n", __func__);
+		return -EINVAL;
 	}
+	opp_init_cpufreq_table(mpu_dev, &freq_table);
 
 	if (freq_table) {
 		result = cpufreq_frequency_table_cpuinfo(policy, freq_table);
@@ -184,7 +181,7 @@ static struct cpufreq_driver omap_driver = {
 	.get		= omap_getspeed,
 	.init		= omap_cpu_init,
 	.exit		= omap_cpu_exit,
-	.name		= "omap",
+	.name		= "omap2plus",
 	.attr		= omap_cpufreq_attr,
 };
 
@@ -193,12 +190,12 @@ static int __init omap_cpufreq_init(void)
 	return cpufreq_register_driver(&omap_driver);
 }
 
-late_initcall(omap_cpufreq_init);
-
-/*
- * if ever we want to remove this, upon cleanup call:
- *
- * cpufreq_unregister_driver()
- * cpufreq_frequency_table_put_attr()
- */
+static void __exit omap_cpufreq_exit(void)
+{
+	cpufreq_unregister_driver(&omap_driver);
+}
 
+MODULE_DESCRIPTION("cpufreq driver for OMAP2PLUS SOCs");
+MODULE_LICENSE("GPL");
+module_init(omap_cpufreq_init);
+module_exit(omap_cpufreq_exit);
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index a4a1285..ec7862e 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -21,7 +21,6 @@ obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
 obj-$(CONFIG_OMAP_IOMMU) += iommu.o iovmm.o
 obj-$(CONFIG_OMAP_IOMMU_DEBUG) += iommu-debug.o
 
-obj-$(CONFIG_CPU_FREQ) += cpu-omap.o
 obj-$(CONFIG_OMAP_DM_TIMER) += dmtimer.o
 obj-$(CONFIG_OMAP_DEBUG_DEVICES) += debug-devices.o
 obj-$(CONFIG_OMAP_DEBUG_LEDS) += debug-leds.o
-- 
1.6.0.4


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* [PATCH v2 2/2] OMAP2PLUS: cpufreq: Add SMP support to cater OMAP4430
  2011-03-14 11:38 [PATCH v2 0/2] [pm-wip/cpufreq] OMAP: CPUfreq cleanup and SMP support Santosh Shilimkar
  2011-03-14 11:38 ` [PATCH v2 1/2] OMAP: cpufreq: Split OMAP1 and OMAP2PLUS CPUfreq drivers Santosh Shilimkar
@ 2011-03-14 11:38 ` Santosh Shilimkar
  2011-05-11  0:41   ` Menon, Nishanth
  2011-03-17 21:50 ` [PATCH v2 0/2] [pm-wip/cpufreq] OMAP: CPUfreq cleanup and SMP support Kevin Hilman
  2 siblings, 1 reply; 6+ messages in thread
From: Santosh Shilimkar @ 2011-03-14 11:38 UTC (permalink / raw)
  To: linux-omap; +Cc: khilman, Santosh Shilimkar, Vishwanath BS

On OMAP SMP configuartion, both processors share the voltage
and clock. So both CPUs needs to be scaled together and hence
needs software co-ordination.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
cc: Vishwanath BS <vishwanath.bs@ti.com>
---
 arch/arm/mach-omap2/omap2plus-cpufreq.c |   73 ++++++++++++++++++++++++++-----
 1 files changed, 62 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c b/arch/arm/mach-omap2/omap2plus-cpufreq.c
index 216704e..84caa6d 100644
--- a/arch/arm/mach-omap2/omap2plus-cpufreq.c
+++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c
@@ -26,9 +26,11 @@
 #include <linux/clk.h>
 #include <linux/io.h>
 #include <linux/opp.h>
+#include <linux/cpu.h>
 
 #include <asm/system.h>
 #include <asm/smp_plat.h>
+#include <asm/cpu.h>
 
 #include <plat/clock.h>
 #include <plat/omap-pm.h>
@@ -63,7 +65,7 @@ static unsigned int omap_getspeed(unsigned int cpu)
 {
 	unsigned long rate;
 
-	if (cpu)
+	if (cpu >= NR_CPUS)
 		return 0;
 
 	rate = clk_get_rate(mpu_clk) / 1000;
@@ -74,9 +76,13 @@ static int omap_target(struct cpufreq_policy *policy,
 		       unsigned int target_freq,
 		       unsigned int relation)
 {
-	int ret = 0;
+	int i, ret = 0;
 	struct cpufreq_freqs freqs;
 
+	/* Changes not allowed until all CPUs are online */
+	if (is_smp() && (num_online_cpus() < NR_CPUS))
+		return ret;
+
 	/* Ensure desired rate is within allowed range.  Some govenors
 	 * (ondemand) will just pass target_freq=0 to get the minimum. */
 	if (target_freq < policy->min)
@@ -84,15 +90,25 @@ static int omap_target(struct cpufreq_policy *policy,
 	if (target_freq > policy->max)
 		target_freq = policy->max;
 
-	freqs.old = omap_getspeed(0);
+	freqs.old = omap_getspeed(policy->cpu);
 	freqs.new = clk_round_rate(mpu_clk, target_freq * 1000) / 1000;
-	freqs.cpu = 0;
+	freqs.cpu = policy->cpu;
 
 	if (freqs.old == freqs.new)
 		return ret;
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	if (!is_smp()) {
+		cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+		goto set_freq;
+	}
+
+	/* notifiers */
+	for_each_cpu(i, policy->cpus) {
+		freqs.cpu = i;
+		cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	}
 
+set_freq:
 #ifdef CONFIG_CPU_FREQ_DEBUG
 	pr_info("cpufreq-omap: transition: %u --> %u\n", freqs.old, freqs.new);
 #endif
@@ -105,12 +121,33 @@ static int omap_target(struct cpufreq_policy *policy,
 	 * CONFIG_SMP enabled. Below code is added only to manage that
 	 * scenario
 	 */
-	if (!is_smp())
+	freqs.new = omap_getspeed(policy->cpu);
+	if (!is_smp()) {
 		loops_per_jiffy =
 			 cpufreq_scale(loops_per_jiffy, freqs.old, freqs.new);
+		cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+		goto skip_lpj;
+	}
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+#ifdef CONFIG_SMP
+	/*
+	 * Note that loops_per_jiffy is not updated on SMP systems in
+	 * cpufreq driver. So, update the per-CPU loops_per_jiffy value
+	 * on frequency transition. We need to update all dependent CPUs.
+	 */
+	for_each_cpu(i, policy->cpus)
+		per_cpu(cpu_data, i).loops_per_jiffy =
+			cpufreq_scale(per_cpu(cpu_data, i).loops_per_jiffy,
+					freqs.old, freqs.new);
+#endif
 
+	/* notifiers */
+	for_each_cpu(i, policy->cpus) {
+		freqs.cpu = i;
+		cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	}
+
+skip_lpj:
 	return ret;
 }
 
@@ -118,6 +155,7 @@ static int __init omap_cpu_init(struct cpufreq_policy *policy)
 {
 	int result = 0;
 	struct device *mpu_dev;
+	static cpumask_var_t cpumask;
 
 	if (cpu_is_omap24xx())
 		mpu_clk = clk_get(NULL, "virt_prcm_set");
@@ -129,12 +167,12 @@ static int __init omap_cpu_init(struct cpufreq_policy *policy)
 	if (IS_ERR(mpu_clk))
 		return PTR_ERR(mpu_clk);
 
-	if (policy->cpu != 0)
+	if (policy->cpu >= NR_CPUS)
 		return -EINVAL;
 
-	policy->cur = policy->min = policy->max = omap_getspeed(0);
-
+	policy->cur = policy->min = policy->max = omap_getspeed(policy->cpu);
 	mpu_dev = omap2_get_mpuss_device();
+
 	if (!mpu_dev) {
 		pr_warning("%s: unable to get the mpu device\n", __func__);
 		return -EINVAL;
@@ -154,7 +192,20 @@ static int __init omap_cpu_init(struct cpufreq_policy *policy)
 
 	policy->min = policy->cpuinfo.min_freq;
 	policy->max = policy->cpuinfo.max_freq;
-	policy->cur = omap_getspeed(0);
+	policy->cur = omap_getspeed(policy->cpu);
+
+	/*
+	 * On OMAP SMP configuartion, both processors share the voltage
+	 * and clock. So both CPUs needs to be scaled together and hence
+	 * needs software co-ordination. Use cpufreq affected_cpus
+	 * interface to handle this scenario. Additional is_smp() check
+	 * is to keep SMP_ON_UP build working.
+	 */
+	if (is_smp()) {
+		policy->shared_type = CPUFREQ_SHARED_TYPE_ANY;
+		cpumask_or(cpumask, cpumask_of(policy->cpu), cpumask);
+		cpumask_copy(policy->cpus, cpumask);
+	}
 
 	/* FIXME: what's the actual transition time? */
 	policy->cpuinfo.transition_latency = 300 * 1000;
-- 
1.6.0.4


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH v2 0/2] [pm-wip/cpufreq] OMAP: CPUfreq cleanup and SMP support
  2011-03-14 11:38 [PATCH v2 0/2] [pm-wip/cpufreq] OMAP: CPUfreq cleanup and SMP support Santosh Shilimkar
  2011-03-14 11:38 ` [PATCH v2 1/2] OMAP: cpufreq: Split OMAP1 and OMAP2PLUS CPUfreq drivers Santosh Shilimkar
  2011-03-14 11:38 ` [PATCH v2 2/2] OMAP2PLUS: cpufreq: Add SMP support to cater OMAP4430 Santosh Shilimkar
@ 2011-03-17 21:50 ` Kevin Hilman
  2 siblings, 0 replies; 6+ messages in thread
From: Kevin Hilman @ 2011-03-17 21:50 UTC (permalink / raw)
  To: Santosh Shilimkar; +Cc: linux-omap

Santosh Shilimkar <santosh.shilimkar@ti.com> writes:

> This series is an attempt to clean-up OMAP CPUfreq driver.
> 	- The OMAP1 and OMAP2PLUS cpufreq support is split to avoid
> 	  any #ifdefery
> 	- The omap2plus_cupfreq support is updated to work on
> 	  SMP_ON_UP builds
> 	- SMP support is added which can be used on OMAP4
>
> The series is generated against Kevin's latest cpufreq branch.

Thanks, adding to pm-wip/cpufreq branch.

Kevin

> The following changes since commit 444a22eb04ae07aef45cd4d0154f6f2bbe76daa9:
>   Kevin Hilman (1):
>         cpufreq: fixup after new OPP layer merged
>
> Santosh Shilimkar (2):
>   OMAP: cpufreq: Split OMAP1 and OMAP2PLUS CPUfreq drivers.
>   OMAP2PLUS: cpufreq: Add SMP support to cater OMAP4430
>
>  arch/arm/mach-omap1/Makefile                       |    3 +
>  .../cpu-omap.c => mach-omap1/omap1-cpufreq.c}      |   68 +++------
>  arch/arm/mach-omap2/Makefile                       |    3 +
>  .../cpu-omap.c => mach-omap2/omap2plus-cpufreq.c}  |  156 +++++++++++++-------
>  arch/arm/plat-omap/Makefile                        |    1 -
>  5 files changed, 128 insertions(+), 103 deletions(-)
>  copy arch/arm/{plat-omap/cpu-omap.c => mach-omap1/omap1-cpufreq.c} (75%)
>  rename arch/arm/{plat-omap/cpu-omap.c => mach-omap2/omap2plus-cpufreq.c} (55%)

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v2 2/2] OMAP2PLUS: cpufreq: Add SMP support to cater OMAP4430
  2011-03-14 11:38 ` [PATCH v2 2/2] OMAP2PLUS: cpufreq: Add SMP support to cater OMAP4430 Santosh Shilimkar
@ 2011-05-11  0:41   ` Menon, Nishanth
  2011-05-11  7:10     ` Santosh Shilimkar
  0 siblings, 1 reply; 6+ messages in thread
From: Menon, Nishanth @ 2011-05-11  0:41 UTC (permalink / raw)
  To: Santosh Shilimkar
  Cc: linux-omap, khilman, Vishwanath BS, Herman, Saquib, Revanna, Amarnath

On Mon, Mar 14, 2011 at 06:38, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
> On OMAP SMP configuartion, both processors share the voltage
> and clock. So both CPUs needs to be scaled together and hence
> needs software co-ordination.
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Kevin Hilman <khilman@ti.com>
> cc: Vishwanath BS <vishwanath.bs@ti.com>
> ---
>  arch/arm/mach-omap2/omap2plus-cpufreq.c |   73 ++++++++++++++++++++++++++-----
>  1 files changed, 62 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c b/arch/arm/mach-omap2/omap2plus-cpufreq.c

[...]
>        rate = clk_get_rate(mpu_clk) / 1000;
> @@ -74,9 +76,13 @@ static int omap_target(struct cpufreq_policy *policy,
[...]

> -       cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
> +#ifdef CONFIG_SMP
> +       /*
> +        * Note that loops_per_jiffy is not updated on SMP systems in
> +        * cpufreq driver. So, update the per-CPU loops_per_jiffy value
> +        * on frequency transition. We need to update all dependent CPUs.
> +        */
> +       for_each_cpu(i, policy->cpus)
> +               per_cpu(cpu_data, i).loops_per_jiffy =
> +                       cpufreq_scale(per_cpu(cpu_data, i).loops_per_jiffy,
> +                                       freqs.old, freqs.new);
We have an issue here - arch/arm/lib/delay.S uses the generic
loops_per_jiffy which is not updated when smp (OMAP4) is active, as a
result loops_per_jiffy contains the value which was updated. with a
trace added as follows:
diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c
b/arch/arm/mach-omap2/omap2plus-cpufreq.c
index 0105c8d..8bad854 100644
--- a/arch/arm/mach-omap2/omap2plus-cpufreq.c
+++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c
@@ -137,10 +137,14 @@ set_freq:
         * cpufreq driver. So, update the per-CPU loops_per_jiffy value
         * on frequency transition. We need to update all dependent CPUs.
         */
-       for_each_cpu(i, policy->cpus)
+       for_each_cpu(i, policy->cpus) {
                per_cpu(cpu_data, i).loops_per_jiffy =
                        cpufreq_scale(per_cpu(cpu_data, i).loops_per_jiffy,
                                        freqs.old, freqs.new);
+               pr_err("%s: loops_per_jiffy=%lu cpu%d.loops_per_jiffy=%d\n",
+                               __func__, loops_per_jiffy, i,
+                               per_cpu(cpu_data, i).loops_per_jiffy);
+       }
 #endif

Testing:600000 freq
[   30.319885] omap_target: loops_per_jiffy=7643136 cpu0.loops_per_jiffy=4666514
[   30.327758] omap_target: loops_per_jiffy=7643136 cpu1.loops_per_jiffy=4549484
testing:800000
[   31.419616] omap_target: loops_per_jiffy=7643136 cpu0.loops_per_jiffy=6222018
[   31.427612] omap_target: loops_per_jiffy=7643136 cpu1.loops_per_jiffy=6065978
testing:1008000
[   32.532012] omap_target: loops_per_jiffy=7643136 cpu0.loops_per_jiffy=7839742
[   32.540252] omap_target: loops_per_jiffy=7643136 cpu1.loops_per_jiffy=7643132

Luckily my bootloader was booting up at 1GHz, but for folks booting at
OPP100, well.. at 1GHz, the mdelays and udelays are going to be wrong
badly.

With a quick patch as follows (by Amarnath/Saquib), the output is:
testing:600000
[   27.499603] omap_target: loops_per_jiffy=4666514 cpu0.loops_per_jiffy=4666514
[   27.507507] omap_target: loops_per_jiffy=4666514 cpu1.loops_per_jiffy=4549484
testing:800000
[   28.617553] omap_target: loops_per_jiffy=6222018 cpu0.loops_per_jiffy=6222018
[   28.625518] omap_target: loops_per_jiffy=6222018 cpu1.loops_per_jiffy=6065978
testing:1008000
[   29.724578] omap_target: loops_per_jiffy=7839742 cpu0.loops_per_jiffy=7839742
[   29.732818] omap_target: loops_per_jiffy=7839742 cpu1.loops_per_jiffy=7643132

patch:
diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c
b/arch/arm/mach-omap2/omap2plus-cpufreq.c
index 0105c8d..58a968d 100644
--- a/arch/arm/mach-omap2/omap2plus-cpufreq.c
+++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c
@@ -80,6 +80,7 @@ static int omap_target(struct cpufreq_policy *policy,
        int i, ret = 0;
        struct cpufreq_freqs freqs;
        struct device *mpu_dev = omap2_get_mpuss_device();
+       unsigned int jiffy_loop_cpu = 0;

        /* Changes not allowed until all CPUs are online */
        if (is_smp() && (num_online_cpus() < NR_CPUS))
@@ -137,10 +138,14 @@ set_freq:
         * cpufreq driver. So, update the per-CPU loops_per_jiffy value
         * on frequency transition. We need to update all dependent CPUs.
         */
-       for_each_cpu(i, policy->cpus)
+       for_each_cpu(i, policy->cpus) {
                per_cpu(cpu_data, i).loops_per_jiffy =
                        cpufreq_scale(per_cpu(cpu_data, i).loops_per_jiffy,
                                        freqs.old, freqs.new);
+               if (per_cpu(cpu_data, i).loops_per_jiffy > jiffy_loop_cpu)
+                       jiffy_loop_cpu = per_cpu(cpu_data, i).loops_per_jiffy;
+       }
+       loops_per_jiffy = jiffy_loop_cpu;
 #endif

        /* notifiers */

Question: what would be the best solution for this? is a solution
isolated to OMAP good enough?

Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH v2 2/2] OMAP2PLUS: cpufreq: Add SMP support to cater OMAP4430
  2011-05-11  0:41   ` Menon, Nishanth
@ 2011-05-11  7:10     ` Santosh Shilimkar
  0 siblings, 0 replies; 6+ messages in thread
From: Santosh Shilimkar @ 2011-05-11  7:10 UTC (permalink / raw)
  To: Menon, Nishanth
  Cc: linux-omap, khilman, Vishwanath BS, Herman, Saquib, Revanna, Amarnath

On 5/11/2011 6:11 AM, Menon, Nishanth wrote:
> On Mon, Mar 14, 2011 at 06:38, Santosh Shilimkar
> <santosh.shilimkar@ti.com>  wrote:
>> On OMAP SMP configuartion, both processors share the voltage
>> and clock. So both CPUs needs to be scaled together and hence
>> needs software co-ordination.
>>
>> Signed-off-by: Santosh Shilimkar<santosh.shilimkar@ti.com>
>> Cc: Kevin Hilman<khilman@ti.com>
>> cc: Vishwanath BS<vishwanath.bs@ti.com>
>> ---
>>   arch/arm/mach-omap2/omap2plus-cpufreq.c |   73 ++++++++++++++++++++++++++-----
>>   1 files changed, 62 insertions(+), 11 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c b/arch/arm/mach-omap2/omap2plus-cpufreq.c
>
> [...]
>>         rate = clk_get_rate(mpu_clk) / 1000;
>> @@ -74,9 +76,13 @@ static int omap_target(struct cpufreq_policy *policy,
> [...]
>
>> -       cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
>> +#ifdef CONFIG_SMP
>> +       /*
>> +        * Note that loops_per_jiffy is not updated on SMP systems in
>> +        * cpufreq driver. So, update the per-CPU loops_per_jiffy value
>> +        * on frequency transition. We need to update all dependent CPUs.
>> +        */
>> +       for_each_cpu(i, policy->cpus)
>> +               per_cpu(cpu_data, i).loops_per_jiffy =
>> +                       cpufreq_scale(per_cpu(cpu_data, i).loops_per_jiffy,
>> +                                       freqs.old, freqs.new);
> We have an issue here - arch/arm/lib/delay.S uses the generic
> loops_per_jiffy which is not updated when smp (OMAP4) is active, as a
> result loops_per_jiffy contains the value which was updated. with a
> trace added as follows:

[...]

>
> Question: what would be the best solution for this? is a solution
> isolated to OMAP good enough?
>
We have debated on the global lpj update topic enough. The assumption
of all the CPU's in ARM SMP system are running at same speed in not

I propose this idea based on the fact that on OMAP we scale
all the CPU's in SMP clusture together. But that is not seems
to be true for all ARM SMP archs.

So there is a patch series which makes udelay() independent
of lpj and make use a timer.

Here is the link for the same.
http://eeek.borgchat.net/lists/arm-kernel/msg120702.html

Regards
Santosh

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2011-05-11 15:52 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-03-14 11:38 [PATCH v2 0/2] [pm-wip/cpufreq] OMAP: CPUfreq cleanup and SMP support Santosh Shilimkar
2011-03-14 11:38 ` [PATCH v2 1/2] OMAP: cpufreq: Split OMAP1 and OMAP2PLUS CPUfreq drivers Santosh Shilimkar
2011-03-14 11:38 ` [PATCH v2 2/2] OMAP2PLUS: cpufreq: Add SMP support to cater OMAP4430 Santosh Shilimkar
2011-05-11  0:41   ` Menon, Nishanth
2011-05-11  7:10     ` Santosh Shilimkar
2011-03-17 21:50 ` [PATCH v2 0/2] [pm-wip/cpufreq] OMAP: CPUfreq cleanup and SMP support Kevin Hilman

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.