public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Jones <davej@redhat.com>
To: Bruno Ducrot <ducrot@poupinou.org>
Cc: Pavel Machek <pavel@ucw.cz>,
	cpufreq@lists.linux.org.uk, linux-kernel@vger.kernel.org,
	linux-pm@lists.osdl.org
Subject: Re: [linux-pm] Re: PowerOP 2/3: Intel Centrino support
Date: Wed, 10 Aug 2005 14:44:45 -0400	[thread overview]
Message-ID: <20050810184445.GB14350@redhat.com> (raw)
In-Reply-To: <20050810125848.GM852@poupinou.org>

On Wed, Aug 10, 2005 at 02:58:48PM +0200, Bruno Ducrot wrote:

 > > > Minimal PowerOP support for Intel Enhanced Speedstep "Centrino"
 > > > notebooks.  These systems run at an operating point comprised of a cpu
 > > > frequency and a core voltage.  The voltage could be set from the values
 > > > recommended in the datasheets if left unspecified (-1) in the operating
 > > > point, as cpufreq does.
 > > 
 > > Eh? I thought these are handled okay by cpufreq already?

It does to some extent.  You can't explicitly set a voltage with
cpufreq, but the low-level drivers will match a voltage to a speed
on chips that we know enough info about.

 > ATM I'm wondering what are the pro for those patches wrt current cpufreq
 > infrastructure (especially cpufreq's notion of notifiers).
 > 
 > I still don't find a good one but I'm surely missing something obvious.

I'm glad I'm not the only one who feels he's too dumb to see
the advantages of this. The added complexity to expose something
that in all cases, we actually don't want to expose seems a little
pointless to me.

For example, most of the x86 drivers, if you set a speed, and then
start fiddling with the voltage, you can pretty much guarantee
you'll crash within the next few seconds.  They have to match,
or at the least, be within a very small margin.

Given how long its taken us to get sane userspace parts for cpufreq,
I'm loathe to changing the interfaces yet again unless there's
a clear advantage to doing so, as it'll take at least another 12 months
for userspace to catch up.

		Dave


  reply	other threads:[~2005-08-10 18:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-09  2:54 PowerOP 2/3: Intel Centrino support Todd Poynor
2005-08-09  7:59 ` Ingo Molnar
2005-08-10 10:01 ` Pavel Machek
2005-08-10 12:58   ` Bruno Ducrot
2005-08-10 18:44     ` Dave Jones [this message]
2005-08-10 23:37       ` [linux-pm] " Todd Poynor
2005-08-11 15:06         ` Jordan Crouse
2005-08-12 23:13           ` Todd Poynor
2005-08-12 12:38       ` [linux-pm] " Nikolay Pelov
2005-08-10 22:53     ` Todd Poynor

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=20050810184445.GB14350@redhat.com \
    --to=davej@redhat.com \
    --cc=cpufreq@lists.linux.org.uk \
    --cc=ducrot@poupinou.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.osdl.org \
    --cc=pavel@ucw.cz \
    /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