On Thu, 26 Apr 2012, Hiremath, Vaibhav wrote: > On Thu, Apr 26, 2012 at 12:06:00, Paul Walmsley wrote: > > On Thu, 26 Apr 2012, Hiremath, Vaibhav wrote: > > > > > Unfortunately, this is fractional divider, assuming input clock of 24MHz. > > > > > > 24MHz / 732.4219 = 32KHz (Normal OPP100) > > > 24MHz / 366.2109 = 32KHz (OPP50) > > > > Yes, I already saw that in the TRM. The question is, how is the > > fractional divider implemented in the hardware? Is it implemented as an > > M,N counter? It's rather unlikely to be dividing by 732.4219 directly -- > > in fact that value isn't even accurate. > > Not sure how it is implemented in HW, in any case we do not have control > over it. The control is only provided using, > - MODULEMODE (module enable/disable) > - CONTROL_CLK32K_DIVRATIO_CTRL (divisor selection) Right, but the goal is to make the clock tree rate computation independent of the assumptions of the OPP settings. So placing a fixed clock rate -- one that supposedly does not depend on a parent rate -- in the middle of a clock tree is something we wish to avoid, if possible. It is a hack. Especially considering that the clock's input rate does appear to depend on its parent's rate. So, could you please double-check to find out if the appropriate abstraction is as an M,N counter? If the public forum is an issue, then if you prefer, you can E-mail me privately with the results. > > > > - This clock is feeding downstream clocks, but it's using the MODULEMODE > > > > control interface, as if it were a standalone IP block. Do you know why > > > > it's using the MODULEMODE control method rather than some optional clock > > > > control bits, like OMAP4 does? > > > > > > Yes, this clock is feeding to timers, gpio debounce clocks, etc... > > > Honestly, I do not know the answer to why part of it. > > > (May be another integration/design issue) > > > > Could you please check with the AM335x PRCM designers about this to find > > out what that MODULEMODE bit is actually doing (i.e., is it actually > > enabling the clock, and if so, why did they not use the OPTFCLKEN bits) ? > > The AM335x TRM has almost no documentation on what those MODULEMODE bits > > are doing in this case. > > I can check, I am certain that, the answer would be to consider this as a > separate independent module. Yes, please check with the hardware team. The questions would be: - What does changing the CLKDIV32K_CLKCTRL.MODULEMODE bits do? - Is it necessary for the MODULEMODE bits to be set to 2 (ENABLE) to generate a clock to the clock nodes downstream of CLKDIV32K, or does the MODULEMODE just affect some other register access by the MPU? - Will setting the CLKDIV32K_CLKCTRL.MODULEMODE bits to 0 disable the clock from being provided to downstream nodes of the CLKDIV32K, or does it simply affect register access? - Is it necessary to follow the clockdomain enable sequence before enabling the CLKDIV32K MODULEMODE? - What clockdomain does the CLKDIV32K module belong to? > And same as other modules, control is provided to the SW. The problem is that CLKDIV32K does not appear to be a distinct, leaf IP block from a clocking perspective, unlike the other uses of the *_CLKCTRL.MODULEMODE bits in the AM335x and OMAP4 clock trees. So something is very unusual here. If one of our core framework assumptions for OMAP4+ devices is incorrect, it would be useful for us to know as soon as possible, to avoid churn and broken code. - 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
