From: Pavel Machek <pavel@ucw.cz>
To: Mark Gross <mgross@linux.intel.com>
Cc: pm list <linux-pm@lists.osdl.org>,
Dominik Brodowski <linux@dominikbrodowski.net>
Subject: Re: Alternative Concept [Was: Re: [RFC] CPUFreq PowerOP integration, Intro 0/3]
Date: Thu, 12 Oct 2006 18:48:13 +0200 [thread overview]
Message-ID: <20061012164813.GA4624@elf.ucw.cz> (raw)
In-Reply-To: <20061012153821.GA30804@linux.intel.com>
On Thu 2006-10-12 08:38:21, Mark Gross wrote:
> On Sun, Oct 08, 2006 at 07:16:49AM +0000, Pavel Machek wrote:
> > Hi!
> >
> > > F) So, how would this work for OMAP1?
> > >
> > > Let's limit it, to keep it somewhat simple, to the values contained in your
> > > "struct pm_core_point" for OMAP:
> > >
> > > int cpu_vltg; /* voltage in mV */
> > > int dpll; /* in KHz */
> > > int cpu; /* CPU frequency in KHz */
> > > int tc; /* in KHz */
> > > int per; /* in KHz */
> > > int dsp; /* in KHz */
> > > int dspmmu; /* in KHz */
> > > int lcd; /* in KHz */
> > >
> > > and let's also add a
> > >
> > > int i_am_special;
> >
> > Hehe, nice idea.
> >
> > > I think that this might be much easier to implement than your PowerOP /
> > > operating points / PM core / PowerOP - cpufreq interaction patches. As a
> > > matter of fact, some parts of your operating points table infrastructure
> > > may be usable for the concept outlined above. So, what do you think? What
> > > does everyone else involved think about this alternative approach?
> >
> > Looks okay to me. Unlike powerop design, this actually works for
> > everyone.
>
> Pavel, if you would pay attention better you would notice that at the
> underneath of what Dominic is talking about is a concept of *more knobs*
> for controlling platform power states. This is what PowerOP is trying
> to bring to the table.
I believe I did pay attention. What PowerOP has is crappy patches,
crappy changelogs, and when you don't like it, you are obviously
biased (or not paying attention).
And no, what Dominik describes is very reasonable, unlike powerop.
> PowerOP is not a policy engine like what Dominic is talking about. And
> what Dominic is talking about will need to build on something that will
> end up looking so much like power op that it wont be funny.
Great, so you think you do not have that much work to do. Go ahead and
do it.
(Unlike powerop, this has actually chance of working with 256
cpus. Unlike powerop people, Dominik did his homework.)
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next prev parent reply other threads:[~2006-10-12 16:48 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-24 1:23 [RFC] CPUFreq PowerOP integration, Intro 0/3 Eugeny S. Mints
2006-10-07 2:36 ` Alternative Concept [Was: Re: [RFC] CPUFreq PowerOP integration, Intro 0/3] Dominik Brodowski
2006-10-07 3:15 ` Dominik Brodowski
2006-10-08 7:16 ` Pavel Machek
2006-10-12 15:38 ` Mark Gross
2006-10-12 16:02 ` Dominik Brodowski
2006-10-16 21:56 ` Mark Gross
2006-10-17 21:40 ` Matthew Locke
2006-10-12 16:48 ` Pavel Machek [this message]
2006-10-12 17:12 ` Vitaly Wool
2006-10-12 17:23 ` Pavel Machek
2006-10-09 18:21 ` Mark Gross
2006-10-26 3:06 ` Dominik Brodowski
2006-10-12 22:43 ` Eugeny S. Mints
2006-10-13 10:55 ` Pavel Machek
2006-10-16 21:44 ` Mark Gross
2006-10-17 8:26 ` Pavel Machek
2006-10-26 3:05 ` Dominik Brodowski
2007-03-13 0:57 ` Alternative Concept Matthew Locke
2007-03-13 11:08 ` Pavel Machek
2007-03-13 20:34 ` Mark Gross
2007-03-14 2:30 ` Ikhwan Lee
2007-03-14 10:43 ` Eugeny S. Mints
2007-03-14 17:19 ` David Brownell
2007-03-14 18:12 ` Igor Stoppa
2007-03-14 18:45 ` David Brownell
2007-03-15 9:53 ` Eugeny S. Mints
2007-03-15 13:04 ` Igor Stoppa
2007-03-16 2:21 ` David Brownell
2007-03-16 3:56 ` Ikhwan Lee
2007-03-16 6:17 ` David Brownell
2007-03-19 2:27 ` Ikhwan Lee
2007-03-19 6:07 ` David Brownell
2007-03-16 13:06 ` Dmitry Krivoschekov
2007-03-16 18:03 ` David Brownell
2007-03-18 20:25 ` Dmitry Krivoschekov
2007-03-19 4:04 ` David Brownell
2007-03-20 0:03 ` Dmitry Krivoschekov
2007-03-20 8:07 ` David Brownell
2007-03-20 9:45 ` Dmitry Krivoschekov
2007-03-20 10:30 ` Igor Stoppa
2007-03-20 12:13 ` Eugeny S. Mints
2007-03-20 12:39 ` Igor Stoppa
2007-03-20 13:44 ` Dmitry Krivoschekov
2007-03-20 21:03 ` David Brownell
2007-03-20 13:07 ` Dmitry Krivoschekov
2007-03-20 13:52 ` Igor Stoppa
2007-03-20 14:58 ` Dmitry Krivoschekov
2007-03-20 15:36 ` Pavel Machek
2007-03-20 19:16 ` Dmitry Krivoschekov
2007-03-20 20:45 ` Pavel Machek
2007-03-20 22:04 ` David Brownell
2007-03-20 22:06 ` Pavel Machek
2007-03-20 23:29 ` David Brownell
2007-03-20 15:36 ` Igor Stoppa
2007-03-20 19:17 ` Dmitry Krivoschekov
2007-03-20 20:17 ` David Brownell
2007-03-20 20:21 ` David Brownell
2007-03-20 19:58 ` David Brownell
2007-03-24 0:47 ` charging batteries from USB [was: Re: Alternative Concept] Dmitry Krivoschekov
2007-03-24 1:17 ` David Brownell
2007-03-24 1:48 ` Dmitry Krivoschekov
2007-03-24 2:35 ` David Brownell
2007-03-24 10:20 ` Oliver Neukum
2007-03-24 8:36 ` Oliver Neukum
2007-03-14 3:19 ` Alternative Concept Dominik Brodowski
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=20061012164813.GA4624@elf.ucw.cz \
--to=pavel@ucw.cz \
--cc=linux-pm@lists.osdl.org \
--cc=linux@dominikbrodowski.net \
--cc=mgross@linux.intel.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