<snip> > > > > > > > + clk_enable(dpll5_clk); > > > > + > > > > + /* Enable autoidle to allow it to enter low power bypass */ > > > > + omap3_dpll_allow_idle(dpll5_clk); > > > > + > > > > + /* Program dpll5_m2_clk divider for no division */ > > > > + dpll5_m2_clk = clk_get(NULL, "dpll5_m2_ck"); > > > > + clk_enable(dpll5_m2_clk); > > > > + clk_set_rate(dpll5_m2_clk, 120000000); > > > > > > Shouldn't we clk_disable() dpll5_clk and dpll5_m2_clk here? The rationale > > > is that we should keep these disabled until some driver signals that it > > > needs them with a clk_enable(). > > > > The idea behind enabling these upfront was: > > - If done when the USB controller (the only user of this DPLL) needs the > > USB clocks, there would be an additional delay required to lock this > > DPLL. > > - Enabling and placing these DPLLs in bypass at init leaves no additional > > power drain in the OMAP, and avoids the above delay at first clock-init. > > > > What do you think? > > There is an additional power drain because you cannot stop > the DPLL, so you will have some dynamic consumption on the VPLL rail. > The point is that if nobody ever used the USB you will add an > extra consumption for nothing. > You'd better keep the DPLL in stop mode and enable it only > when needed. > > Regards, > Benoit > Okay. Will fix and resend in a bit. - Anand -- 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
