[lkml]   [2001]   [Apr]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:24    [W:0.020 / U:12.096 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site