From: Rene Herman <rene.herman@keyaccess.nl>
To: David Newall <david@davidnewall.com>
Cc: Paul Rolland <rol@as2917.net>, "H. Peter Anvin" <hpa@zytor.com>,
Krzysztof Halasa <khc@pm.waw.pl>, Pavel Machek <pavel@ucw.cz>,
Andi Kleen <andi@firstfloor.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
"David P. Reed" <dpreed@reed.com>,
linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
rol@witbe.net
Subject: Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Date: Tue, 11 Dec 2007 14:16:01 +0100 [thread overview]
Message-ID: <475E8D91.20201@keyaccess.nl> (raw)
In-Reply-To: <475E7DC2.4060509@davidnewall.com>
[-- Attachment #1: Type: text/plain, Size: 1829 bytes --]
On 11-12-07 13:08, David Newall wrote:
> Rene Herman wrote:
>> On 11-12-07 08:40, Paul Rolland wrote:
>>
>>> Well, if the delay is so much unspecified, what about _reading_ port
>>> 0x80 ?
>>> Will the delay be shorter ?
>>
>> The delay is completely and fully specified in terms of the ISA/LPC clock
>
> That would be the delay on the i386 (sic) architecture. In general,
> though, the delay is:
This particular discussion isn't about anything in general but solely about
the delay an outb_p gives you on x86 since what is under discussion is not
using an output to port 0x80 on that platform to generate it.
> Thinking that _p gives a pause is perhaps too PC-centric. Why, if a delay
> is needed, wouldn't you use a real delay; one that says how long it
> should be?
Because any possible outb_p delay should be synced to the bus-clock, not to
any wall-clock. Drivers that want to sync to wall-clock need to use an outb,
delay pair as you'd expect.
In the real world, driver authors aren't perfect and will have used outb_p
as a wall-clock delay which they have gotten away with since it's a nicely
specified delay in terms of the ISA/LPC clock and the ISA/LPC clock being
fairly (old) to very (new) constant.
The delay it gives is very close to 1 us on a spec ISA/LPC bus (*) and as
such, even though it may not be the right thing to do from an theoretical
standpoint, generally a udelay(1) is going to be a fine replacement from a
practical one -- as soon as we _can_ use udelay(), as I also wrote.
Rene.
(*) some local testing shows it to be almost exactly that for both out and
in on my own PC -- a little over. If anyone cares, see attached little test
program. The "little over" I don't worry about. 0 us delay is also fine for
me and if any code was _that_ fragile it would have broken long ago.
[-- Attachment #2: port80.c --]
[-- Type: text/plain, Size: 634 bytes --]
#include <stdlib.h>
#include <stdio.h>
#include <sys/io.h>
int main(void)
{
unsigned long cycles;
if (iopl(3) < 0) {
perror("iopl");
return EXIT_FAILURE;
}
asm ( "cli \n\t"
"rdtsc \n\t"
"movl %%eax, %%ecx \n\t"
"outb %%al, $0x80 \n\t"
"rdtsc \n\t"
"subl %%ecx, %%eax \n\t"
"sti "
: "=a" (cycles) : : "ecx", "edx");
printf("out = %lu\n", cycles);
asm ( "cli \n\t"
"rdtsc \n\t"
"movl %%eax, %%ecx \n\t"
"inb $0x80, %%al \n\t"
"rdtsc \n\t"
"subl %%ecx, %%eax \n\t"
"sti "
: "=a" (cycles) : : "ecx", "edx");
printf("in = %lu\n", cycles);
return EXIT_FAILURE;
}
next prev parent reply other threads:[~2007-12-11 13:18 UTC|newest]
Thread overview: 125+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-06 22:38 RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops David P. Reed
2007-12-07 0:15 ` Alan Cox
2007-12-07 10:44 ` Andi Kleen
2007-12-07 14:50 ` David P. Reed
2007-12-05 11:10 ` Pavel Machek
2007-12-08 0:21 ` Andi Kleen
2007-12-07 14:54 ` Andi Kleen
2007-12-07 15:43 ` Rene Herman
2007-12-07 16:28 ` Rene Herman
2007-12-11 0:31 ` H. Peter Anvin
2007-12-11 5:53 ` H. Peter Anvin
2007-12-07 16:04 ` Alan Cox
2007-12-07 16:31 ` Andi Kleen
2007-12-07 17:19 ` Alan Cox
2007-12-07 18:45 ` Rene Herman
2007-12-07 18:42 ` Alan Cox
2007-12-07 19:25 ` Rene Herman
2007-12-07 21:45 ` Alan Cox
2007-12-08 19:25 ` David P. Reed
2007-12-08 19:50 ` Andi Kleen
2007-12-08 20:47 ` David P. Reed
2007-12-08 21:04 ` Alan Cox
2007-12-08 20:26 ` Alan Cox
2007-12-11 5:58 ` H. Peter Anvin
2007-12-09 5:04 ` Rene Herman
2007-12-09 13:22 ` Pavel Machek
2007-12-11 15:14 ` Lennart Sorensen
2007-12-09 12:54 ` Pavel Machek
2007-12-09 13:41 ` Dr. David Alan Gilbert
2007-12-09 15:54 ` Ondrej Zary
2007-12-09 16:59 ` Andi Kleen
2007-12-09 21:25 ` Pavel Machek
2007-12-09 22:29 ` Alan Cox
2007-12-09 23:22 ` Pavel Machek
2007-12-10 12:02 ` Alan Cox
2007-12-10 4:17 ` Rene Herman
2007-12-10 11:30 ` Krzysztof Halasa
2007-12-10 12:08 ` Rene Herman
2007-12-10 18:02 ` Ondrej Zary
2007-12-11 1:10 ` David Newall
2007-12-11 1:25 ` H. Peter Anvin
2007-12-11 1:42 ` David Newall
2007-12-11 1:46 ` H. Peter Anvin
2007-12-11 1:51 ` H. Peter Anvin
2007-12-11 7:40 ` Paul Rolland
2007-12-11 9:50 ` Rene Herman
2007-12-11 12:08 ` David Newall
2007-12-11 13:16 ` Rene Herman [this message]
2007-12-11 13:32 ` Paul Rolland
2007-12-11 14:15 ` Rene Herman
2007-12-11 15:28 ` Rene Herman
2007-12-11 15:37 ` Paul Rolland
2007-12-11 15:53 ` Rene Herman
2007-12-11 16:58 ` David P. Reed
2007-12-11 17:01 ` Rene Herman
2007-12-11 17:05 ` H. Peter Anvin
2007-12-11 17:32 ` Alan Cox
2007-12-11 19:19 ` David P. Reed
2007-12-11 19:36 ` Pavel Machek
2007-12-11 20:16 ` Alan Cox
2007-12-11 20:27 ` linux-os (Dick Johnson)
2007-12-11 20:34 ` Rene Herman
2007-12-11 21:03 ` David P. Reed
2007-12-11 23:56 ` David P. Reed
2007-12-12 13:11 ` linux-os (Dick Johnson)
2007-12-12 16:12 ` Alan Cox
2007-12-14 14:33 ` Ingo Molnar
2007-12-16 21:26 ` Pavel Machek
2007-12-17 0:02 ` Alan Cox
2007-12-17 0:03 ` Alan Cox
2007-12-17 0:28 ` Pavel Machek
2007-12-17 14:42 ` Ingo Molnar
2007-12-27 10:39 ` Pavel Machek
2007-12-12 19:42 ` Attitude problems David P. Reed
2007-12-12 20:31 ` linux-os (Dick Johnson)
2007-12-14 16:01 ` linux-os (Dick Johnson)
2007-12-11 16:32 ` RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops John Stoffel
2007-12-11 16:40 ` Rene Herman
2007-12-11 13:50 ` David Newall
2007-12-11 14:14 ` Rene Herman
2007-12-11 14:25 ` Alan Cox
2007-12-12 22:18 ` David Newall
2007-12-12 23:00 ` Alan Cox
2007-12-13 13:13 ` David P. Reed
2007-12-13 13:21 ` Alan Cox
2007-12-14 1:50 ` David P. Reed
2007-12-14 15:16 ` Alan Cox
2007-12-11 15:41 ` linux-os (Dick Johnson)
2007-12-11 16:30 ` Andi Kleen
2007-12-11 16:50 ` Rene Herman
2007-12-11 17:00 ` David P. Reed
2007-12-11 17:04 ` Rene Herman
2007-12-11 17:27 ` Rene Herman
2007-12-11 19:18 ` Pavel Machek
2007-12-11 19:16 ` Pavel Machek
2007-12-11 19:59 ` Rene Herman
2007-12-11 19:59 ` Rene Herman
2007-12-11 20:00 ` Rene Herman
2007-12-11 20:00 ` Rene Herman
2007-12-12 20:07 ` More info on port 80 symptoms on MCP51 machine David P. Reed
2007-12-12 20:26 ` Rene Herman
2007-12-12 20:37 ` David P. Reed
2007-12-12 20:58 ` Rene Herman
2007-12-12 21:01 ` Alan Cox
2007-12-12 21:12 ` H. Peter Anvin
2007-12-12 21:29 ` Alan Cox
2007-12-15 22:34 ` Allen Martin
2007-12-15 22:46 ` H. Peter Anvin
2007-12-16 0:46 ` David P. Reed
2007-12-12 21:05 ` H. Peter Anvin
2007-12-14 22:05 ` Chuck Ebbert
2007-12-15 7:22 ` Rene Herman
2007-12-11 13:14 ` RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops Alan Cox
2007-12-11 13:32 ` Andi Kleen
2007-12-11 13:47 ` Pavel Machek
2007-12-11 13:50 ` Andi Kleen
2007-12-14 13:33 ` Ingo Molnar
2007-12-11 6:54 ` Rene Herman
2007-12-11 17:01 ` H. Peter Anvin
[not found] <fa./27SNSh+L5T3iqFNPdHClEu+yT0@ifi.uio.no>
2007-12-07 0:23 ` Robert Hancock
2007-12-07 5:09 ` Rene Herman
2007-12-07 5:54 ` David P. Reed
2007-12-07 7:17 ` Rene Herman
2007-12-07 7:34 ` Rene Herman
2007-12-07 10:49 ` Andi Kleen
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=475E8D91.20201@keyaccess.nl \
--to=rene.herman@keyaccess.nl \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=andi@firstfloor.org \
--cc=david@davidnewall.com \
--cc=dpreed@reed.com \
--cc=hpa@zytor.com \
--cc=khc@pm.waw.pl \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pavel@ucw.cz \
--cc=rol@as2917.net \
--cc=rol@witbe.net \
--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;
as well as URLs for NNTP newsgroup(s).