Hi!
I've added possibility to manualy force specified frequency and
voltage... That's fairly usefull for testing, and I believe this (or
something equivalent) is needed because every 2nd bios seems to be
b0rken.
Take a look and apply if you want to...
Pavel
--- clean/arch/i386/kernel/cpu/cpufreq/powernow-k7.c 2003-02-15 18:51:11.000000000 +0100
+++ linux/arch/i386/kernel/cpu/cpufreq/powernow-k7.c 2003-02-18 17:36:29.000000000 +0100
@@ -210,7 +210,7 @@
}
-static void change_speed (unsigned int index)
+static void change_speed (unsigned int index, unsigned int voltage)
{
u8 fid, vid;
struct cpufreq_freqs freqs;
@@ -226,6 +226,14 @@
fid = powernow_table[index].index & 0xFF;
vid = (powernow_table[index].index & 0xFF00) >> 8;
+ if (voltage) {
+ int i;
+ for (i=0; i<32; i++)
+ if (mobile_vid_table[i] == voltage)
+ vid = i;
+ printk("Voltage overriden to %d mV, index 0x%x\n", voltage, vid);
+ }
+
freqs.cpu = 0;
rdmsrl (MSR_K7_FID_VID_STATUS, fidvidstatus.val);
@@ -338,7 +346,7 @@
if (cpufreq_frequency_table_target(policy, powernow_table, target_freq, relation, &newstate))
return -EINVAL;
- change_speed(newstate);
+ change_speed(newstate, policy->voltage);
return 0;
}
--- clean/drivers/cpufreq/proc_intf.c 2003-02-18 12:24:32.000000000 +0100
+++ linux/drivers/cpufreq/proc_intf.c 2003-02-18 14:23:48.000000000 +0100
@@ -28,6 +28,7 @@
unsigned int min = 0;
unsigned int max = 0;
unsigned int cpu = 0;
+ unsigned int voltage = 0;
char str_governor[16];
struct cpufreq_policy current_policy;
unsigned int result = -EFAULT;
@@ -37,9 +38,24 @@
policy->min = 0;
policy->max = 0;
+ policy->voltage = 0;
policy->policy = 0;
policy->cpu = CPUFREQ_ALL_CPUS;
+ if (sscanf(input_string, "%d:%d:%d:%15s", &cpu, &min, &voltage, str_governor) == 4)
+ {
+ if (!strcmp(str_governor, "mVforce")) {
+ printk("Have request to go to %d mV\n", voltage);
+ policy->min = min;
+ policy->max = min;
+ policy->voltage = voltage;
+ policy->cpu = cpu;
+ result = 0;
+ policy->policy = CPUFREQ_POLICY_PERFORMANCE;
+ return 0;
+ }
+ }
+
if (sscanf(input_string, "%d:%d:%d:%15s", &cpu, &min, &max, str_governor) == 4)
{
policy->min = min;
--- clean/include/linux/cpufreq.h 2003-02-18 12:24:38.000000000 +0100
+++ linux/include/linux/cpufreq.h 2003-02-18 12:25:10.000000000 +0100
@@ -63,6 +63,7 @@
unsigned int min; /* in kHz */
unsigned int max; /* in kHz */
unsigned int policy; /* see above */
+ unsigned int voltage;/* in mV, 0 == trust bios */
struct cpufreq_governor *governor; /* see below */
struct cpufreq_cpuinfo cpuinfo; /* see above */
struct intf_data intf; /* interface data */
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
On Tue, Feb 18, 2003 at 10:42:20PM +0100, Pavel Machek wrote:
> I've added possibility to manualy force specified frequency and
> voltage... That's fairly usefull for testing, and I believe this (or
> something equivalent) is needed because every 2nd bios seems to be
> b0rken.
Why are all the power/cpu patches so complex? Can't we have a
two-mode style operation, "slow-low-power" and "fast-high-power" or
something? Would that not work with 99% or what people need and also
be somewhat more uniform across platforms, CPUs, etc?
--cw
Hi!
> > I've added possibility to manualy force specified frequency and
> > voltage... That's fairly usefull for testing, and I believe this (or
> > something equivalent) is needed because every 2nd bios seems to be
> > b0rken.
>
> Why are all the power/cpu patches so complex? Can't we have a
> two-mode style operation, "slow-low-power" and "fast-high-power" or
> something? Would that not work with 99% or what people need and also
> be somewhat more uniform across platforms, CPUs, etc?
Well, and does slow-low-power mean 300MHz, 1.4V as bios said, or
300MHz, 1.2V which is probably also safe?
What about
"as-fast-as-possible-but-not-exceed-140MHz-because-batteries-are-
running-low-and-can-not-give-enough-current"? That's different from
"fast-high-power", but it is *also* different from
"slow-low-power". [This actually matters on beasts like zaurus]. What
about
"as-low-power-as-possible-but-make-sure-you-can-keep-display-up"? [On
some machines cpu must be > some HMz for display to still work].
Power managment is complex...
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
On Tue, Feb 18, 2003 at 10:58:19PM +0100, Pavel Machek wrote:
> Well, and does slow-low-power mean 300MHz, 1.4V as bios said, or
> 300MHz, 1.2V which is probably also safe?
I have no idea... that's the point... the user almost never knows what
*exact* magic values are required, they just want fast-on-power or
slow-on-battery sort of thing.
> What about
> "as-fast-as-possible-but-not-exceed-140MHz-because-batteries-are-
> running-low-and-can-not-give-enough-current"? That's different from
> "fast-high-power", but it is *also* different from
> "slow-low-power". [This actually matters on beasts like
> zaurus]. What about
> "as-low-power-as-possible-but-make-sure-you-can-keep-display-up"?
> [On some machines cpu must be > some HMz for display to still work].
this just shows how silly these complex schemes are
you pick two options, a slow and fast option; both should work
--cw
On Tue, Feb 18, 2003 at 02:08:58PM -0800, Chris Wedgwood wrote:
> you pick two options, a slow and fast option; both should work
User control, yes. System control can (and should) be fine grained.
Define "slow" when someone turns the framebuffer display off and you
don't need to satisfy its minimum requirement while you do still need
to keep something running in the background.
So now we have "slow", "not so slow" and "fast".
As I say, user control is by all means "I want fast" or "I want power
save" but you can't define "fast" and "slow" to mean anything without
examining the rest of the system state.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Hi!
> > Well, and does slow-low-power mean 300MHz, 1.4V as bios said, or
> > 300MHz, 1.2V which is probably also safe?
>
> I have no idea... that's the point... the user almost never knows what
> *exact* magic values are required, they just want fast-on-power or
> slow-on-battery sort of thing.
Well, but system also does not know. And *I* need a way to tell my
system what the right thing is.
> > What about
> > "as-fast-as-possible-but-not-exceed-140MHz-because-batteries-are-
> > running-low-and-can-not-give-enough-current"? That's different from
> > "fast-high-power", but it is *also* different from
> > "slow-low-power". [This actually matters on beasts like
> > zaurus]. What about
> > "as-low-power-as-possible-but-make-sure-you-can-keep-display-up"?
> > [On some machines cpu must be > some HMz for display to still work].
>
> this just shows how silly these complex schemes are
>
> you pick two options, a slow and fast option; both should work
Well, but this simple user interface means pretty complicated
insides.
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
On Tue, Feb 18, 2003 at 10:16:11PM +0000, Russell King wrote:
> User control, yes. System control can (and should) be fine grained.
Well the issue then is how to avoid making the kernel API extremely
complex and different for every platform out there then?
--cw
On Tuesday 18 February 2003 16:47, Chris Wedgwood wrote:
> On Tue, Feb 18, 2003 at 10:42:20PM +0100, Pavel Machek wrote:
> > I've added possibility to manualy force specified frequency and
> > voltage... That's fairly usefull for testing, and I believe this (or
> > something equivalent) is needed because every 2nd bios seems to be
> > b0rken.
>
> Why are all the power/cpu patches so complex? Can't we have a
> two-mode style operation, "slow-low-power" and "fast-high-power" or
> something? Would that not work with 99% or what people need and also
> be somewhat more uniform across platforms, CPUs, etc?
I think the important thing is for the kernel to provide the functionality
that 99% of the people will need, and then for userspace tools/daemons to
hide the complex portions and make it easy for a user to get what he wants.
/proc is not nearly a valid user interface, but it is one of the
application interfaces.
--
George Staikos
On Tue, 2003-02-18 at 21:47, Chris Wedgwood wrote:
> On Tue, Feb 18, 2003 at 10:42:20PM +0100, Pavel Machek wrote:
>
> > I've added possibility to manualy force specified frequency and
> > voltage... That's fairly usefull for testing, and I believe this (or
> > something equivalent) is needed because every 2nd bios seems to be
> > b0rken.
>
> Why are all the power/cpu patches so complex? Can't we have a
> two-mode style operation, "slow-low-power" and "fast-high-power" or
> something? Would that not work with 99% or what people need and also
> be somewhat more uniform across platforms, CPUs, etc?
The ACPI side deals with most of that aspect of it. The low level stuff
is cool for some people, its there so you can have speed sliders,
temperature gauges, flashing red thermal lights, watt meters and the
rest to go with your blue lights, see through case and watercooler ;)
On Tue, Feb 18, 2003 at 02:08:58PM -0800, Chris Wedgwood wrote:
> On Tue, Feb 18, 2003 at 10:58:19PM +0100, Pavel Machek wrote:
>
> > Well, and does slow-low-power mean 300MHz, 1.4V as bios said, or
> > 300MHz, 1.2V which is probably also safe?
>
> I have no idea... that's the point... the user almost never knows what
> *exact* magic values are required, they just want fast-on-power or
> slow-on-battery sort of thing.
One possibility is a database of known-safe overrides for specific
models of laptops. We *could* even do DMI based overrides which make
cpufreq point at an in-module PST instead of BIOS. That in-module PST
would be machine-independant, and would need to be derived by someone
like Pavel using a patch pretty much like the one he proposed to do
trial and error testing. The only thing I'm concerned about with that
approach is the risk of possible damage.
longhaul will allow you to overclock/overpower the cpu. I've never
actually damaged a C3 in this way, just locked it up needing a
power-cycle. powernow-k7 clips in hardware to the maximum the cpu
is capable of. Specifying too low a voltage also seems to universally
lock up the box. Those are the implementations I know about, so unless
any of the other implementations allow dangerous operations, we should
be 'mostly harmless' right now.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
> > Well, and does slow-low-power mean 300MHz, 1.4V as bios said, or
> > 300MHz, 1.2V which is probably also safe?
>
> I have no idea... that's the point... the user almost never knows what
> *exact* magic values are required, they just want fast-on-power or
> slow-on-battery sort of thing.
>
> you pick two options, a slow and fast option; both should work
Until you are working on an embedded system, and want the extra
functionality.
Whenever you have a lot of options, adding extra options to try to
simplify things rarely achieves that.
Good defaults, and good documentation are much more useful than yet
another way to alter several variables at once.
John.
Hi!
> > I've added possibility to manualy force specified frequency and
> > voltage... That's fairly usefull for testing, and I believe this (or
> > something equivalent) is needed because every 2nd bios seems to be
> > b0rken.
>
> Why are all the power/cpu patches so complex? Can't we have a
> two-mode style operation, "slow-low-power" and "fast-high-power" or
> something? Would that not work with 99% or what people need and also
> be somewhat more uniform across platforms, CPUs, etc?
Another point here: This laptop machine allows scalling from 900MHz
back down to ~45MHz (actually 300MHz+throttling). If user said
"slow-low-power" he probably did not mean 45MHz, still it would be
nice to expose full range to the user.
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.