Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

[Ivan Kokshaysky <ink@jurassic.park.msu.ru>]

On Fri, Apr 06, 2001 at 07:13:21PM +0200, Maciej W. Rozycki wrote:
>  You do.  PCI-space registers are volatile and they may change depending
> on what was written (or read) previously.  A memory barrier before a PCI
> read will ensure you get a value that is relevant to previous code
> actions.  Without a barrier you may get pretty anything, depending on
> which of previous writes managed to complete before. 

Of course. I meant that if you are reading, for example, some status register
in a loop waiting for "ready bit" set, the memory barrier won't help you
to notice this event any faster. Actually you'll notice that *later*, as
"mb" is expensive.

Well, here is some info on ev6 IO write buffers - they are a bit different
than ev4/ev5 ones.
Merging rules:
 - byte/word stores aren't allowed to merge into a write buffer;
 - different size stores (32- and 64-bit) aren't allowed to merge;
 - addresses must be in ascending order and non-overlapping,
   but not necessarily consecutive.
The I/O register merge window close (ie write-buffer flushing) occurs after
 - mb and wmb instructions;
 - IO-space load instruction (!);
 - after 1024 cycles if there were no IO-space stores.
Store requests are sent offchip in program order (!).

All this explains, in particular, why XFree86-4.0 worked on ev6 without
memory barriers of any kind, while it crashed badly on ev4/ev5.

Ivan.