Re: [BUG] omap1 fails to boot on clock propagation

["Łukasz Góralczyk" <lukasz.goralczyk@gmail.com>]

2013/1/29 Jon Hunter <jon-hunter@ti.com>
>
> On 01/29/2013 03:53 AM, Łukasz Góralczyk wrote:
> > Hello,
> >
> > Some background:
> > Recently I've ported Linux to some custom omap1 based (5940 or 1510)
> > hardware. I've had some initial problems, but after a "dirty" fix I
> > have a running kernel and I can boot using NFS.
>
> Do you mean 5910? I am not familiar with a 5940.

Yes, I hesitated for a moment if it was ...10 or ...40, it's *5910*.

> > Problem:
> > On the very beginning kernel boot process stopped on clock propagation
> > routine (simple freeze, no crash info, nothing). After investigation I
> > have found that one memory read is at fault in function
> > omap1_ckctl_recalc_dsp_domain() in clock.c file:
> >
> > dsor = 1 << (3 & (__raw_readw(DSP_CKCTL) >> clk->rate_offset));
> >
> > My fix was to exchange read operation with default value of DSP_CKCTL register:
> >
> > dsor = 1 << (3 & (0x009000090 >> clk->rate_offset));
> >
> > Since this fix I haven't dug deeper into this problem, but it keeps me
> > thinking how to fix it properly. Any suggestions what might be the
> > root cause of this?
>
> Well looking at the code, in order to access the DSP_CKCTL register you
> need to enable the api_ck first ...
>
> omap1_clk_enable(api_ck_p);
> dsor = 1 << (3 & (__raw_readw(DSP_CKCTL) >> clk->rate_offset));
> omap1_clk_disable(api_ck_p);
>
> Therefore, I would check if the api_ck is actually being turned on, on
> your platform. For example ...
>
> omap1_clk_enable(api_ck_p);
> pr_info("ARM_IDLECT2 = 0x%x\n", __raw_readw(ARM_IDLECT2));
> omap1_clk_disable(api_ck_p);
>
> Bit 6 in the ARM_IDLECT2 should be set if the api_ck is enabled.

Thanks, now I'll know where to look.

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