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