[lkml]   [1998]   [Dec]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: MTRR testbeds??
On Thu, 24 Dec 1998, Richard Gooch wrote:

> I'm sitting on some patches written by Rafael which hacked the MTRR
> code to work for IBM/Cryix. By the time 2.3 is released I should have
> some time to integrate these patches (Rafael thought the Intel support
> may have been broken by his hacks:-). I'm planning a framework for
> supporting different CPUs in a nice, easy way.

Sounds fine, once i get some working code i'll send it to you for
inclusion/testing/whatever...if anyone has one of these CPU's and wants to
test some stuff out, let me know by private email and we'll work something

> The most useful benchmark is one that blits images to the screen. So
> one with pixmap or SHM XImage blitting should show the difference
> quite nicely.

alright, i'll see what i can find..

> > also, what is the best setting for the X linear framebuffer?
> > writecombining for stacks? strings? both? neither?
> Stacks? I can't imagine putting a stack in the framebuffer
> memory. Just strings would be good enough, although I see no harm in
> both. Frankly, I don't know what the distinction really is. I can
> guess what stacks are (well, I *know* what they are, but IDT may mean
> something odd, though I doubt it). I suppose by "strings" they really
> mean "all other accesses other than stacks". You tell me.

I wish i could, but it's quite ambiguous.. from the C6 Processor Data Book
(paraphrased from chart, p A-13):
Attribute bit 0 : Enables store combining on non-stack non-string writes
Attribute bit 1 : enables store combining on string instruction writes
" bit 2 : enables store combining on stack instruction writes
bits 3+4: write order strategy for memory region: Strog/weak

but i have not found anywhere where they define "string" or
"stack"...howver, i'm new to reading these things so i thought maybe
someone here could shed some light on it...(for tests, i just turned 0,1,
and 2 on)

i'm also working under the (what i consider to be logical) assumption that
"store-combining" is "write-combining" from ythe PPro MTRR code.

> Just the linear framebuffer. Don't even think of making the MMIO
> region write-combining. That's the cards register set mapped into
> memory. Many register sets care about the order of writes. Write
> combining rearranges the order of writing. Besides, fiddling the MMIO
> registers is not time-critical anyway.

appearently, you can tune the winchip's MCR's to not change the order of
writes...i'm actually rather impressed, there are like 8-10 different bits
you can set to tune the behavior of a given range, even if that does make
it a lot more confusing to program ;)

> BTW: what's reported as being at 0xe08000000 ? Is that by any chance
> the linear frambuffer mapped for big endian CPUs?

couldn't tell ya without going to Matrox, although this is a Mystique,
which appearently has hardware 3d support (a pleasent surprise when i
picked it up for 20$), maybe this range has something to do with that?
Xfree doesn't even report it..

00:0d.0 VGA compatible controller: Matrox Graphics, Inc. MGA 1064SG
[Mystique] (rev 03)
Subsystem: Unknown device 102b:051a
Flags: stepping, medium devsel, IRQ 11
Memory at e0000000 (32-bit, prefetchable)
Memory at e1000000 (32-bit, non-prefetchable)
Memory at e0800000 (32-bit, non-prefetchable)

and the relevant X bootup messages:

(--) SVGA: PCI: Matrox MGA 1064SG rev 3, Memory @ 0xe0000000, 0xe1000000
(--) SVGA: Linear framebuffer at 0xE0000000
(--) SVGA: MMIO registers at 0xE1000000
(--) SVGA: Video BIOS info block at 0x000c77e0
(--) SVGA: Found and verified enhanced Video BIOS info block
Using BIOS value for maxPixelClock: 220000 kHz
(--) SVGA: chipset: mga1064sg
(--) SVGA: videoram: 2048k
(**) SVGA: Option "dac_8_bit"

> Regards,
> Richard....

- --
/* John Clemens _/ */
/* Suite 1033 _/ Speak Softly, */

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

 \ /
  Last update: 2005-03-22 13:46    [W:0.032 / U:5.160 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site