Hi, > a few quick comments, possibly nit-picking... > > On Wed, 31 Dec 2008, Woodruff, Richard wrote: > > > Actually, the functional spec for timer says max re-sync time is: > > 3 OCP clock + 2.5 TIMER clock > > 3(1/83MHz) + 76uS = ~76uS > > The OCP clock rate is dependent on the timer's interface clock > clockdomain. On OMAP3, GPTIMER1 uses sys_clk as the OCP interface clock, > so the interface portion of this delay could be as slow as 3 periods/12MHz > periods = 250 ns. > > For GPTIMERs in CORE_L4 or PER_L4, the choice of CORE OPP will also change > the OCP delay portion. The L4 bus clock rate could be as low as 20.75MHz > in 34xx VDD2 OPP1; resulting in a 145 ns delay for that portion. > > These factors are noise with the 32KiHz timer source, but we are overusing > it. In the case of Beagle, the HF clk source can't be disabled, so we > should be able to use sys_ck. Same for other boards when AUTOEXTCLKMODE > is disabled. In those situations we should probably take the OCP-related > delay into account. Yes, you are correct on L4 clock. I wrote a bit quickly. It is noise compared to the 32K. Your idea about AUOEXTCLKMODE might work. I'd be worried about some hidden CM (from prcm) dependency which might stop RET/OFF. Several other clock sources which route through CM can keep it up and CORE from going down. Probably worth a quick test. Regards, Richard W. -- 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
