On 11/01/11 12:18, Paul Mundt wrote:

On Tue, Jan 11, 2011 at 06:30:18PM +0800, Jeremy Kerr wrote:

quoted

Hi Paul,

quoted

No, the sleeping clock case is and always will be a corner case, and I
have no interest in pretending otherwise. On SH we have hundreds of
clocks that are all usable in the atomic context and perhaps less than a
dozen that aren't (and even in those cases much of the PLL negotiation is
handled in hardware so there's never any visibility for the lock-down
from the software side, other architectures also have similar behaviour).

I'm not too worried about the corner-cases on the *implementation* side, more 
the corner-cases on the API side: are we seeing more users of the API that 
require an atomic clock, or more that don't care?

Again, you are approaching it from the angle that an atomic clock is a
special requirement rather than the default behaviour. Sleeping for
lookup, addition, and deletion are all quite acceptable, but
enable/disable pairs have always been intended to be usable from atomic
context. Anyone that doesn't count on that fact is either dealing with
special case clocks (PLLs, root clocks, etc.) or simply hasn't bothered
implementing any sort of fine grained runtime power management for their
platform.

No, the API has always been defined to ensure clk_enable() returns once
a clock is running and usable, so if the case where there are PLLs in
the way is inconvenient to you, then sorry but they exist already.