[lkml]   [2008]   [Jan]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On 01-01-08 20:35, Christer Weinigel wrote:

> On Tue, 1 Jan 2008 19:46:59 +0100
> Ingo Molnar <> wrote:
>> * Christer Weinigel <> wrote:
>>> What I'm afraid is that udelay will be significantly slower, [...]
>> why should it be significantly slower?
> out 80h, al is only two bytes. Any alternative that has been suggested
> in this discussion will use more space. mov dx, alt_port; out dx, al
> will be larger, a function call will definitely be a lot larger. People
> have been making changes to the kernel to save a couple of hundred
> bytes of text size.
> On old hardware (or anything with an ISA bus which I'd guess includes
> the Geode SCx200 SoC which is basically a MediaGX processor, a
> southbridge and an ISA bus with a Super I/O chip on it) an out to 80h
> will use exactly one ISA cycle.

Not to disagree with the point but more like 8 (1 us at 8 MHz). It's the
timeout property.

> A call to udelay will need a margin,
> so it will be slightly slower. And that's assuming that you can find
> out the speed of the ISA bus, if you can't you'll have to assume the
> slowest possible bus (6 MHz I guess) which will be a lot slower.
> I don't know if the difference in code size or the udelay will be
> significantly slower, but I think it might be.

There's also the bit about microseconds being very losely defined pre
loops_per_jiffy calibration. Per CPU-family init helps somewhat but
certainly for family 6 (Pentium Pro, II, III -- lots of hardware with ISA
busses therefore) speeds vary quite a bit still.

> And to take the MediaGX as an example, the TSC is not usable on that
> CPU, so Linux has to use the PIT timer for gettimeofday. As I wrote
> in a different post, I believe the PIT on the SCx200 needs outb_p to
> work reliably. So if outb_p becomes significantly slower that will
> affect a critical path on a very common embedded CPU.
> I'm not sure what Alan meant with his comments about locking, but if
> changing outb_p to use an udelay means that we have to add locking,
> that is also going to affect the code size and speed.

Explained here:

However, that's not an argument. Missing locking is a bug, and current outb
I/O delay use hiding it doesn't change that.


 \ /
  Last update: 2008-01-01 21:05    [W:0.155 / U:3.456 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site