[linux-pm] PowerOp Design and working patch

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

 



Vitaly Wool wrote:
> On 7/30/06, david singleton <dsingleton at mvista.com> wrote:
   > By just presenting the supported operating points to the user it
>  > removes the
>  > need for new APIs.  The user just reads the supported operating points
>  > and decides the best use of the supported operating points.
> 
> I see this approach as fundamentally wrong at least because it will
> produce very long and hard to manage lists of operating points.
> Suppose you have 20 hardware vendor approved core CPU frequency
> values, 3 possible voltage values and 10 approved DSP CPU frequency
> values (which are derived from the other PLL). Not too impossible is
> that almost all combinations are available which makes is almost 600
> operating points. I find it absolutely unreal that anyone enters all
> that stuff without mistakes; managing those lists/searching thru them
> will take significant time which will slow down the state transitions;
> and, finally, it's gonna increase the kernel footprint  quite a bit.
> 
> It looks to me that the concept that the kernel can implement
> rules/restrictions for operating points but shouldn't define them with
> possible exception for the most essential ones far better suits both
> embedded and non-embedded use cases.

I don't think anyone expects that the list of operating points
for a machine would be comprehensive (ie every possible combination
of parameters that are known to work).  This hearkens back to the
bad old days of X11 configuration, where users were expected to
set their own dot clocks and mode lines.  While you can still do
this, giving yourself a resolution of, say, 1139 by 582, almost
everyone now just selects from a pre-defined set
of X resolutions.  I think the same is expected to be true of
power operating points.  There would be a set number of
operating points, which would derive from the vendor data
sheets, that would be smallish and not necessarily all-inclusive.

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================



[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