Messages in this thread | | | Date | Sun, 8 Apr 2001 22:11:23 +0400 | From | Ivan Kokshaysky <> | Subject | Re: [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/
| |