Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

[Rene Herman]

On 01-01-08 20:35, Christer Weinigel wrote:

> On Tue, 1 Jan 2008 19:46:59 +0100
> Ingo Molnar <mingo@xxxxxxx> wrote:
>
> > * Christer Weinigel <christer@xxxxxxxxxxx> 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:

http://lkml.org/lkml/2007/12/30/136

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

Rene.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/