On Wed, Apr 27, 2011 at 12:26 PM, Thomas Gleixner <t...@linutronix.de> wrote: > Forget OMAP implementation details for a while, sit back and look at > the big picture.
Here's my proposal for DVFS: - DVFS is implemented in drivers/clk/dvfs.c, and is called by the common clock implementation to adjust the voltages, if necessary, on regular clk_* calls. - Platform code provides mappings in the form (clk, regulator, max frequency, min voltage) to the dvfs code. - Everything that is in OPP today gets converted to helper functions inside the dvfs implementation, and is never called from SoC code (except to pass tables at init), or from drivers. - OPP can be recreated in the future as a upper level policy manager for clocks that need to move together, if that is ever necessary. It would not know anything about voltages. - A few common policy implementations need to be added to the common clock implementation, like temperature limits. For Tegra: - DVFS continues to be accessed by calling clk_* functions For OMAP: - DVFS is triggered by hwmod through clk_* functions. Any cross-arch driver can continue to call clk_* functions. OPP currently has opp_enable and opp_disable functions. I don't understand why these are needed, they are only used at init time to determine available voltages, which could be handled by never passing unavailable voltages to the dvfs implementation. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
