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

[Christer Weinigel]

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.  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.

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.

  /Christer





--
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/