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

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

 



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?

> _______________________________________________
> linux-pm mailing list
> linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux