[PATCH v2 0/2] OMAP cpufreq fixes

Changes in v2:
Fixed the handling of freq_table_users in Patch 1/2 as
suggested by Santosh. Patch 2/2 is unchanged.

Hi Kevin,

While testing cpufreq on 3.6-rc1, I noticed strange issues on OMAP4,
like a lockup when booting with 'performace' governer as default,
and crashes when using 'usespace' (which booted up) and switching
to higher OPPs.
It took me a while to realise I was using a 4460 device. The OPPs
registered though seemed to be for 4430 and hence were causing
issues on the 4460 device. 

This series basically avoids registering the 4430 OPPs on other
varients like 4460 and 4470 (and hence causing random issues)
and also fixes a subsequent bug uncovered by doing this in
OMAP cpufreq driver.

regards,
Rajendra 

Rajendra Nayak (2):
  cpufreq: OMAP: Handle missing frequency table on SMP systems
  ARM: OMAP4: Register the OPP table only for 4430 device

 arch/arm/mach-omap2/opp4xxx_data.c |    2 +-
 drivers/cpufreq/omap-cpufreq.c     |    4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)

-- 
1.7.9.5

On OMAP4, if the first CPU fails to get a valid frequency table (this
could happen if the platform does not register any OPP table), the
subsequent CPU instances end up dealing with a NULL freq_table and
crash.

Check for an already existing freq_table, before trying to create one,
and increment the freq_table_users only if the table is sucessfully
created.

Signed-off-by: Rajendra Nayak <redacted>
Signed-off-by: Santosh Shilimkar <redacted>
Cc: <redacted>
---
 drivers/cpufreq/omap-cpufreq.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 17fa04d..b47034e 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c

@@ -218,7 +218,7 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy *policy)
 
 	policy->cur = policy->min = policy->max = omap_getspeed(policy->cpu);
 
-	if (atomic_inc_return(&freq_table_users) == 1)
+	if (!freq_table)
 		result = opp_init_cpufreq_table(mpu_dev, &freq_table);
 
 	if (result) {

@@ -227,6 +227,8 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy *policy)
 		goto fail_ck;
 	}
 
+	atomic_inc_return(&freq_table_users);
+
 	result = cpufreq_frequency_table_cpuinfo(policy, freq_table);
 	if (result)
 		goto fail_table;

-- 
1.7.9.5

The 4430 OPP table was being registered for all other OMAP4 variants
too, like 4460 and 4470 causing issues with cpufreq driver
enabled. 4460 and 4470 devices have different OPPs as compared to
4430, and they should be populated seperately. As long as that
happens, let the OPP table registeration happen only on 4430 device.

Signed-off-by: Rajendra Nayak <redacted>
---
 arch/arm/mach-omap2/opp4xxx_data.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/opp4xxx_data.c b/arch/arm/mach-omap2/opp4xxx_data.c
index 2293ba2..c95415d 100644
--- a/arch/arm/mach-omap2/opp4xxx_data.c
+++ b/arch/arm/mach-omap2/opp4xxx_data.c

@@ -94,7 +94,7 @@ int __init omap4_opp_init(void)
 {
 	int r = -ENODEV;
 
-	if (!cpu_is_omap44xx())
+	if (!cpu_is_omap443x())
 		return r;
 
 	r = omap_init_opp_table(omap44xx_opp_def_list,

-- 
1.7.9.5

On Thu, Aug 9, 2012 at 12:38 PM, Rajendra Nayak [off-list ref] wrote:

The 4430 OPP table was being registered for all other OMAP4 variants
too, like 4460 and 4470 causing issues with cpufreq driver
enabled. 4460 and 4470 devices have different OPPs as compared to
4430, and they should be populated seperately. As long as that
happens, let the OPP table registeration happen only on 4430 device.

Signed-off-by: Rajendra Nayak <redacted>
---

Acked-by: Santosh Shilimkar <redacted>

On Thursday, August 09, 2012, Rajendra Nayak wrote:

On OMAP4, if the first CPU fails to get a valid frequency table (this
could happen if the platform does not register any OPP table), the
subsequent CPU instances end up dealing with a NULL freq_table and
crash.

Check for an already existing freq_table, before trying to create one,
and increment the freq_table_users only if the table is sucessfully
created.

Signed-off-by: Rajendra Nayak <redacted>
Signed-off-by: Santosh Shilimkar <redacted>
Cc: <redacted>

Kevin, are you going to merge this?

Rafael