Re: OMAP3 migrating: partition / clock

[Arno Steffen <arno.steffen@googlemail.com>]

Thanks Paul for your help.

Switch on the  "#define DEBUG" in this both files skip almost all
kernel boot messages before this warning and gives just this: !?!

 Uncompressing Linux................ done, booting the kernel.
lock: associated clk usbtll_ick to clkdm core_l4_clkdm
Clocking rate (Crystal/Core/MPU): 12.0/332/600 MHz
------------[ cut here ]------------
WARNING: at arch/arm/mach-omap2/clock34xx.c:773
omap3_noncore_dpll_set_rate+0x1d4/0x308()
Modules linked in:
[<c002a924>] (unwind_backtrace+0x0/0xdc) from [<c004a168>]
(warn_slowpath_common+0x48/0x60)
....

I expected to get more messages, not less:
You are right, my board is running at 12 instead of 13MHz, but this
setting is (or should be) done in uboot.
I don't know what this new line withb the "lock" means. On my board
there is no USB at all.
Regards
Arno


2010/2/5 Paul Walmsley <paul@pwsan.com>:
> Hello Arno,
>
> On Thu, 4 Feb 2010, Arno Steffen wrote:
>
>> I am trying to migrate from kernel 28 to 32 on  TI OMA3. Our board is
>> derived from EVM board.
>
> ...
>
>> Also I do get this warning now while boot:
>>
>> Hierarchical RCU implementation.
>> NR_IRQS:368
>> Clocking rate (Crystal/Core/MPU): 12.0/332/500 MHz
>
> I don't have an 3530 EVM here, but I'd assume this is one difference
> between your board and the EVM, since TI usually seems to
> build boards with 26MHz HF clock (resulting in a 13MHz sys_clk).
>
>> ------------[ cut here ]------------
>> WARNING: at arch/arm/mach-omap2/clock34xx.c:773
>> omap3_noncore_dpll_set_rate+0x280/0x2c4()
>
> The above lines tell you exactly where to find the code that's emitting
> the warning.  In this case, the problem is that the DPLL rate rounding
> code picked DPLL parameters that resulted in an invalid jitter correction
> value (from _omap3_dpll_compute_freqsel()).  The caller is presumably
> omap3_clk_lock_dpll5() in clock34xx.c, which probably got inlined which is
> why it isn't showing up specifically in the backtrace.
>
> I'd first suggest confirming this by changing the '#undef DEBUG' to
> '#define DEBUG' in clock34xx.c and mach-omap2/clock.c, rebuilding, and
> sending along the output.
>
> If the above hypothesis is confirmed, and the problem is not due to some
> other bug in the code, it might be necessary to call
> _omap3_dpll_compute_freqsel() to test the freqsel value in
> _dpll_test_mult(), and reject values that result in an invalid freqsel.
>
>
>> Modules linked in:
>> [<c002a924>] (unwind_backtrace+0x0/0xdc) from [<c0049e74>]
>> (warn_slowpath_common+0x48/0x60)
>> [<c0049e74>] (warn_slowpath_common+0x48/0x60) from [<c0033d30>]
>> (omap3_noncore_dpll_set_rate+0x280/0x2c4)
>> [<c0033d30>] (omap3_noncore_dpll_set_rate+0x280/0x2c4) from
>> [<c0031674>] (omap2_clk_set_rate+0x20/0x2c)
>> [<c0031674>] (omap2_clk_set_rate+0x20/0x2c) from [<c003494c>]
>> (clk_set_rate+0x4c/0xb0)
>> [<c003494c>] (clk_set_rate+0x4c/0xb0) from [<c000e980>]
>> (omap2_clk_init+0x124/0x1a0)
>> [<c000e980>] (omap2_clk_init+0x124/0x1a0) from [<c000d6ec>]
>> (omap2_init_common_hw+0x4c/0xe0)
>> [<c000d6ec>] (omap2_init_common_hw+0x4c/0xe0) from [<c000ead8>]
>> (omap3_evm_init_irq+0x28/0x94)
>> [<c000ead8>] (omap3_evm_init_irq+0x28/0x94) from [<c000b1b0>]
>> (init_IRQ+0x30/0x40)
>> [<c000b1b0>] (init_IRQ+0x30/0x40) from [<c0008978>] (start_kernel+0x140/0x29c)
>> [<c0008978>] (start_kernel+0x140/0x29c) from [<80008034>] (0x80008034)
>> ---[ end trace 1b75b31a2719ed1c ]---
>> Reprogramming SDRC clock to 332000000 Hz
>> GPMC revision 5.0
>>
>> Do you know the reason and how to solve it?
>> Thanks & regards
>> Arno
>
>
> - Paul
>
--
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