lkml.org 
[lkml]   [2001]   [Apr]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:24    [W:0.079 / U:0.388 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site