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.
> 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.
Cheers
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html