Skip to contentSkip to conversation

OMAP cpufreq fixes

PATCH New Rajendra Nayak 4 participants 8 messages Aug 9, 2012

Subsystems (4)
lore
Share & tools
lore
#0 lore raw

v2 cover 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(-)
Signature · 1 line
1.7.9.5
#1 lore raw

PATCH v2 1/2 cpufreq: OMAP: Handle missing frequency table on SMP systems

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.

---
 drivers/cpufreq/omap-cpufreq.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/cpufreq/omap-cpufreq.c +3 -1
index 17fa04d..b47034e 100644
@@ -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;
Signature · 1 line
1.7.9.5
#2 lore raw

PATCH v2 1/2 cpufreq: OMAP: Handle missing frequency table on SMP systems

Quoted 5 lines · Rajendra Nayak

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.

Quoted 7 lines

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.

Kevin, are you going to merge this?

Rafael

Quoted 27 lines
---
 drivers/cpufreq/omap-cpufreq.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/cpufreq/omap-cpufreq.c +3 -1
index 17fa04d..b47034e 100644
@@ -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;
#3 lore raw

PATCH v2 1/2 cpufreq: OMAP: Handle missing frequency table on SMP systems

Quoted 10 lines · Rafael J. Wysocki
Quoted 9 lines · Rajendra Nayak

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.

Quoted 6 lines
Quoted 3 lines

Kevin, are you going to merge this?

Yes, I plan to queue this with 2/2 for v3.6-rc.

Kevin

#4 lore raw

PATCH v2 1/2 cpufreq: OMAP: Handle missing frequency table on SMP systems

Quoted 12 lines · Kevin Hilman
Quoted 10 lines · Rafael J. Wysocki
Quoted 9 lines · Rajendra Nayak

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.

Quoted 8 lines
Quoted 6 lines
Quoted 3 lines

Kevin, are you going to merge this?

Yes, I plan to queue this with 2/2 for v3.6-rc.

If you have any cpufreq patches for v3.7, can you please tell me where to pull them from (and when)?

Rafael

#5 lore raw

PATCH v2 1/2 cpufreq: OMAP: Handle missing frequency table on SMP systems

Quoted 17 lines · Rafael J. Wysocki
Quoted 16 lines · Kevin Hilman
Quoted 14 lines · Rafael J. Wysocki
Quoted 12 lines · Rajendra Nayak

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.

Quoted 7 lines
Quoted 4 lines
Quoted 2 lines

Kevin, are you going to merge this?

Yes, I plan to queue this with 2/2 for v3.6-rc.

If you have any cpufreq patches for v3.7, can you please tell me where to pull them from (and when)?

Yes, I will.

Thanks,

Kevin

#6 lore raw

PATCH v2 2/2 ARM: OMAP4: Register the OPP table only for 4430 device

In reply to Rajendra Nayak

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.

---
 arch/arm/mach-omap2/opp4xxx_data.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/mach-omap2/opp4xxx_data.c +1 -1
index 2293ba2..c95415d 100644
@@ -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,
Signature · 1 line
1.7.9.5
#7 lore raw

PATCH v2 2/2 ARM: OMAP4: Register the OPP table only for 4430 device

Quoted 8 lines · Rajendra Nayak

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.

---