On Wed, Apr 27, 2011 at 11:12 PM, MyungJoo Ham <myungjoo.ham@xxxxxxxxxxx> wrote:
> On Thu, Apr 28, 2011 at 5:48 AM, Colin Cross <ccross@xxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
