Experimental OAK Spitfire 64111 xorg driver - fails to use MTRR on 64-bit compile

[Alex Villací­s Lasso]

A few months ago I reported that I wrote a driver for the Oak Technologies OTI-64111 "Spitfire" graphics card. Currently this driver (written using xf86-video-savage as a reference) supports user-mode setting, setting 8-bit, 16-bit, 24-bit and 32-bit modes, with or without the help of BIOS, resolutions up to 1024x768 (limited by pixel depth and available video memory), and XAA acceleration (bitblit, mono pattern fill, solids). I am starting to implement some EXA acceleration (for now, solids and bitblts should be possible, no composite or upload/download support), and if at all possible, some xvideo support (YUV only, no native YV12 support). For my development I am using a card with 2 Mb of total video memory.

open("/usr/lib64/xorg/modules/drivers/spitfire_drv.so", O_RDONLY) = 10

fstat(10, {st_mode=S_IFREG|0775, st_size=283277, ...}) = 0

mprotect(0x7fe75f448000, 2097152, PROT_NONE) = 0

close(10)                               = 0
write(0, "(II) Module spitfire: vendor=\"X."..., 48) = 48
write(0, "\tcompiled for 1.7.4", 19)    = 19
write(0, ", module version = 0.0.1\n", 25) = 25
write(0, "\tModule class: X.Org Video Drive"..., 34) = 34
write(0, "\tABI class: X.Org Video Driver, "..., 44) = 44
write(0, "(II) SPITFIRE: driver (version 0"..., 64) = 64
write(0, "\n\t", 2)                     = 2
write(0, "Oak Spitfire 64111", 18)      = 18
write(0, "\n", 1)                       = 1
ioperm(0, 0x400, 0x1)                   = 0
iopl(0x3)                               = 0
ioperm(0x40, 0x4, 0)                    = 0
ioperm(0x60, 0x4, 0)                    = 0
write(0, "(II) Primary Device is: PCI 0...@0"..., 39) = 39
open("/dev/vga_arbiter", O_RDWR)        = 10
read(10, "count:1,PCI:0000:00:02.0,decodes"..., 64) = 64
write(10, "target PCI:0000:03:01.0", 23) = 23
read(10, "count:1,PCI:0000:03:01.0,decodes"..., 64) = 64
...
write(0, "(II) Module xaa: vendor=\"X.Org F"..., 43) = 43
write(0, "\tcompiled for 1.7.4", 19)    = 19
write(0, ", module version = 1.2.1\n", 25) = 25
write(0, "\tABI class: X.Org Video Driver, "..., 44) = 44
munmap(0x7fe75ed21000, 987136)          = 0
munmap(0x7fe760509000, 131072)          = 0
write(0, "(--) Depth 24 pixmap format is 3"..., 38) = 38
write(10, "target PCI:0000:03:01.0", 23) = 23
read(10, "count:1,PCI:0000:03:01.0,decodes"..., 64) = 64
write(0, "(II) Loading sub module \"int10\"\n", 32) = 32
write(0, "(II) LoadModule: \"int10\"", 24) = 24
write(0, "\n", 1)                       = 1
...
write(0, "(II) SPITFIRE(0): VESA BIOS dete"..., 37) = 37
write(0, "(II) SPITFIRE(0): VESA VBE Versi"..., 39) = 39
write(0, "(II) SPITFIRE(0): VESA VBE Total"..., 46) = 46
write(0, "(II) SPITFIRE(0): VESA VBE OEM: "..., 46) = 46

open("/sys/bus/pci/devices/0000:03:01.0/resource1", O_RDWR) = 13

write(2, "error setting MTRR (base = 0xfc8"..., 104) = 104

Recently I took out my test card from the very old machine (Pentium Classic-era) I was using for my tests, and plugged it to my newer home machine. This newer machine runs Fedora 12 64-bits with self-compiled 2.6.33-rc5 kernel, and has an integrated Intel video chipset with working KMS and compiz effects. With this I have verified that starting a second X server for this card works correctly, and can drive the card as a secondary display. However, I have noticed that the setup to mark the framebuffer area for the card as write-combining, which used to work on a 32-bit Fedora on a Pentium 4, now fails in my newer machine. The strace output is the following: read(10, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240%\0\0\0\0\0\0"..., 832) = 832 mmap(NULL, 2131968, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0x7fe75f440000 mmap(0x7fe75f648000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0x8000) = 0x7fe75f648000 open("/sys/bus/pci/devices/0000:03:01.0/resource1_wc", O_RDWR) = -1 ENOENT (No such file or directory) mmap(NULL, 2097152, PROT_READ|PROT_WRITE, MAP_SHARED, 13, 0) = 0x7fe75e660000 ioctl(10, MTRRIOC_ADD_ENTRY, 0x7fff3d21c5e0) = -1 ENOTTY (Inappropriate ioctl for device) I see that an ioctl is being attempted on a file descriptor opened for /dev/vga_arbitrer, and this failing ioctl is the cause of the error I am seeing. I can, of course, set the MTRR manually via /proc/mtrr, but I wonder why this operation is failing here. The card still works, apparently normally. I am using the distro-supplied RPM package xorg-x11-server-Xorg-1.7.4-1.fc12.x86_64 . All of these tests were made with the intel KMS in effect. I have another question: is it worthwhile at all to attempt to implement KMS for this card? This is a card that has no 3D support whatsoever, and that (as far as I know) absolutely requires access to legacy VGA registers to set up modes, that is, there is no separate register range (as reported by PCI) to set up the display parameters.

salida-x-spitfire.txt.bz2
Description: BZip2 compressed data

_______________________________________________
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg