* [PATCH 7/8] latency must be in _nano_seconds
@ 2003-11-19 18:33 Dominik Brodowski
2003-11-19 19:07 ` Dave Jones
0 siblings, 1 reply; 3+ messages in thread
From: Dominik Brodowski @ 2003-11-19 18:33 UTC (permalink / raw)
To: cpufreq, davej
Even though the core stated that cpuinfo.transition_latency needs to be
in 10^(-9) s, hardly any driver set it to nanoseconds but to microseconds.
So, fix up the drivers.
arch/arm/mach-integrator/cpu.c | 2 +-
arch/i386/kernel/cpu/cpufreq/acpi.c | 4 ++--
arch/i386/kernel/cpu/cpufreq/p4-clockmod.c | 2 +-
arch/i386/kernel/cpu/cpufreq/powernow-k7.c | 2 +-
arch/i386/kernel/cpu/cpufreq/powernow-k8.c | 4 ++--
include/linux/cpufreq.h | 2 +-
6 files changed, 8 insertions(+), 8 deletions(-)
diff -ruN linux-original/arch/arm/mach-integrator/cpu.c linux/arch/arm/mach-integrator/cpu.c
--- linux-original/arch/arm/mach-integrator/cpu.c 2003-11-19 17:06:11.554719384 +0100
+++ linux/arch/arm/mach-integrator/cpu.c 2003-11-19 18:43:38.036918992 +0100
@@ -172,7 +172,7 @@
policy->governor = CPUFREQ_DEFAULT_GOVERNOR;
policy->cpuinfo.max_freq = 160000;
policy->cpuinfo.min_freq = 12000;
- policy->cpuinfo.transition_latency = 1000; /* 1 ms, assumed */
+ policy->cpuinfo.transition_latency = 1000000; /* 1 ms, assumed */
policy->cur = policy->min = policy->max =
icst525_khz(&cclk_params, vco); /* current freq */
diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/acpi.c linux/arch/i386/kernel/cpu/cpufreq/acpi.c
--- linux-original/arch/i386/kernel/cpu/cpufreq/acpi.c 2003-11-19 17:06:10.570868952 +0100
+++ linux/arch/i386/kernel/cpu/cpufreq/acpi.c 2003-11-19 18:46:00.268296536 +0100
@@ -578,8 +578,8 @@
/* detect transition latency */
policy->cpuinfo.transition_latency = 0;
for (i=0;i<perf->state_count;i++) {
- if (perf->states[i].transition_latency > policy->cpuinfo.transition_latency)
- policy->cpuinfo.transition_latency = perf->states[i].transition_latency;
+ if ((perf->states[i].transition_latency * 1000) > policy->cpuinfo.transition_latency)
+ policy->cpuinfo.transition_latency = perf->states[i].transition_latency * 1000;
}
policy->governor = CPUFREQ_DEFAULT_GOVERNOR;
policy->cur = perf->states[pr->limit.state.px].core_frequency * 1000;
diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c linux/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c
--- linux-original/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c 2003-11-19 18:22:58.441366160 +0100
+++ linux/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c 2003-11-19 18:44:47.510357424 +0100
@@ -255,7 +255,7 @@
/* cpuinfo and default policy values */
policy->governor = CPUFREQ_DEFAULT_GOVERNOR;
- policy->cpuinfo.transition_latency = 1000;
+ policy->cpuinfo.transition_latency = 1000000; /* assumed */
policy->cur = stock_freq;
return cpufreq_frequency_table_cpuinfo(policy, &p4clockmod_table[0]);
diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/powernow-k7.c linux/arch/i386/kernel/cpu/cpufreq/powernow-k7.c
--- linux-original/arch/i386/kernel/cpu/cpufreq/powernow-k7.c 2003-11-19 17:06:10.571868800 +0100
+++ linux/arch/i386/kernel/cpu/cpufreq/powernow-k7.c 2003-11-19 18:48:10.150551432 +0100
@@ -386,7 +386,7 @@
minimum_speed, maximum_speed);
policy->governor = CPUFREQ_DEFAULT_GOVERNOR;
- policy->cpuinfo.transition_latency = latency;
+ policy->cpuinfo.transition_latency = latency * 20;
policy->cur = maximum_speed;
return cpufreq_frequency_table_cpuinfo(policy, powernow_table);
diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/powernow-k8.c linux/arch/i386/kernel/cpu/cpufreq/powernow-k8.c
--- linux-original/arch/i386/kernel/cpu/cpufreq/powernow-k8.c 2003-11-19 17:07:58.537455536 +0100
+++ linux/arch/i386/kernel/cpu/cpufreq/powernow-k8.c 2003-11-19 18:46:57.031667192 +0100
@@ -959,8 +959,8 @@
pol->governor = CPUFREQ_DEFAULT_GOVERNOR;
/* Take a crude guess here. */
- pol->cpuinfo.transition_latency = ((rvo + 8) * vstable * VST_UNITS_20US)
- + (3 * (1 << irt) * 10);
+ pol->cpuinfo.transition_latency = (((rvo + 8) * vstable * VST_UNITS_20US)
+ + (3 * (1 << irt) * 10)) * 1000;
if (query_current_values_with_pending_wait())
return -EIO;
diff -ruN linux-original/include/linux/cpufreq.h linux/include/linux/cpufreq.h
--- linux-original/include/linux/cpufreq.h 2003-11-19 18:38:58.586401928 +0100
+++ linux/include/linux/cpufreq.h 2003-11-19 18:42:27.944574648 +0100
@@ -57,7 +57,7 @@
struct cpufreq_cpuinfo {
unsigned int max_freq;
unsigned int min_freq;
- unsigned int transition_latency; /* in 10^(-9) s */
+ unsigned int transition_latency; /* in 10^(-9) s = nanoseconds */
};
struct cpufreq_real_policy {
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [PATCH 7/8] latency must be in _nano_seconds 2003-11-19 18:33 [PATCH 7/8] latency must be in _nano_seconds Dominik Brodowski @ 2003-11-19 19:07 ` Dave Jones 2003-11-20 18:31 ` Dominik Brodowski 0 siblings, 1 reply; 3+ messages in thread From: Dave Jones @ 2003-11-19 19:07 UTC (permalink / raw) To: Dominik Brodowski; +Cc: cpufreq On Wed, Nov 19, 2003 at 07:33:30PM +0100, Dominik Brodowski wrote: > return cpufreq_frequency_table_cpuinfo(policy, &p4clockmod_table[0]); > diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/powernow-k7.c linux/arch/i386/kernel/cpu/cpufreq/powernow-k7.c > --- linux-original/arch/i386/kernel/cpu/cpufreq/powernow-k7.c 2003-11-19 17:06:10.571868800 +0100 > +++ linux/arch/i386/kernel/cpu/cpufreq/powernow-k7.c 2003-11-19 18:48:10.150551432 +0100 > @@ -386,7 +386,7 @@ > minimum_speed, maximum_speed); > > policy->governor = CPUFREQ_DEFAULT_GOVERNOR; > - policy->cpuinfo.transition_latency = latency; > + policy->cpuinfo.transition_latency = latency * 20; > policy->cur = maximum_speed; Can we at least get a comment explaining where '20' comes from when we add magic numbers like this? I know, and you know, but it's a little non-obvious, and in six months time, I'll probably have forgotten too 8) > diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/powernow-k8.c linux/arch/i386/kernel/cpu/cpufreq/powernow-k8.c > --- linux-original/arch/i386/kernel/cpu/cpufreq/powernow-k8.c 2003-11-19 17:07:58.537455536 +0100 > +++ linux/arch/i386/kernel/cpu/cpufreq/powernow-k8.c 2003-11-19 18:46:57.031667192 +0100 > @@ -959,8 +959,8 @@ > pol->governor = CPUFREQ_DEFAULT_GOVERNOR; > > /* Take a crude guess here. */ > - pol->cpuinfo.transition_latency = ((rvo + 8) * vstable * VST_UNITS_20US) > - + (3 * (1 << irt) * 10); > + pol->cpuinfo.transition_latency = (((rvo + 8) * vstable * VST_UNITS_20US) > + + (3 * (1 << irt) * 10)) * 1000; Ditto. This one moreso, as its quite complex to begin with. Dave ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH 7/8] latency must be in _nano_seconds 2003-11-19 19:07 ` Dave Jones @ 2003-11-20 18:31 ` Dominik Brodowski 0 siblings, 0 replies; 3+ messages in thread From: Dominik Brodowski @ 2003-11-20 18:31 UTC (permalink / raw) To: Dave Jones; +Cc: cpufreq On Wed, Nov 19, 2003 at 07:07:25PM +0000, Dave Jones wrote: > On Wed, Nov 19, 2003 at 07:33:30PM +0100, Dominik Brodowski wrote: > > > return cpufreq_frequency_table_cpuinfo(policy, &p4clockmod_table[0]); > > diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/powernow-k7.c linux/arch/i386/kernel/cpu/cpufreq/powernow-k7.c > > --- linux-original/arch/i386/kernel/cpu/cpufreq/powernow-k7.c 2003-11-19 17:06:10.571868800 +0100 > > +++ linux/arch/i386/kernel/cpu/cpufreq/powernow-k7.c 2003-11-19 18:48:10.150551432 +0100 > > @@ -386,7 +386,7 @@ > > minimum_speed, maximum_speed); > > > > policy->governor = CPUFREQ_DEFAULT_GOVERNOR; > > - policy->cpuinfo.transition_latency = latency; > > + policy->cpuinfo.transition_latency = latency * 20; > > policy->cur = maximum_speed; > > Can we at least get a comment explaining where '20' comes from > when we add magic numbers like this? I know, and you know, but > it's a little non-obvious, and in six months time, I'll probably > have forgotten too 8) Comment added. > > diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/powernow-k8.c linux/arch/i386/kernel/cpu/cpufreq/powernow-k8.c > > --- linux-original/arch/i386/kernel/cpu/cpufreq/powernow-k8.c 2003-11-19 17:07:58.537455536 +0100 > > +++ linux/arch/i386/kernel/cpu/cpufreq/powernow-k8.c 2003-11-19 18:46:57.031667192 +0100 > > @@ -959,8 +959,8 @@ > > pol->governor = CPUFREQ_DEFAULT_GOVERNOR; > > > > /* Take a crude guess here. */ > > - pol->cpuinfo.transition_latency = ((rvo + 8) * vstable * VST_UNITS_20US) > > - + (3 * (1 << irt) * 10); > > + pol->cpuinfo.transition_latency = (((rvo + 8) * vstable * VST_UNITS_20US) > > + + (3 * (1 << irt) * 10)) * 1000; > > Ditto. This one moreso, as its quite complex to begin with. What Paul Devriendt did here I do not know, but I added a comment for the factor "1000"... Dominik Even though the core stated that cpuinfo.transition_latency needs to be in 10^(-9) s, hardly any driver set it to nanoseconds but to microseconds. So, fix up the drivers. arch/arm/mach-integrator/cpu.c | 2 +- arch/i386/kernel/cpu/cpufreq/acpi.c | 4 ++-- arch/i386/kernel/cpu/cpufreq/p4-clockmod.c | 2 +- arch/i386/kernel/cpu/cpufreq/powernow-k7.c | 6 +++++- arch/i386/kernel/cpu/cpufreq/powernow-k8.c | 7 ++++--- include/linux/cpufreq.h | 2 +- 6 files changed, 14 insertions(+), 9 deletions(-) diff -ruN linux-original/arch/arm/mach-integrator/cpu.c linux/arch/arm/mach-integrator/cpu.c --- linux-original/arch/arm/mach-integrator/cpu.c 2003-11-20 19:17:28.489660360 +0100 +++ linux/arch/arm/mach-integrator/cpu.c 2003-11-20 19:17:34.311775264 +0100 @@ -172,7 +172,7 @@ policy->governor = CPUFREQ_DEFAULT_GOVERNOR; policy->cpuinfo.max_freq = 160000; policy->cpuinfo.min_freq = 12000; - policy->cpuinfo.transition_latency = 1000; /* 1 ms, assumed */ + policy->cpuinfo.transition_latency = 1000000; /* 1 ms, assumed */ policy->cur = policy->min = policy->max = icst525_khz(&cclk_params, vco); /* current freq */ diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/acpi.c linux/arch/i386/kernel/cpu/cpufreq/acpi.c --- linux-original/arch/i386/kernel/cpu/cpufreq/acpi.c 2003-11-20 19:17:28.510657168 +0100 +++ linux/arch/i386/kernel/cpu/cpufreq/acpi.c 2003-11-20 19:17:34.312775112 +0100 @@ -578,8 +578,8 @@ /* detect transition latency */ policy->cpuinfo.transition_latency = 0; for (i=0;i<perf->state_count;i++) { - if (perf->states[i].transition_latency > policy->cpuinfo.transition_latency) - policy->cpuinfo.transition_latency = perf->states[i].transition_latency; + if ((perf->states[i].transition_latency * 1000) > policy->cpuinfo.transition_latency) + policy->cpuinfo.transition_latency = perf->states[i].transition_latency * 1000; } policy->governor = CPUFREQ_DEFAULT_GOVERNOR; policy->cur = perf->states[pr->limit.state.px].core_frequency * 1000; diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c linux/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c --- linux-original/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c 2003-11-20 19:17:28.540652608 +0100 +++ linux/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c 2003-11-20 19:17:34.312775112 +0100 @@ -255,7 +255,7 @@ /* cpuinfo and default policy values */ policy->governor = CPUFREQ_DEFAULT_GOVERNOR; - policy->cpuinfo.transition_latency = 1000; + policy->cpuinfo.transition_latency = 1000000; /* assumed */ policy->cur = stock_freq; return cpufreq_frequency_table_cpuinfo(policy, &p4clockmod_table[0]); diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/powernow-k7.c linux/arch/i386/kernel/cpu/cpufreq/powernow-k7.c --- linux-original/arch/i386/kernel/cpu/cpufreq/powernow-k7.c 2003-11-20 19:17:28.541652456 +0100 +++ linux/arch/i386/kernel/cpu/cpufreq/powernow-k7.c 2003-11-20 19:20:35.230271472 +0100 @@ -386,7 +386,11 @@ minimum_speed, maximum_speed); policy->governor = CPUFREQ_DEFAULT_GOVERNOR; - policy->cpuinfo.transition_latency = latency; + + /* latency is in 10 ns (look for SGTC above) for each VID + * and FID transition, so multiply that value with 20 */ + policy->cpuinfo.transition_latency = latency * 20; + policy->cur = maximum_speed; return cpufreq_frequency_table_cpuinfo(policy, powernow_table); diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/powernow-k8.c linux/arch/i386/kernel/cpu/cpufreq/powernow-k8.c --- linux-original/arch/i386/kernel/cpu/cpufreq/powernow-k8.c 2003-11-20 19:17:28.591644856 +0100 +++ linux/arch/i386/kernel/cpu/cpufreq/powernow-k8.c 2003-11-20 19:18:45.550945264 +0100 @@ -958,9 +958,10 @@ pol->governor = CPUFREQ_DEFAULT_GOVERNOR; - /* Take a crude guess here. */ - pol->cpuinfo.transition_latency = ((rvo + 8) * vstable * VST_UNITS_20US) - + (3 * (1 << irt) * 10); + /* Take a crude guess here. + * That guess was in microseconds, so multply with 1000 */ + pol->cpuinfo.transition_latency = (((rvo + 8) * vstable * VST_UNITS_20US) + + (3 * (1 << irt) * 10)) * 1000; if (query_current_values_with_pending_wait()) return -EIO; diff -ruN linux-original/include/linux/cpufreq.h linux/include/linux/cpufreq.h --- linux-original/include/linux/cpufreq.h 2003-11-20 19:17:28.695629048 +0100 +++ linux/include/linux/cpufreq.h 2003-11-20 19:17:34.314774808 +0100 @@ -57,7 +57,7 @@ struct cpufreq_cpuinfo { unsigned int max_freq; unsigned int min_freq; - unsigned int transition_latency; /* in 10^(-9) s */ + unsigned int transition_latency; /* in 10^(-9) s = nanoseconds */ }; struct cpufreq_real_policy { ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2003-11-20 18:31 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2003-11-19 18:33 [PATCH 7/8] latency must be in _nano_seconds Dominik Brodowski 2003-11-19 19:07 ` Dave Jones 2003-11-20 18:31 ` Dominik Brodowski
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.