From: Marcus Sundberg <mackan@stacken.kth.se>
  To  : ggi-develop@eskimo.com
  Date: 02 Nov 1999 21:54:33 +0100

Re: gicon and low-level I/O

"Jon M. Taylor" <taylorj@ecs.csus.edu> writes:

> 	Our mmap() handler sets the _PAGE_PCD (page cache disable) flag on
> the regions it maps.  I'll bet that's it.  And we are doing the right
> thing - this flag should _always_ be enabled for MMIO register regions.  
> If matroxfb works without it, great (or lucky), but lots of other chipsets
> can react very badly if their register MMIO goes through the L2 cache.

Of course matroxfb doesn't cache the MMIO region - if it did then
nothing would work. In any case the mmap() code is more or less
identical to the mmap() code matroxfb uses, which makes this thing
so strange...

> The
> linux-kernel archives show that this flag used to always be set for high
> PCI memory region mappings, to avoid XFree86-related problems.

If it's XFree-related then it's about mapping /dev/mem, and that
is still uncached when you map memory above main RAM. But that
doesn't affect memory mapped through other device nodes.

> 	We also enable this flag for the LFB region, which is actually
> _not_ necessary in most (all?)

It's mandatory if you have an on-board chip that ever draws to video
memory, which means all remotely modern hardware.

> cases and probably costs us some performance.

Caching would actually hurt performance even if you don't use HW
accelerated drawing. If you write just one single byte to a cache-line
the whole cache-line will have to be read in from video-memory
(and reading video RAM is usually even slower than writing it)
unless it's present in cache, and then written back to video
RAM again when the cache is flushed.

And you would either have to explicitly flush all touched cache
lines after every drawing operation, or you would have to flush
the entire video RAM-area in ggiFlush(). Caching video-RAM is
in short a very bad idea.

>  The one-size-fits-all solution we are using now in
> kgifb_mmap() looks like needing replacement - there are too many
> driver-specific special cases to be able to handle them cleanly in
> fbcon-kgi.c.  Perhaps we need to start making use of the 'prot'
> (protection flags) field in the kgi_mmio_region struct.  We need this to
> let the driver tell fbcon-kgi.c about cache policy, MTRR policy, AGP
> flags, etc etc etc on a per-region basis.

Basicly you never want to cache anything that sits on the other side
of the PCI-bus. MTRR write combining should always be turned on for
memory, but never for registers. That's about it.
AGP is ofcourse another story...

//Marcus
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |   E-Mail: mackan@stacken.kth.se