OMAP3 migrating: partition / clock

OMAP3 migrating: partition / clock

[Arno Steffen]

I am trying to migrate from kernel 28 to 32 on  TI OMA3. Our board is
derived from EVM board.
In new kernel I can't see the partitions in flash, and found no file
to set them.

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
------------[ cut here ]------------
WARNING: at arch/arm/mach-omap2/clock34xx.c:773
omap3_noncore_dpll_set_rate+0x280/0x2c4()
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

Re: OMAP3 migrating: partition / clock

[Paul Walmsley]

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

Re: OMAP3 migrating: partition / clock

[Arno Steffen]

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

Re: OMAP3 migrating: partition / clock

[Paul Walmsley]

On Mon, 8 Feb 2010, Arno Steffen wrote:

> 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: !?!

You probably need to enable CONFIG_DEBUG_LL to see all of the messages.

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

The leading "c" was apparently dropped.  You can recursively grep through 
the source tree to locate messages, if you are curious as to where they 
come from.

> On my board there is no USB at all.

If you're not using any of the DPLL5-connected devices (USB, USIM, etc.), 
what happens if you comment out the omap3_clk_lock_dpll5() call in 
clock34xx.c?  This is not a proper fix, of course, but it may help narrow 
down the problem.


- Paul

Re: OMAP3 migrating: partition / clock

[Arno Steffen]

2010/2/8 Paul Walmsley <paul@pwsan.com>:
> On Mon, 8 Feb 2010, Arno Steffen wrote:
>
>> 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: !?!
>
> You probably need to enable CONFIG_DEBUG_LL to see all of the messages.
>
>>  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.
>
> The leading "c" was apparently dropped.  You can recursively grep through
> the source tree to locate messages, if you are curious as to where they
> come from.
>
>> On my board there is no USB at all.
>
> If you're not using any of the DPLL5-connected devices (USB, USIM, etc.),
> what happens if you comment out the omap3_clk_lock_dpll5() call in
> clock34xx.c?  This is not a proper fix, of course, but it may help narrow
> down the problem.
> - Paul

Thanks Paul!

Sorry for bothering you again:
Although I set "#define DEBUG" in clock.c and clock34xx.c and checked
that kernel has been new compiled with "CONFIG_DEBUG_LL=y" the debub
messages are quite strange.

Uncompressing Linux................. done, booting the kernel.
kout2_src_ck to clkdm core_clkdm
Clocking rate (Crystal/Core/MPU): 12.0/332/600 MHz
Reprogramming SDRC clock to 332000000 Hz
GPMC revision 5.0
...

This strange behaviour is just happend if I do a "#define DEBUG" in clock.c.
Changing the debug setting in clock34xx.c has no effect at all ?!?

Anyhow there are good news too:
I removed the call of omap3_clk_lock_dpll5() and you are right - the
message disappers. How did you know that?
This call
clk_set_rate(dpll5_clk, DPLL5_FREQ_FOR_USBHOST);
causes the first message, and thus I assume that dpll5_clk might be
wrong, which is get by this command:
dpll5_clk = clk_get(NULL, "dpll5_ck");

I could live with this workaround (remove the call), but have to be
sure, that clock is not powered (save energy).

Best regards
Arno
--
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