> 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/