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 _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
