From: Johan Karlberg <wlfshmn@failure.ml.org>
  To  : GGI mailing list <ggi-develop@eskimo.com>
  Date: Sun, 16 Aug 1998 13:51:10 +0200 (CEST)

Re: kgicon and MTRRs

On Sat, 15 Aug 1998, Jon M. Taylor wrote:

[LARGE SNIP]
> 
> 	Now that my Trio64V+ driver is working again, I decided to play
> with this (I have a PPro 200).  I inserted the kgicon.o driver and then
> echoed to /proc/mtrr a command string which turned on write-combining over
> the 2MB PCI LAW region the video card occupies.  My consoles are quite
> noticeably snappier now as a result.  As soon as I can get LibGGI to work,
> I'll be able to use speed.c to come up with some benchmark numbers.  If
> you have a PPro or PII, give it a try and see what you think.
> 
> 	I'd like to add MTRR support to kgicon in some way.  Right now I
> am leaning towards a call to mtrr_add() in fbcon-kgi.c, after the card has
> been detected and initialized.  The necessary info - physical base
> address, framebuffer size - are available then.  But there are some
> potential issues with this approach: 
> 
> *  I don't know what happens if you don't have a PPro/PII or MTRR support
> isn't compiled into the kernel and you call mtrr_add().  If a symbol is
> missing, the module won't insert.
> 
Hmm. So what's the problem? the preprocessor could handle that, nobody
runs on distributed binaries of the kernel modules I hope :)

> * Enabling write-combining over MMIO registers is a huge no-no because you
> can't control the order in which the registers are written.  That's not a
> problem for my S3 card because it maps the framebuffer and MMIO registers
> into different address spaces, but I don't know about other cards. 
> 
> * Fixed VGA address ranges have to be handled a little bit differently. 
> The "normal" MTRRs are a set of 16(?) variable type registers that can be
> used with any MTRR type, address, etc.  But the VGA address space (0xa0000
> - 0xbffff) is covered by a set of fixed MTRRs which can only be turned off
> or on.
> 
> * Some older/buggy hardware might not be able to handle MTRRs correctly.  
> In particular, I'm not at all sure how pseudo-linear framebuffers that 
> switch banks on page faults will react to this, since the _physical_ 
> memory is what needs to be MTRRed.
> 
I know some of the really old (well, 93ish ;) ) Matrox cards stick their
pseoudo-linear framebuffer window in the control aperture, so MTRRs
wouldn't do much good to these, but in general MTRRs sounds pretty nice, I
don't have a PII at the moment, but perhaps it's time to get a lowend PII
for these kinds of things :)

> 	Anyway, if can play with this please do and let me/us know what
> happens.  MTRRs give such a dramatic performance increase that we should 
> definitely use them if at all possible.
> 
> Jon
> 
> ---
> 'Cloning and the reprogramming of DNA is the first serious step in 
> becoming one with God.'
> 	- Scientist G. Richard Seed
>