Paul
>-----Original Message-----
>Sent: Thursday, December 20, 2007 6:48 PM
>
>Paul
>Another problem:
>
The cause is the following check:
The GPT2 registers lie PER and the check is a hard coded value of CORE_MOD
The correct check for GPT2 should be OMAP_CM_REGADDR(OMAP3430_PER_MOD, CM_FCLKEN)
So the function returns in the following check.
static void omap2_clk_wait_ready(struct clk *clk)
{
[snip]
reg = clk->enable_reg;
if (reg == OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1) ||
reg == OMAP_CM_REGADDR(CORE_MOD, OMAP24XX_CM_FCLKEN2))
other_reg = (void __iomem *)(((u32)reg & ~0xf0) | 0x10); /* CM_ICLKEN* */
else if (reg == OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN1) ||
reg == OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN2))
other_reg = (void __iomem *)(((u32)reg & ~0xf0) | 0x00); /* CM_FCLKEN* */
else
return;
[snip]
>>Sent: Thursday, December 20, 2007 3:53 PM
>>
>>> Tried and ES2.0 boots now.
>>
>>Great, thanks for your help. I'll respin those patches with the fix
>>included.
>
>
>Another problem I am observing in your clock patch is that occasionally there is a crash as follows
>in dm timer:
>
>[SNIP]
><7>cm_write_reg: writing 0x3ffff to 0xd8005010
>
><7>cm_write_reg: writing 0x3fff7 to 0xd8005000
>
><7>clock: in omap2_get_clksel_by_parent: clk gpt2_fck
>
><7>clock: in omap2_get_clksel_by_parent: looking for parent clk omap_32k_fck
>
><7>clock: set parent of gpt2_fck to omap_32k_fck (new rate 32768)
>
><7>cm_write_reg: writing 0x3ffff to 0xd8005000
>
><1>Unhandled fault: external abort on non-linefetch (0x1028) at 0xd9032010
>
>Internal error: : 1028 [#1]
>
>Modules linked in:
>
>CPU: 0 Not tainted (2.6.24-rc5-omap1-g047c6b0c-dirty #52)
>
>PC is at omap_dm_timer_reset+0x78/0xbc
>
>LR is at omap_dm_timer_set_source+0x48/0x54
>
>pc : [<c003ed34>] lr : [<c003ecb0>] psr: 600001d3
>
>sp : c02bff40 ip : c02c9840 fp : c02bff54
>
>r10: c02c419c r9 : 411fc081 r8 : 80020634
>
>r7 : 00000000 r6 : c02c41c0 r5 : 89705f41 r4 : c02c923c
>
>r3 : d9032000 r2 : c02c9224 r1 : d8005000 r0 : 00000000
>
>Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel
>
>Control: 00c5387f Table: 80004018 DAC: 00000017
>
>Process swapper (pid: 0, stack limit = 0xc02be2d8)
>
>Stack: (0xc02bff40 to 0xc02c0000)
>
>ff40: c02c923c 89705f41 c02bff6c c02bff58 c003ed98 c003ecc8 c005f9f4 c02c923c
>
>ff60: c02bff84 c02bff70 c003ee00 c003ed84 00c65d40 36b4a597 c02bffb4 c02bff88
>
>ff80: c0011638 c003eda8 c02bffc4 c02e3404 c02e3410 c0021f28 c02c1d68 80020634
>
>ffa0: 411fc081 0000001f c02bffc4 c02bffb8 c000f8fc c001154c c02bfff4 c02bffc8
>
>ffc0: c0008c74 c000f8ec c0008544 00000000 00000000 c0021f28 00000000 00c5387d
>
>ffe0: c02e3d10 c002232c 00000000 c02bfff8 80008034 c0008b18 00000000 00000000
>
>Backtrace:
>
>[<c003ecbc>] (omap_dm_timer_reset+0x0/0xbc) from [<c003ed98>] (omap_dm_timer_prepare+0x20/0x24)
>
> r5:89705f41 r4:c02c923c
>
>[<c003ed78>] (omap_dm_timer_prepare+0x0/0x24) from [<c003ee00>] (omap_dm_timer_request+0x64/0x70)
>
> r4:c02c923c
>
>[<c003ed9c>] (omap_dm_timer_request+0x0/0x70) from [<c0011638>] (omap2_gp_timer_init+0xf8/0x1e0)
>
> r4:36b4a597
>
>[<c0011540>] (omap2_gp_timer_init+0x0/0x1e0) from [<c000f8fc>] (time_init+0x1c/0x24)
>
>[<c000f8e0>] (time_init+0x0/0x24) from [<c0008c74>] (start_kernel+0x168/0x2b4)
>
>[<c0008b0c>] (start_kernel+0x0/0x2b4) from [<80008034>] (0x80008034)
>
> r6:c002232c r5:c02e3d10 r4:00c5387d
>
>Code: ebffffcf e59f203c e5943010 e5922000 (e5933010)
>
><0>Kernel panic - not syncing: Attempted to kill the idle task!
>-------
>
>
>Possible Root Cause:
>The GPT2 f-clk and i-clk are not getting enabled properly.
>
>For the clocks: gpt1_fck and gpt1_ick I don't see the function omap2_wait_clock_ready() getting
>called, that checks the status of GPT2 clocks is good or not.
>
>Function omap2_clk_wait_ready() is getting called but due to the checks in this function, the
>function omap2_wait_clock_ready() does not get called. As a result the clocks are still not enabled
>and a register access causes a crash.
>
>Please check
>
>
>
>>
>>
>>- Paul
>-
>To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>the body of a message to majordomo@xxxxxxxxxxxxxxx
>More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
