[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <475E8D91.20201@keyaccess.nl>
Date: Tue, 11 Dec 2007 14:16:01 +0100
From: Rene Herman <rene.herman@...access.nl>
To: David Newall <david@...idnewall.com>
CC: Paul Rolland <rol@...917.net>, "H. Peter Anvin" <hpa@...or.com>,
Krzysztof Halasa <khc@...waw.pl>, Pavel Machek <pavel@....cz>,
Andi Kleen <andi@...stfloor.org>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
"David P. Reed" <dpreed@...d.com>, linux-kernel@...r.kernel.org,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, rol@...be.net
Subject: Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64
with MCP51 laptops
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.
View attachment "port80.c" of type "text/plain" (635 bytes)
Powered by blists - more mailing lists