From: Dominik Brodowski <linux@brodo.de>
To: cpufreq@www.linux.org.uk, davej@codemonkey.org.uk
Subject: [PATCH 7/8] latency must be in _nano_seconds
Date: Wed, 19 Nov 2003 19:33:30 +0100 [thread overview]
Message-ID: <20031119183330.GH20576@brodo.de> (raw)
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 {
next reply other threads:[~2003-11-19 18:33 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-19 18:33 Dominik Brodowski [this message]
2003-11-19 19:07 ` [PATCH 7/8] latency must be in _nano_seconds Dave Jones
2003-11-20 18:31 ` Dominik Brodowski
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=20031119183330.GH20576@brodo.de \
--to=linux@brodo.de \
--cc=cpufreq@www.linux.org.uk \
--cc=davej@codemonkey.org.uk \
/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