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