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

[Paul Walmsley]

Hi

On Wed, 23 May 2012, Hiremath, Vaibhav wrote:

> I believe register read/write to IP block is depends on only interface 
> Clocks? Atleast in case of OMAP3, it was like that, right??

No, on OMAP3, most modules need both the interface clock enabled, and at 
least one of their functional clocks.  For modules with multiple 
functional clocks like the OMAP3 USBHOST, we had to use trial 
and error to determine which functional clock was the main clock, since it 
wasn't documented.  If we got it wrong, then register accesses to the 
module would result in an abort.

The AM33xx/OMAP4 behavior should be a little easier in this regard, 
though, since the MODULEMODE bits should just control everything for a 
given module, and that should be handled by the hwmod code.  Nevertheless 
it is still good to specify a main_clk so we know how fast the module's 
registers are clocked and to locate the module in the power management 
hierarchy.

> Another issues is, 
> 
> I came across situation where, two modules fall into different clock 
> domains but their functional clock is happened to be coming from same 
> source/dpll-divider. So in order to satisfy clkdm match between them, I 
> have kept nodes without enable_regs.

Could you please provide an example?

> > >    So currently, I have mentioned same entry in both the places (especially 
> > >    for Peripherals/modules).
> > >    I am planning to remove ocp_if/clk entry data for all modules..
> > 
> > Hmmm, could you explain this further?
> 
> what if, module only has interface clock? Should it be present as 
> main_clk or ocp_if.clk or both?? Example would be, TPCC, TPTC, 
> smartreflex, etc...

Well it definitely should be present as the ocp_if.clk.  I personally 
think it would be good to list the same clock as the hwmod's main_clk too, 
but it's currently not strictly necessary.  There are some examples in the 
omap_hwmod_44xx_data.c file, like omap44xx_mailbox_hwmod.


- Paul