[linux-pm] Montreal Linux Power Management Mini-Summit, July 13, 2009 - Meeting Notes

[Francesco VIRLINZI]

Hi Russel.
Thanks for your feedback.

I know several point are already covered by other cf implementation.
And I didn't create a new API... I use the same API linux already has.
> Point 4 is something that OMAP might be able to use, though OMAP already
> does this within its clk API implementation without notification of
> drivers - the clock rates are driven by drivers requesting rates for
> their own clocks rather than one driver influencing the clock rate for
> another.
>    
This is the major feature of cf ( without this point the cf is just an other
  cf...)... Moreover it's required when clocks are shared resource....
If each device has its own clock... than also this feature isn't really 
important
  because each driver can manage its own clock.

Basically the cf manages each clock operation (enable/disable/set_rate),
  as a transaction with several states.

During the transaction all the clock frequencies are evaluated (before
  the real change) and all the devices can check if they agree the new
  clock rate.
Moreover this is done also in hierarchical manner (i.e.: if you change
  a PLL which several clock child).
Basically the clock propagation involves both clocks and devices.

Regards
  Francesco