Hi Vaibhav On Wed, 23 May 2012, Hiremath, Vaibhav wrote: > I used your cleaned version of clocktree data, where you have removed all > leaf-nodes and merged multiple clocks nodes into one; but it did not work. I > attempted to review the cleanup and tried to debug, but found it bit hard to > come back to working clocktree from stripped version. So moved back to my > submitted clocktree and started stripping the clock leaf-nodes, same way you > had done it. Now I reached to the stage where I have working clocktree > without peripheral leaf-nodes and booting on BeagleBone. Okay great, please post that to the list so we can diff it against the version that I did, and also so we can queue it for merging in 3.6? > Just FYI (may need your help), I got into some issues (still open) during > this cleanup - > > 1. In cases where we have clock selection option for node-leafs, like, > Timers, I removed enable_reg entry from the node, which results into a > kernel error message from function omap2_dflt_clk_disable() > > clock: clk_disable called on independent clock %s which has no enable_reg Shouldn't those clocks use clkops_null then? > 2. clkdm_name entry: > The issue is, two entries available for clockdomain associated for > module/clock > - hwmod_data.main_clk and > - clk.clkdm_name > > They must match, right? The parent/root clocks flows from one domain to > another domain, so I have to keep the nodes just for sake of matching > clockdomain entry present in associated main_clk data. > > I am still reviewing the code from Rajendra, but one of Rajendra's patch > actually will help here, made it to use hwmod_data.clkdm (if available) > always, instead of directly using clk.clkdm. Well because of this CLKDIV32K snafu, we'll need to keep the clock framework-based clockdomain control for AM33xx, at the very least for the CLKDIV32K clock. I'd suggest starting with specifying a clockdomain name for each clock. If nothing else, this should help think through the power management behavior for each clock. Then those can be easily removed later with a simple grep. > 3. If I understand correctly, hwmod_data.main_clk is functional clock and > hwmod_ocp_if.clk is interface clock, right? Basically, yes. To be more precise, in cases where modules have multiple functional clocks, hwmod_data.main_clk is the functional clock that is needed in order for register reads and writes to the IP block to succeed. > 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? Every ocp_if structure that you create should have an interface clock specified. And almost all of your hwmods should have a main_clk specified. - 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
