[PATCH-V3 3/3] ARM: OMAP3+: clock33xx: Add AM33XX clock tree data

[Hiremath, Vaibhav]

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)


> > As per the Spec, we have some known HW/Si issues to run whole system at 
> > OPP50, that's where if you refer to the TRM Table 8-22. Per PLL Typical 
> > Frequencies (MHz), it only talks about OPP100, which is 732.4219 divider.
> > 
> > So, technically, if both OPP's (OPP100 and OPP50) works fine, then yes, we 
> > should handle it. But given the fact that, OPP50 is not fully functional due 
> > to HW/Si issues, from CORE and PER perspective we will always stay at OPP100.
> 
> I see.
> 
> > To summarize, I had to make it fixed-frequency due to,
> > 
> >  - Fractional divisor value.
> 
> This could be implemented as an M,N counter, unless the hardware is doing 
> something more unusual.
> 
> > > - 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. And same as other modules, control is provided 
to the SW.

> We're trying to remove all of these MODULEMODE clocks from the clock 
> framework, and also remove the accompanying clockdomain control sequence 
> from the clock code.  But now it's looking like it may be impossible due 
> to this "clock," which means we'll need to keep that code around, which is 
> unfortunate.
> 

I think we have to live with it.

Thanks,
Vaibhav
> 
> - Paul
>