On Thu, Apr 28, 2011 at 3:44 PM, Colin Cross <ccr...@google.com> wrote:
> On Wed, Apr 27, 2011 at 11:12 PM, MyungJoo Ham <myungjoo....@samsung.com> 
> wrote:
>> On Thu, Apr 28, 2011 at 5:48 AM, Colin Cross <ccr...@google.com> 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.

Essentially, that's what needed.
However, with clk_set_min/max_rate, don't we need to let another
device to be consumer of other devices' clocks? Not just introducing a
device to other devices?

> _______________________________________________
> linux-pm mailing list
> linux...@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/linux-pm
>



-- 
MyungJoo Ham (함명주), Ph.D.
Mobile Software Platform Lab,
Digital Media and Communications (DMC) Business
Samsung Electronics
cell: 82-10-6714-2858
--
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

Reply via email to