[lkml]   [2001]   [Apr]   [6]   [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 5 Apr 2001, Eric W. Biederman wrote:

> The point is on the Alpha all ram is always cached, and i/o space is
> completely uncached. You cannot do write-combing for video card

You don't want to cache fb memory, do you? All you want is write
combining and you achieve it with memory barriers. You write to fb memory
space whatever you need to and write buffers actually deliver data to fb
memory whenever the bus is idle or they get filled up. When you finally
decide you wrote all data and you want ensure it actually reaches the fb
memory before you perform an operation (say you send a command to fb's
support circuitry) you issue a write memory barrier. Or a memory barrier,
if you want ensure the data reaches the fb memory ASAP.

In other words, you have write-combining by default and request
write-through explicitly.

> memory. Memory barriers are a separate issue. On the alpha the
> natural way to implement it would be in the page table fill code.

Please forgive me -- I can't see how this is related to write combining.

> Memory barriers are o.k. but the really don't help the case when what
> you want to do is read the latest value out of a pci register.

They do -- you issue an mb and you are sure all pending writes reached
the involved PCI hw.

+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+ e-mail:, PGP key available +

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.115 / U:18.804 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site