[RFC] ARM: OMAP4470: Fix OMAP4470 boot failure

[RFC] ARM: OMAP4470: Fix OMAP4470 boot failure

[Jon Hunter]

OMAP4470 currently fails to boot, printing various messages such as ...

omap_hwmod: mpu: cannot clk_get main_clk dpll_mpu_m2_ck
omap_hwmod: mpu: cannot _init_clocks
------------[ cut here ]------------
WARNING: at arch/arm/mach-omap2/omap_hwmod.c:2062 _init+0x2a0/0x2e4()
omap_hwmod: mpu: couldn't init clocks
Modules linked in:
[<c001c7fc>] (unwind_backtrace+0x0/0xf4) from [<c0043c64>] (warn_slowpath_common+0x4c/0x64)
[<c0043c64>] (warn_slowpath_common+0x4c/0x64) from [<c0043d10>] (warn_slowpath_fmt+0x30/0x40)
[<c0043d10>] (warn_slowpath_fmt+0x30/0x40) from [<c0674208>] (_init+0x2a0/0x2e4)
[<c0674208>] (_init+0x2a0/0x2e4) from [<c067428c>] (omap_hwmod_setup_one+0x40/0x60)
[<c067428c>] (omap_hwmod_setup_one+0x40/0x60) from [<c0674280>] (omap_hwmod_setup_one+0x34/0x60)
[<c0674280>] (omap_hwmod_setup_one+0x34/0x60) from [<c06726f4>] (omap_dm_timer_init_one+0x30/0x250)
[<c06726f4>] (omap_dm_timer_init_one+0x30/0x250) from [<c0672930>] (omap2_gp_clockevent_init+0x1c/0x108)
[<c0672930>] (omap2_gp_clockevent_init+0x1c/0x108) from [<c0672c60>] (omap4_timer_init+0x10/0x5c)
[<c0672c60>] (omap4_timer_init+0x10/0x5c) from [<c066c418>] (time_init+0x20/0x30)
[<c066c418>] (time_init+0x20/0x30) from [<c0668814>] (start_kernel+0x1b0/0x304)
[<c0668814>] (start_kernel+0x1b0/0x304) from [<80008044>] (0x80008044)
---[ end trace 1b75b31a2719ed1c ]---

The problem is that currently none of the clocks are being registered for
OMAP4470 devices and so on boot-up no clocks can be found and the kernel panics.

This fix always the kernel to boot without failure using a simple RAMDISK file
system. However, I need some inputs from the clock guru's if this is the
correct fix :-)

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
 arch/arm/mach-omap2/clock44xx_data.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-omap2/clock44xx_data.c
index 2172f66..19275e8 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3412,7 +3412,7 @@ int __init omap4xxx_clk_init(void)
 	if (cpu_is_omap443x()) {
 		cpu_mask = RATE_IN_4430;
 		cpu_clkflg = CK_443X;
-	} else if (cpu_is_omap446x()) {
+	} else if (cpu_is_omap446x() || cpu_is_omap447x()) {
 		cpu_mask = RATE_IN_4460 | RATE_IN_4430;
 		cpu_clkflg = CK_446X | CK_443X;
 	} else {
-- 
1.7.9.5

Re: [RFC] ARM: OMAP4470: Fix OMAP4470 boot failure

[Jon Hunter]

On 06/07/2012 06:00 PM, Jon Hunter wrote:
> OMAP4470 currently fails to boot, printing various messages such as ...
> 
> omap_hwmod: mpu: cannot clk_get main_clk dpll_mpu_m2_ck
> omap_hwmod: mpu: cannot _init_clocks
> ------------[ cut here ]------------
> WARNING: at arch/arm/mach-omap2/omap_hwmod.c:2062 _init+0x2a0/0x2e4()
> omap_hwmod: mpu: couldn't init clocks
> Modules linked in:
> [<c001c7fc>] (unwind_backtrace+0x0/0xf4) from [<c0043c64>] (warn_slowpath_common+0x4c/0x64)
> [<c0043c64>] (warn_slowpath_common+0x4c/0x64) from [<c0043d10>] (warn_slowpath_fmt+0x30/0x40)
> [<c0043d10>] (warn_slowpath_fmt+0x30/0x40) from [<c0674208>] (_init+0x2a0/0x2e4)
> [<c0674208>] (_init+0x2a0/0x2e4) from [<c067428c>] (omap_hwmod_setup_one+0x40/0x60)
> [<c067428c>] (omap_hwmod_setup_one+0x40/0x60) from [<c0674280>] (omap_hwmod_setup_one+0x34/0x60)
> [<c0674280>] (omap_hwmod_setup_one+0x34/0x60) from [<c06726f4>] (omap_dm_timer_init_one+0x30/0x250)
> [<c06726f4>] (omap_dm_timer_init_one+0x30/0x250) from [<c0672930>] (omap2_gp_clockevent_init+0x1c/0x108)
> [<c0672930>] (omap2_gp_clockevent_init+0x1c/0x108) from [<c0672c60>] (omap4_timer_init+0x10/0x5c)
> [<c0672c60>] (omap4_timer_init+0x10/0x5c) from [<c066c418>] (time_init+0x20/0x30)
> [<c066c418>] (time_init+0x20/0x30) from [<c0668814>] (start_kernel+0x1b0/0x304)
> [<c0668814>] (start_kernel+0x1b0/0x304) from [<80008044>] (0x80008044)
> ---[ end trace 1b75b31a2719ed1c ]---
> 
> The problem is that currently none of the clocks are being registered for
> OMAP4470 devices and so on boot-up no clocks can be found and the kernel panics.
> 
> This fix always the kernel to boot without failure using a simple RAMDISK file

I am embarrassed to say that English is my first language and the above
should read "this fix ALLOWS" :-)

Jon

Re: [RFC] ARM: OMAP4470: Fix OMAP4470 boot failure

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1846 bytes --]

Hi Jon,

On Thu, 7 Jun 2012, Jon Hunter wrote:

> The problem is that currently none of the clocks are being registered for
> OMAP4470 devices and so on boot-up no clocks can be found and the kernel panics.
> 
> This fix always the kernel to boot without failure using a simple RAMDISK file
> system. However, I need some inputs from the clock guru's if this is the
> correct fix :-)
> 
> Signed-off-by: Jon Hunter <jon-hunter@ti.com>

I guess Benoît should make the call on this, since he's got access to the 
hardware data to use to autogenerate these clocks.  If there aren't any 
differences between the 4460 and 4470 clocks and dividers, then your 
patch looks good to me.  

If there are any differences between the 4460 and 4470 clocks and 
dividers, we should probably wait until the common clock conversion is 
complete, since that would presumably be a large change.

Just my 2 cents, 

- Paul


> ---
>  arch/arm/mach-omap2/clock44xx_data.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-omap2/clock44xx_data.c
> index 2172f66..19275e8 100644
> --- a/arch/arm/mach-omap2/clock44xx_data.c
> +++ b/arch/arm/mach-omap2/clock44xx_data.c
> @@ -3412,7 +3412,7 @@ int __init omap4xxx_clk_init(void)
>  	if (cpu_is_omap443x()) {
>  		cpu_mask = RATE_IN_4430;
>  		cpu_clkflg = CK_443X;
> -	} else if (cpu_is_omap446x()) {
> +	} else if (cpu_is_omap446x() || cpu_is_omap447x()) {
>  		cpu_mask = RATE_IN_4460 | RATE_IN_4430;
>  		cpu_clkflg = CK_446X | CK_443X;
>  	} else {
> -- 
> 1.7.9.5
> 
> --
> 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
> 


- Paul