Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64with MCP51 laptops
From: Rene Herman
Date: Tue Dec 11 2007 - 09:16:18 EST
On 11-12-07 14:50, David Newall wrote:
Rene Herman wrote:
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.
That could be true if outb_p were used only in architecture dependent
It not only could be, it _is_ true. Not using an output to port 0x80 is what
this discussion is about.
code, but it's not. It's used in drivers that are supposed to run on
all sorts of platforms. Why does a megaraid controller need delays on
i386 but not on Sparc, PowerPC, Alpha and others? Is it buggy on most
platforms, or just unnecessarily slow on Intel?
The latter probably and I don't bleedin' well care. In a discussion about
removing the out to 0x80 the only thing that is relevant is what it should
be replaced with. Usually, "nothing" will do but generally, udelay(1) will.
is needed, wouldn't you use a real delay; one that says how long it
should be?
Thinking that _p gives a pause is perhaps too PC-centric. Why, if a delay
Because any possible outb_p delay should be synced to the bus-clock,
not to any wall-clock.
You misunderstand. A delay can be counted in bus cycles.
No damnit, you misunderstand. I'm saying that an outb_p _should_ be defined
in terms of the bus clock since if you want a wall-clock delay you should be
using just that.
The _hardware_ is synced to the bus clock and therefore, having a delay
available that is synced to the bus clock as well makes some sense. And
again again again again not withstanding that, a udelay will still be an
okay replacement in practice.
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/