From: Tony Lindgren <tony@atomide.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: linux-kernel@vger.kernel.org, davej@redhat.com
Subject: Re: [PATCH] powernow-k8 max speed sanity check
Date: Thu, 5 Feb 2004 17:15:10 -0800 [thread overview]
Message-ID: <20040206011509.GE10268@atomide.com> (raw)
In-Reply-To: <20040206002806.GB1736@elf.ucw.cz>
* Pavel Machek <pavel@ucw.cz> [040205 16:28]:
> Hi!
>
> > > Well, I wanted some way to detect exactly this broken machine. You
> > > might want to simply put == 8 there.. but proper solution is DMI blacklist.
> >
> > Or just use the current running values for max speed. That will fail if the
> > system boots at lower speeds on battery though. And the BIOS checks will
> > fail on buggy BIOSes and when upgrading the CPU. So maybe use both checks?
>
> Well... for your own kernel hack it any way you want.
>
> For public consumtion... I guess DMI blacklist and assume user did not
> exchange cpus... We could cross-check /proc/cpuinfo.
Yeah, I don't care as long as it works good :)
> > > > What do you think about using module options maxfid and maxvid?
> > >
> > > Well, the original BIOS has not only maximum values wrong, but also
> > > 1600MHz wrong, as far as I can tell...
> >
> > Outch! I did not know that...
> >
> > Are the middle values needed? What if you only use the min and max
> > fid/vid values, and always recalculate the stepping tables from those
> > values?
>
> Well, 1600MHz operation is very nice, as it has significantly less
> power consumption but pretty much same performance. It also does not
> start CPU fan most of the time :-).
Yes, 1600MHz would be nice, I agree.
But I meant calculating all the valid values inbetween min and max without
relying on getting those values from the BIOS.
Then you would only need to find out the min and max values, and not
care about bugs in the BIOS table inbetween min and max.
I guess the code already does that to figure out how many steps are needed
to change between min and max?
Tony
next prev parent reply other threads:[~2004-02-06 1:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-31 20:35 [PATCH] powernow-k8 max speed sanity check Tony Lindgren
2004-01-31 23:19 ` Dave Jones
2004-02-03 13:14 ` Pavel Machek
2004-02-05 18:17 ` Tony Lindgren
2004-02-05 18:48 ` Pavel Machek
2004-02-05 19:36 ` Tony Lindgren
2004-02-05 21:33 ` Tony Lindgren
2004-02-05 21:38 ` Pavel Machek
2004-02-05 21:56 ` Tony Lindgren
2004-02-06 0:28 ` Pavel Machek
2004-02-06 1:15 ` Tony Lindgren [this message]
2004-02-06 12:56 ` Pavel Machek
2004-02-06 17:28 ` Tony Lindgren
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=20040206011509.GE10268@atomide.com \
--to=tony@atomide.com \
--cc=davej@redhat.com \
--cc=linux-kernel@vger.kernel.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