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

[Paul Walmsley]

On Thu, 24 May 2012, Hiremath, Vaibhav wrote:

> On Thu, May 24, 2012 at 13:01:11, Paul Walmsley wrote:
> > On Wed, 23 May 2012, Hiremath, Vaibhav wrote:
> > 
> > > 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?
> 
> In case of AM33xx, clock architecture is,
> 
> sysclk1 -> L4_wakeup - wakeup domain modules
> 
> sysclk1 -> L4 HS - L4 HS domain modules
> 
> sysclk1 -> L4 LS - L4 LS domain modules
> 
> and so on...
> 
> 
> Now with leaf node cleanup, we are moving upward in the clocktree, more 
> close to dpll output, and is the issue related to clockdomain.

I don't really understand.  Perhaps you could provide an example from one 
of the modules?

Are you saying that you have a module that should be in a different 
clockdomain than the clockdomain of the module's main functional clock?

> > > > >    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.
> 
> omap44xx_mailbox_hwmod doesn't have main_clk exported in the hwmod_data,
> so I think I should also follow same thing, right?

Well please start with specifying the main_clk for all IP blocks.  It is 
potentially ambiguous not to specify it, so unless there is some problem 
with specifying it, I'd prefer to have them.

> You can access the code at - 
> https://github.com/hvaibhav/am335x-linux   am335x-upstream-staging

I'll wait until it's posted to the lists.


- Paul