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

2012-06-18 Thread Paul Walmsley 
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-hun...@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 majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 


- Paul

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

2012-06-07 Thread 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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html