Cc: Alan Cox <alan@...>, David P. Reed <dpreed@...>, H. Peter Anvin <hpa@...>, Rene Herman <rene.herman@...>, Paul Rolland <rol@...>, Pavel Machek <pavel@...>, Thomas Gleixner <tglx@...>, <linux-kernel@...>, Ingo Molnar <mingo@...>, <rol@...>
On Tue, 1 Jan 2008 19:46:59 +0100
Ingo Molnar <mingo@elte.hu> wrote:
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
--
