On 04/26/2012 11:33 AM, Kevin Hilman wrote:
Vaibhav Hiremath<hvaibhav@xxxxxx> writes:
Current OMAP code supports couple of clocksource options based
on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer
and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz).
[...]
+
+ sync32k_ick = clk_get(NULL, "omap_32ksync_ick");
+ if (!IS_ERR(sync32k_ick))
+ clk_enable(sync32k_ick);
+
+ sync32k_cnt_reg = base + OMAP2_32KSYNCNT_CR_OFF;
+
+ /*
+ * 120000 rough estimate from the calculations in
+ * __clocksource_updatefreq_scale.
+ */
+ clocks_calc_mult_shift(&persistent_mult,&persistent_shift,
+ 32768, NSEC_PER_SEC, 120000);
+
+ ret = clocksource_mmio_init(base, "32k_counter", 32768, 250, 32,
+ clocksource_mmio_readl_up);
After discussing this a bit with Vaibhav offline, we found that 'base'
here should be sync32k_cnt_reg.
Sorry, this was confusing. To be more specific, s/base/sync32k_cnt_reg/
in the clocksource_mmio_init line
above.
Kevin
Can you guys that were seeing the hang confirm that that fixes the
issue?
If so, please reply with your Tested-by.
Thanks,
Kevin
--
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
