On Wed, Apr 27, 2011 at 11:12 PM, MyungJoo Ham <[email protected]> wrote: > On Thu, Apr 28, 2011 at 5:48 AM, Colin Cross <[email protected]> wrote: >> 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. > > We need them in runtime. > > A device "a" may want to guarantee that a device "b" to be at least > "200MHz" or faster while it does some operations. Then, "a" will > opp_disable("b", 100MHz and others); and opp_enable("b", them) later > on. We have similar issues with multimedia blocks (MFC, Camera, FB, > GPU) and CPU/Memory Bus. Ondemand governor of CPUFREQ has some delay > on catching up a workload (1.5x the sampling rate in average, <2.0x > the sampling rate in worst cases), which may incur flickering/tearing > issues with multimedia streams. On the other hand, a general thermal > monitor or battery manager might want to limit energy usage by > disabling top performance clocks if it is too hot or the battery level > is low.
That sounds like a very strange api, when what you really mean is clk_set_min_rate or clk_set_max_rate. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
