Hi Igor, On Wed, 10 Dec 2008, Igor Stoppa wrote: > On Tue, 2008-12-09 at 16:14 -0700, ext Paul Walmsley wrote: > > > > On Tue, 9 Dec 2008, Tomi Valkeinen wrote: > > > > > It looks to me that when I do clk_enable() to a clock which is inside a > > > turned off powerdomain, clk_enable() function will return before the > > > powerdomain is fully turned on. Reading PM_PWSTST_DSS shows that the > > > powerdomain is still in transition state. > > > > > > The following change waits until the powerdomain has finished the > > > transition. At least it fixed the problem for me, and other things seem > > > to be still working =). > > > > Nice work - this makes sense. Tested your patch here also. > > Just a thought: > wouldn't this feature be required in basically every similar case? > > And if yes, wouldn't it be better to embed it into clk_enable() so that > the driver code doesn't have to address it explicitly and can be more > easily shared across different OMAP architectures? I think Tomi's patch covers all of the similar cases, even though it isn't in clock..d directly. clock.c:omap2_clk_enable() calls clockdomain.c:omap2_clkdm_clk_enable() whenever a clock is enabled. This is the function that Tomi's patch changes. When the number of active clocks in a clockdomain goes from 0 to 1, omap2_clkdm_clk_enable() will wait until the powerdomain indicates that it has finished its transition before continuing. (The powerdomain may not actually change state at this point, but pwrdm_wait_transition() just waits for the "INTRANSITION" bit to equal zero, so it should be safe to test even if the powerdomain state does not change.) - 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
