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 Thu, Apr 28, 2011 at 5:48 AM, Colin Cross <ccross@xxxxxxxxxx> wrote:
> On Wed, Apr 27, 2011 at 12:26 PM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
>> Forget OMAP implementation details for a while, sit back and look at
>> the big picture.
>
> Here's my proposal for DVFS:
> - DVFS is implemented in drivers/clk/dvfs.c, and is called by the
> common clock implementation to adjust the voltages, if necessary, on
> regular clk_* calls.
> - Platform code provides mappings in the form (clk, regulator, max
> frequency, min voltage) to the dvfs code.
> - Everything that is in OPP today gets converted to helper functions
> inside the dvfs implementation, and is never called from SoC code
> (except to pass tables at init), or from drivers.
> - OPP can be recreated in the future as a upper level policy manager
> for clocks that need to move together, if that is ever necessary. ÂIt
> would not know anything about voltages.
> - A few common policy implementations need to be added to the common
> clock implementation, like temperature limits.

I hope that my previous reply answered this.

>
> For Tegra:
> - DVFS continues to be accessed by calling clk_* functions
>
> For OMAP:
> - DVFS is triggered by hwmod through clk_* functions. ÂAny cross-arch
> driver can continue to call clk_* functions.
>
> 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.

> _______________________________________________
> 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
_______________________________________________
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