On Tue, Jan 11, 2011 at 05:44:59PM +0800, Jeremy Kerr wrote:> > I object to this as one of the purposes behind the clk API is to allow> > power savings to be made, and unless we can perform clk enable/disable> > from atomic contexts, the best you can do is enable the clock when the> > device is probed and disable it when it's released.> > > > [...]> >> > Sometimes the only point that you know you need the clock enabled is when> > your driver has already been called in an atomic context.> > .. provided that the enable (and subsequent things that depend on the clock > signal to be valid) can't be deferred; I'm not sure how often this will be > possible.> > So, it sounds like the best approach is to provide an atomic clk_enable. I > agree with Sascha that the clk_enable and clk_enable_atomic polarity makes the > most sense, so how about:> > int clk_enable(struct clk *clk)> {> might_sleep();> > [...]> }> > int clk_enable_atomic(struct clk *clk)> {> BUG_ON(!(clk->flags & CLK_ATOMIC));> > [...]> }> > Paul: even though you mention that the atomic clocks are the usual case, I > think that this way around illustrates the atomic 'restriction' at the call > site more clearly. When the drivers don't care about the atomicity, > clk_enable() is fine. When drivers do need an atomic clock, > clk_enable_atomic() shows this requirement.I agree that we should try to make the clk api easy and consistent. Soif we can go the atomic way we should in my opinion.

On i.mx the roots in the clk hierarchy are plls, so it would be nice toknow how long it takes to enable these.

Back when I implemented clk support for ns921x I had a clock that mademe think that a sleeping implementation would be the way to go. I don'tremember the exact details. (It was the rtc clk.)