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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
