Re: [RFC PATCH] PM: Introduce generic DVFS framework with device-specific OPPs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Apr 27, 2011 at 11:50 PM, MyungJoo Ham <myungjoo.ham@xxxxxxxxxxx> wrote:
> On Thu, Apr 28, 2011 at 3:44 PM, Colin Cross <ccross@xxxxxxxxxx> wrote:
>> 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.
>
> 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?

Yes, but that's effectively what you're doing through a backwards api
anyways.  The question is, for these complicated clock scenarios where
the final frequency of a clock depends on so many factors, should that
control go through the clock framework, or through some sort of global
clock governor (which is where OPP would reappear).
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm



[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux