From: Tim Bird <tim.bird@am.sony.com>
To: Vitaly Wool <vitalywool@gmail.com>
Cc: David Singleton <daviado@gmail.com>,
linux-pm@lists.osdl.org, david singleton <dsingleton@mvista.com>
Subject: Re: PowerOp Design and working patch
Date: Tue, 01 Aug 2006 11:02:44 -0700 [thread overview]
Message-ID: <44CF9744.2060201@am.sony.com> (raw)
In-Reply-To: <acd2a5930607300402n13890dbg150315f617c86ffd@mail.gmail.com>
Vitaly Wool wrote:
> On 7/30/06, david singleton <dsingleton@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
=============================
next prev parent reply other threads:[~2006-08-01 18:02 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-28 22:31 PowerOp Design and working patch david singleton
2006-07-28 23:38 ` Greg KH
2006-07-29 0:26 ` david singleton
2006-07-29 0:38 ` david singleton
2006-07-29 0:45 ` Greg KH
2006-07-29 5:12 ` david singleton
2006-07-29 19:07 ` Eugeny S. Mints
2006-07-30 4:43 ` david singleton
2006-07-30 11:02 ` Vitaly Wool
2006-08-01 0:59 ` david singleton
2006-08-01 10:09 ` Matthew Locke
2006-08-01 10:22 ` Matthew Locke
2006-08-01 18:31 ` david singleton
2006-08-01 18:52 ` Tim Bird
2006-08-01 18:59 ` david singleton
2006-08-01 19:17 ` Vitaly Wool
2006-08-01 19:28 ` Vitaly Wool
2006-08-06 22:11 ` Pavel Machek
2006-08-07 10:34 ` Igor Stoppa
2006-08-07 19:45 ` Tim Bird
2006-08-08 10:07 ` Pavel Machek
2006-08-08 11:12 ` Igor Stoppa
2006-08-08 11:33 ` Pavel Machek
2006-08-08 16:43 ` Tim Bird
2006-08-01 12:23 ` Vitaly Wool
2006-08-01 18:25 ` Tim Bird
2006-08-01 18:02 ` Tim Bird [this message]
2006-08-06 22:05 ` Pavel Machek
2006-08-07 3:52 ` david singleton
2006-08-07 4:17 ` Greg KH
2006-08-07 4:32 ` Vitaly Wool
2006-07-29 22:09 ` Greg KH
2006-08-01 0:36 ` david singleton
2006-08-01 1:27 ` david singleton
2006-08-07 22:06 ` Pavel Machek
-- strict thread matches above, loose matches on Subject: below --
2006-08-01 10:09 Matthew Locke
2006-08-07 14:12 Scott E. Preece
2006-08-07 16:58 ` Greg KH
2006-08-08 13:44 Scott E. Preece
2006-08-08 13:52 ` Pavel Machek
2006-08-08 15:53 ` Matthew Locke
2006-08-08 16:03 ` Matthew Locke
2006-08-08 18:10 ` Igor Stoppa
2006-08-08 13:54 Scott E. Preece
2006-08-08 16:49 ` Tim Bird
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44CF9744.2060201@am.sony.com \
--to=tim.bird@am.sony.com \
--cc=daviado@gmail.com \
--cc=dsingleton@mvista.com \
--cc=linux-pm@lists.osdl.org \
--cc=vitalywool@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox