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

Hiremath, Vaibhav hvaibhav at ti.com
Thu May 24 16:24:09 EDT 2012


On Thu, May 24, 2012 at 13:01:11, Paul Walmsley wrote:
> 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.
> 

Ok, thanks for the clarification.

> 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?
> 

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.


> > > >    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?


The cleaned clocktree (without common-clock fw) and hwmod code is ready, I 
just need to rebase against Kevin's hwmod cpu_is_xxx cleanup series (was 
pending in last version). This shouldn't impact anything to above clocktree 
and hwmod patch.

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


Thanks,
Vaibhav




More information about the linux-arm-kernel mailing list