All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Jones <davej@redhat.com>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: BIOS Flash changes PowerNOW frequencies?
Date: Wed, 14 Jan 2004 05:08:18 +0000	[thread overview]
Message-ID: <20040114050818.GC23845@redhat.com> (raw)
In-Reply-To: <20040111175610.GA26855@dotnetslash.net>

On Sun, Jan 11, 2004 at 12:56:10PM -0500, Mark W. Alexander wrote:
 > I'm not currently subscribed. Please cc: me on responses.
 > 
 > I'm running 2.6.0 on an HP Pavilion ze4420 Athlon version (lspci -v below).  I
 > recently flashed the BIOS (hoping against all odds for suspend to ram
 > capability) and the CPU frequencies discovered by PowerNOW (K7) has changed.
 > This is obviously caused by the BIOS update, but the stupid question of the day
 > is "Why?". If the CPU and chipset support both sets of frequencies with
 > different BIOS, wouldn't the _real_ set of supported frequencies be the union
 > of the 2?

In reality, yes.
However BIOS programmers have a different perception of reality to the rest of us.
The spec for PST tables allows for up to 256 FID/VID pairs, yet everyone just
seems to offer 5-6 as maximum. I guess they figured no-one needed the granularity
of the full range.

 > As startling as it was to come up at 532Mhz the first boot, I can see where
 > this could provide some dramatic power savings (say, while using vi),
 > but the now missing 1064, 1463 and 1596 frequencies were more practical
 > for actually doing something worthwhile (say, using vi while watching a
 > DVD ;).
 > Is there anything I can do to persuade PowerNOW/frequency scaling to see the
 > full range of frequencies that I've seen this box can do?

Something that has been planned for quite a while has been a means of overriding
the tables using sysfs. I haven't had time to implement this, and no-one else
has found the time/motivation to do so either it seems.

Something I was tempted to do at one point (due to the number of broken PST's out
there) was to offer a 'ignore_pst' module parameter, which exposed the full table
to sysfs. The only problem being some VRMs can't handle certain frequencies at
certain voltages whilst some can, making it hard to find a set of 'safe' values
for each frequency.

How to find out which one VRM can handle frequency X at voltage Y ?
Through the PST tables.

*sigh*, back to the drawing board.

		Dave


  reply	other threads:[~2004-01-14  5:09 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-11 17:56 BIOS Flash changes PowerNOW frequencies? Mark W. Alexander
2004-01-14  5:08 ` Dave Jones [this message]
2004-01-15 20:48   ` Pavel Machek
2004-01-15 12:03 ` Pavel Machek
2004-01-15 13:32   ` Mark W. Alexander
2004-01-15 21:04     ` Pavel Machek
2004-01-15 21:24     ` Pavel Machek

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=20040114050818.GC23845@redhat.com \
    --to=davej@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.