From: Rene Herman <rene.herman@keyaccess.nl>
To: "David P. Reed" <dpreed@reed.com>, Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
Dmitry Torokhov <dtor_core@ameritech.net>,
linux-kernel@vger.kernel.org
Subject: Re: [linux-kernel] Re: [PATCH] x86: use explicit timing delay for pit accesses in kernel and pcspkr driver
Date: Thu, 21 Feb 2008 07:21:11 +0100 [thread overview]
Message-ID: <47BD1857.9000505@keyaccess.nl> (raw)
In-Reply-To: <47BC89F5.90305@reed.com>
[-- Attachment #1: Type: text/plain, Size: 1896 bytes --]
On 20-02-08 21:13, David P. Reed wrote:
> Actually, disparaging things as "one idiotic system" doesn't seem like a
> long-term thoughtful process - it's not even accurate.
Whatever we think about systems using port 0x80, fact of the matter is that
they do and outside of legacy stuff that isn't applicable to these systems,
Linux needs to stop using it (post ACPI init at least) to be able to run on
them.
As options of doing so we have:
1) Replace the port 0x80 I/O delay with nothing. Determined to be unsafe.
2) Replace 0x80 with another port. None are really available and DMI based
switching gets to be unmaintainable and has a such been shot down.
3) Replace the port 0x80 I/O delay with a udelay(2). Should work well enough
in practice for the remaining users outside legacy drivers after (Alan's)
cleaning up.
The remaining (possible) problem is that pre calibration microseconds are a
total fiction and at least PIT init happens before calibration. In practice
I believe this might not be much of a real-world problem since for whatever
initial value for loops_per_jiffy we get at least our old double short jump
that is enough of a delay for 386 and 486 but I sympathise with anone, such
as HPA, who'd consider my beliefs not a particular guarantee.
So, we need a more useful pre calibration udelay. Ugly as it might be,
through something like the attached. Alan, could you perhaps comment?
With the problam surfacing only post ACPI init, the _last_ remaining option
is talking to the PIT using port 0x80 at init and using udelay after but I
myself will not be submitting a patch to do so. Insane mess.
It would be good to get this crap sorted relatively quickly so we can do
away with the io_delay mongering even pre .26 again. It introduces boot
parameters and as such becomes part of API somewhat, so if it's not going to
stay let's kill it quickly.
Ren
[-- Attachment #2: per-family-loops_per_jiffy.diff --]
[-- Type: text/plain, Size: 2525 bytes --]
commit 9c679215248e837b34242632d5a22adf9a247021
Author: Rene Herman <rene.herman@gmail.com>
Date: Wed Feb 20 12:52:30 2008 +0100
x86: per CPU family loops_per_jiffy initialization
Following the current port 0x80 I/O delay replacements we need
microseconds to be somewhat usefully defined pre calibration.
Initialize 386, 486 and Pentium 1 as fastest in their families
and higher CPUs (including 64-bit) at 1 Ghz. Note that trouble
should be absent past family 5 systems anyway.
Signed-off-by: Rene Herman <rene.herman@gmail.com>
diff --git a/arch/x86/kernel/time_32.c b/arch/x86/kernel/time_32.c
index 1a89e93..e33e70b 100644
--- a/arch/x86/kernel/time_32.c
+++ b/arch/x86/kernel/time_32.c
@@ -32,6 +32,7 @@
#include <linux/interrupt.h>
#include <linux/time.h>
#include <linux/mca.h>
+#include <linux/delay.h>
#include <asm/arch_hooks.h>
#include <asm/hpet.h>
@@ -134,6 +135,17 @@ void __init hpet_time_init(void)
*/
void __init time_init(void)
{
+ switch (boot_cpu_data.x86) {
+ case 3:
+ loops_per_jiffy = LOOPS_PER_JIFFY_386;
+ break;
+ case 4:
+ loops_per_jiffy = LOOPS_PER_JIFFY_486;
+ break;
+ case 5:
+ loops_per_jiffy = LOOPS_PER_JIFFY_586;
+ break;
+ }
tsc_init();
late_time_init = choose_time_init();
}
diff --git a/include/asm-x86/delay.h b/include/asm-x86/delay.h
index 409a649..d0fbaf6 100644
--- a/include/asm-x86/delay.h
+++ b/include/asm-x86/delay.h
@@ -7,6 +7,11 @@
* Delay routines calling functions in arch/x86/lib/delay.c
*/
+#define LOOPS_PER_JIFFY_386 (4000000 / HZ) /* 386 at 40 Mhz */
+#define LOOPS_PER_JIFFY_486 (30000000 / HZ) /* 486 at 120 MHz */
+#define LOOPS_PER_JIFFY_586 (233000000 / HZ) /* Pentium 1 at 233 Mhz */
+#define LOOPS_PER_JIFFY (1000000000 / HZ) /* P6+ at 1 GHz */
+
/* Undefined functions to get compile-time errors */
extern void __bad_udelay(void);
extern void __bad_ndelay(void);
diff --git a/init/main.c b/init/main.c
index 8b19820..94862c8 100644
--- a/init/main.c
+++ b/init/main.c
@@ -228,12 +228,11 @@ static int __init obsolete_checksetup(char *line)
return had_early_param;
}
-/*
- * This should be approx 2 Bo*oMips to start (note initial shift), and will
- * still work even if initially too large, it will just take slightly longer
- */
-unsigned long loops_per_jiffy = (1<<12);
+#ifndef LOOPS_PER_JIFFY
+#define LOOPS_PER_JIFFY (1 << 12)
+#endif
+unsigned long loops_per_jiffy = LOOPS_PER_JIFFY;
EXPORT_SYMBOL(loops_per_jiffy);
static int __init debug_kernel(char *str)
next prev parent reply other threads:[~2008-02-21 6:19 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-18 18:58 [PATCH] x86: use explicit timing delay for pit accesses in kernel and pcspkr driver David P. Reed
2008-02-18 20:17 ` Alan Cox
2008-02-18 20:38 ` Rene Herman
2008-02-18 20:43 ` H. Peter Anvin
2008-02-18 21:04 ` Rene Herman
2008-02-18 21:05 ` Rene Herman
2008-02-18 21:44 ` H. Peter Anvin
2008-02-18 21:59 ` Rene Herman
2008-02-18 22:01 ` H. Peter Anvin
2008-02-18 22:07 ` Rene Herman
2008-02-18 22:32 ` Rene Herman
2008-02-18 22:44 ` H. Peter Anvin
2008-02-20 12:06 ` Rene Herman
2008-02-20 17:05 ` H. Peter Anvin
2008-02-20 17:09 ` Rene Herman
2008-02-20 20:13 ` [linux-kernel] " David P. Reed
2008-02-21 6:21 ` Rene Herman [this message]
2008-02-18 22:43 ` H. Peter Anvin
2008-02-19 9:46 ` Ingo Molnar
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=47BD1857.9000505@keyaccess.nl \
--to=rene.herman@keyaccess.nl \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=dpreed@reed.com \
--cc=dtor_core@ameritech.net \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
/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