[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