Messages in this thread | | | Date | Thu, 24 Dec 1998 01:36:04 -0500 (EST) | From | John Michael Clemens <> | Subject | Re: 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 out.
> 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 ordered..
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.c - -- /* John Clemens http://www.rpi.edu/~clemej _/ */ /* Suite 1033 clemej@rpi.edu _/ Speak Softly, */
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |