Thread (45 messages) 45 messages, 3 authors, 2012-05-24
STALE5128d

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

From: Hiremath, Vaibhav <hidden>
Date: 2012-05-24 20:24:09
Also in: linux-omap

On Thu, May 24, 2012 at 13:01:11, Paul Walmsley wrote:
Hi

On Wed, 23 May 2012, Hiremath, Vaibhav wrote:
quoted
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.
quoted
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.

quoted
quoted
quoted
   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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help