[PATCH v2 0/2] OMAP cpufreq fixes

[PATCH v2 0/2] OMAP cpufreq fixes

[Rajendra Nayak]

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

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

[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.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: <linux-pm@vger.kernel.org>
---
 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

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

[Rafael J. Wysocki]

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 <rnayak@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: <linux-pm@vger.kernel.org>

Kevin, are you going to merge this?

Rafael


> ---
>  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;
> 

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

[Kevin Hilman]

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

> 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 <rnayak@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> Cc: <linux-pm@vger.kernel.org>
>
> Kevin, are you going to merge this?
>

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

Kevin

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

[Rafael J. Wysocki]

On Thursday, August 09, 2012, Kevin Hilman wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> 
> > 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 <rnayak@ti.com>
> >> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> >> Cc: <linux-pm@vger.kernel.org>
> >
> > 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

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

[Kevin Hilman]

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

> On Thursday, August 09, 2012, Kevin Hilman wrote:
>> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>> 
>> > 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 <rnayak@ti.com>
>> >> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> >> Cc: <linux-pm@vger.kernel.org>
>> >
>> > 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

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

[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.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
 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

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

[Shilimkar, Santosh]

On Thu, Aug 9, 2012 at 12:38 PM, Rajendra Nayak <rnayak@ti.com> 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 <rnayak@ti.com>
> ---
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>