From 9fa68eae9f8291a98bfe00b94b78f72eb253165a Mon Sep 17 00:00:00 2001 From: Knut Petersen Date: Fri, 9 Sep 2005 13:04:56 -0700 Subject: [PATCH] framebuffer: new driver for cyberblade/i1 graphics core This is a framebuffer driver for the Cyberblade/i1 graphics core. Currently tridenfb claims to support the cyberblade/i1 graphics core. This is of very limited truth. Even vesafb is faster and provides more working modes and a much better quality of the video signal. There is a great number of bugs in tridentfb ... but most often it is impossible to decide if these bugs are real bugs or if fixing them for the cyberblade/i1 core would break support for one of the other supported chips. Tridentfb seems to be unmaintained,and documentation for most of the supported chips is not available. So "fixing" cyberblade/i1 support inside of tridentfb was not an option, it would have caused numerous if(CYBERBLADEi1) else ... cases and would have rendered the code to be almost unmaintainable. A first version of this driver was published on 2005-07-31. A fix for a bug reported by Jochen Hein was integrated as well as some changes requested by Antonino A. Daplas. A message has been added to tridentfb to inform current users of tridentfb to switch to cyblafb if the cyberblade/i1 graphics core is detected. This patch is one logical change, but because of the included documentation it is bigger than 70kb. Therefore it is not sent to lkml and linux-fbdev-devel, Signed-off-by: Knut Petersen Cc: Muli Ben-Yehuda Acked-by: Antonino Daplas Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/fb/cyblafb/bugs | 14 +++ Documentation/fb/cyblafb/credits | 7 ++ Documentation/fb/cyblafb/documentation | 17 +++ Documentation/fb/cyblafb/fb.modes | 155 +++++++++++++++++++++++++ Documentation/fb/cyblafb/performance | 80 +++++++++++++ Documentation/fb/cyblafb/todo | 32 +++++ Documentation/fb/cyblafb/usage | 206 +++++++++++++++++++++++++++++++++ Documentation/fb/cyblafb/whycyblafb | 85 ++++++++++++++ 8 files changed, 596 insertions(+) create mode 100644 Documentation/fb/cyblafb/bugs create mode 100644 Documentation/fb/cyblafb/credits create mode 100644 Documentation/fb/cyblafb/documentation create mode 100644 Documentation/fb/cyblafb/fb.modes create mode 100644 Documentation/fb/cyblafb/performance create mode 100644 Documentation/fb/cyblafb/todo create mode 100644 Documentation/fb/cyblafb/usage create mode 100644 Documentation/fb/cyblafb/whycyblafb (limited to 'Documentation') diff --git a/Documentation/fb/cyblafb/bugs b/Documentation/fb/cyblafb/bugs new file mode 100644 index 000000000000..f90cc66ea919 --- /dev/null +++ b/Documentation/fb/cyblafb/bugs @@ -0,0 +1,14 @@ +Bugs +==== + +I currently don't know of any bug. Please do send reports to: + - linux-fbdev-devel@lists.sourceforge.net + - Knut_Petersen@t-online.de. + + +Untested features +================= + +All LCD stuff is untested. If it worked in tridentfb, it should work in +cyblafb. Please test and report the results to Knut_Petersen@t-online.de. + diff --git a/Documentation/fb/cyblafb/credits b/Documentation/fb/cyblafb/credits new file mode 100644 index 000000000000..0eb3b443dc2b --- /dev/null +++ b/Documentation/fb/cyblafb/credits @@ -0,0 +1,7 @@ +Thanks to +========= + * Alan Hourihane, for writing the X trident driver + * Jani Monoses, for writing the tridentfb driver + * Antonino A. Daplas, for review of the first published + version of cyblafb and some code + * Jochen Hein, for testing and a helpfull bug report diff --git a/Documentation/fb/cyblafb/documentation b/Documentation/fb/cyblafb/documentation new file mode 100644 index 000000000000..bb1aac048425 --- /dev/null +++ b/Documentation/fb/cyblafb/documentation @@ -0,0 +1,17 @@ +Available Documentation +======================= + +Apollo PLE 133 Chipset VT8601A North Bridge Datasheet, Rev. 1.82, October 22, +2001, available from VIA: + + http://www.viavpsd.com/product/6/15/DS8601A182.pdf + +The datasheet is incomplete, some registers that need to be programmed are not +explained at all and important bits are listed as "reserved". But you really +need the datasheet to understand the code. "p. xxx" comments refer to page +numbers of this document. + +XFree/XOrg drivers are available and of good quality, looking at the code +there is a good idea if the datasheet does not provide enough information +or if the datasheet seems to be wrong. + diff --git a/Documentation/fb/cyblafb/fb.modes b/Documentation/fb/cyblafb/fb.modes new file mode 100644 index 000000000000..cf4351fc32ff --- /dev/null +++ b/Documentation/fb/cyblafb/fb.modes @@ -0,0 +1,155 @@ +# +# Sample fb.modes file +# +# Provides an incomplete list of working modes for +# the cyberblade/i1 graphics core. +# +# The value 4294967256 is used instead of -40. Of course, -40 is not +# a really reasonable value, but chip design does not always follow +# logic. Believe me, it's ok, and it's the way the BIOS does it. +# +# fbset requires 4294967256 in fb.modes and -40 as an argument to +# the -t parameter. That's also not too reasonable, and it might change +# in the future or might even be differt for your current version. +# + +mode "640x480-50" + geometry 640 480 640 3756 8 + timings 47619 4294967256 24 17 0 216 3 +endmode + +mode "640x480-60" + geometry 640 480 640 3756 8 + timings 39682 4294967256 24 17 0 216 3 +endmode + +mode "640x480-70" + geometry 640 480 640 3756 8 + timings 34013 4294967256 24 17 0 216 3 +endmode + +mode "640x480-72" + geometry 640 480 640 3756 8 + timings 33068 4294967256 24 17 0 216 3 +endmode + +mode "640x480-75" + geometry 640 480 640 3756 8 + timings 31746 4294967256 24 17 0 216 3 +endmode + +mode "640x480-80" + geometry 640 480 640 3756 8 + timings 29761 4294967256 24 17 0 216 3 +endmode + +mode "640x480-85" + geometry 640 480 640 3756 8 + timings 28011 4294967256 24 17 0 216 3 +endmode + +mode "800x600-50" + geometry 800 600 800 3221 8 + timings 30303 96 24 14 0 136 11 +endmode + +mode "800x600-60" + geometry 800 600 800 3221 8 + timings 25252 96 24 14 0 136 11 +endmode + +mode "800x600-70" + geometry 800 600 800 3221 8 + timings 21645 96 24 14 0 136 11 +endmode + +mode "800x600-72" + geometry 800 600 800 3221 8 + timings 21043 96 24 14 0 136 11 +endmode + +mode "800x600-75" + geometry 800 600 800 3221 8 + timings 20202 96 24 14 0 136 11 +endmode + +mode "800x600-80" + geometry 800 600 800 3221 8 + timings 18939 96 24 14 0 136 11 +endmode + +mode "800x600-85" + geometry 800 600 800 3221 8 + timings 17825 96 24 14 0 136 11 +endmode + +mode "1024x768-50" + geometry 1024 768 1024 2815 8 + timings 19054 144 24 29 0 120 3 +endmode + +mode "1024x768-60" + geometry 1024 768 1024 2815 8 + timings 15880 144 24 29 0 120 3 +endmode + +mode "1024x768-70" + geometry 1024 768 1024 2815 8 + timings 13610 144 24 29 0 120 3 +endmode + +mode "1024x768-72" + geometry 1024 768 1024 2815 8 + timings 13232 144 24 29 0 120 3 +endmode + +mode "1024x768-75" + geometry 1024 768 1024 2815 8 + timings 12703 144 24 29 0 120 3 +endmode + +mode "1024x768-80" + geometry 1024 768 1024 2815 8 + timings 11910 144 24 29 0 120 3 +endmode + +mode "1024x768-85" + geometry 1024 768 1024 2815 8 + timings 11209 144 24 29 0 120 3 +endmode + +mode "1280x1024-50" + geometry 1280 1024 1280 2662 8 + timings 11114 232 16 39 0 160 3 +endmode + +mode "1280x1024-60" + geometry 1280 1024 1280 2662 8 + timings 9262 232 16 39 0 160 3 +endmode + +mode "1280x1024-70" + geometry 1280 1024 1280 2662 8 + timings 7939 232 16 39 0 160 3 +endmode + +mode "1280x1024-72" + geometry 1280 1024 1280 2662 8 + timings 7719 232 16 39 0 160 3 +endmode + +mode "1280x1024-75" + geometry 1280 1024 1280 2662 8 + timings 7410 232 16 39 0 160 3 +endmode + +mode "1280x1024-80" + geometry 1280 1024 1280 2662 8 + timings 6946 232 16 39 0 160 3 +endmode + +mode "1280x1024-85" + geometry 1280 1024 1280 2662 8 + timings 6538 232 16 39 0 160 3 +endmode + diff --git a/Documentation/fb/cyblafb/performance b/Documentation/fb/cyblafb/performance new file mode 100644 index 000000000000..eb4e47a9cea6 --- /dev/null +++ b/Documentation/fb/cyblafb/performance @@ -0,0 +1,80 @@ +Speed +===== + +CyBlaFB is much faster than tridentfb and vesafb. Compare the performance data +for mode 1280x1024-[8,16,32]@61 Hz. + +Test 1: Cat a file with 2000 lines of 0 characters. +Test 2: Cat a file with 2000 lines of 80 characters. +Test 3: Cat a file with 2000 lines of 160 characters. + +All values show system time use in seconds, kernel 2.6.12 was used for +the measurements. 2.6.13 is a bit slower, 2.6.14 hopefully will include a +patch that speeds up kernel bitblitting a lot ( > 20%). + ++-----------+-----------------------------------------------------+ +| | not accelerated | +| TRIDENTFB +-----------------+-----------------+-----------------+ +| of 2.6.12 | 8 bpp | 16 bpp | 32 bpp | +| | noypan | ypan | noypan | ypan | noypan | ypan | ++-----------+--------+--------+--------+--------+--------+--------+ +| Test 1 | 4.31 | 4.33 | 6.05 | 12.81 | ---- | ---- | +| Test 2 | 67.94 | 5.44 | 123.16 | 14.79 | ---- | ---- | +| Test 3 | 131.36 | 6.55 | 240.12 | 16.76 | ---- | ---- | ++-----------+--------+--------+--------+--------+--------+--------+ +| Comments | | | completely bro- | +| | | | ken, monitor | +| | | | switches off | ++-----------+-----------------+-----------------+-----------------+ + + ++-----------+-----------------------------------------------------+ +| | accelerated | +| TRIDENTFB +-----------------+-----------------+-----------------+ +| of 2.6.12 | 8 bpp | 16 bpp | 32 bpp | +| | noypan | ypan | noypan | ypan | noypan | ypan | ++-----------+--------+--------+--------+--------+--------+--------+ +| Test 1 | ---- | ---- | 20.62 | 1.22 | ---- | ---- | +| Test 2 | ---- | ---- | 22.61 | 3.19 | ---- | ---- | +| Test 3 | ---- | ---- | 24.59 | 5.16 | ---- | ---- | ++-----------+--------+--------+--------+--------+--------+--------+ +| Comments | broken, writing | broken, ok only | completely bro- | +| | to wrong places | if bgcolor is | ken, monitor | +| | on screen + bug | black, bug in | switches off | +| | in fillrect() | fillrect() | | ++-----------+-----------------+-----------------+-----------------+ + + ++-----------+-----------------------------------------------------+ +| | not accelerated | +| VESAFB +-----------------+-----------------+-----------------+ +| of 2.6.12 | 8 bpp | 16 bpp | 32 bpp | +| | noypan | ypan | noypan | ypan | noypan | ypan | ++-----------+--------+--------+--------+--------+--------+--------+ +| Test 1 | 4.26 | 3.76 | 5.99 | 7.23 | ---- | ---- | +| Test 2 | 65.65 | 4.89 | 120.88 | 9.08 | ---- | ---- | +| Test 3 | 126.91 | 5.94 | 235.77 | 11.03 | ---- | ---- | ++-----------+--------+--------+--------+--------+--------+--------+ +| Comments | vga=0x307 | vga=0x31a | vga=0x31b not | +| | fh=80kHz | fh=80kHz | supported by | +| | fv=75kHz | fv=75kHz | video BIOS and | +| | | | hardware | ++-----------+-----------------+-----------------+-----------------+ + + ++-----------+-----------------------------------------------------+ +| | accelerated | +| CYBLAFB +-----------------+-----------------+-----------------+ +| | 8 bpp | 16 bpp | 32 bpp | +| | noypan | ypan | noypan | ypan | noypan | ypan | ++-----------+--------+--------+--------+--------+--------+--------+ +| Test 1 | 8.02 | 0.23 | 19.04 | 0.61 | 57.12 | 2.74 | +| Test 2 | 8.38 | 0.55 | 19.39 | 0.92 | 57.54 | 3.13 | +| Test 3 | 8.73 | 0.86 | 19.74 | 1.24 | 57.95 | 3.51 | ++-----------+--------+--------+--------+--------+--------+--------+ +| Comments | | | | +| | | | | +| | | | | +| | | | | ++-----------+-----------------+-----------------+-----------------+ + diff --git a/Documentation/fb/cyblafb/todo b/Documentation/fb/cyblafb/todo new file mode 100644 index 000000000000..80fb2f89b6c1 --- /dev/null +++ b/Documentation/fb/cyblafb/todo @@ -0,0 +1,32 @@ +TODO / Missing features +======================= + +Verify LCD stuff "stretch" and "center" options are + completely untested ... this code needs to be + verified. As I don't have access to such + hardware, please contact me if you are + willing run some tests. + +Interlaced video modes The reason that interleaved + modes are disabled is that I do not know + the meaning of the vertical interlace + parameter. Also the datasheet mentions a + bit d8 of a horizontal interlace parameter, + but nowhere the lower 8 bits. Please help + if you can. + +low-res double scan modes Who needs it? + +accelerated color blitting Who needs it? The console driver does use color + blitting for nothing but drawing the penguine, + everything else is done using color expanding + blitting of 1bpp character bitmaps. + +xpanning Who needs it? + +ioctls Who needs it? + +TV-out Will be done later + +??? Feel free to contact me if you have any + feature requests diff --git a/Documentation/fb/cyblafb/usage b/Documentation/fb/cyblafb/usage new file mode 100644 index 000000000000..e627c8f54211 --- /dev/null +++ b/Documentation/fb/cyblafb/usage @@ -0,0 +1,206 @@ +CyBlaFB is a framebuffer driver for the Cyberblade/i1 graphics core integrated +into the VIA Apollo PLE133 (aka vt8601) south bridge. It is developed and +tested using a VIA EPIA 5000 board. + +Cyblafb - compiled into the kernel or as a module? +================================================== + +You might compile cyblafb either as a module or compile it permanently into the +kernel. + +Unless you have a real reason to do so you should not compile both vesafb and +cyblafb permanently into the kernel. It's possible and it helps during the +developement cycle, but it's useless and will at least block some otherwise +usefull memory for ordinary users. + +Selecting Modes +=============== + + Startup Mode + ============ + + First of all, you might use the "vga=???" boot parameter as it is + documented in vesafb.txt and svga.txt. Cyblafb will detect the video + mode selected and will use the geometry and timings found by + inspecting the hardware registers. + + video=cyblafb vga=0x317 + + Alternatively you might use a combination of the mode, ref and bpp + parameters. If you compiled the driver into the kernel, add something + like this to the kernel command line: + + video=cyblafb:1280x1024,bpp=16,ref=50 ... + + If you compiled the driver as a module, the same mode would be + selected by the following command: + + modprobe cyblafb mode=1280x1024 bpp=16 ref=50 ... + + None of the modes possible to select as startup modes are affected by + the problems described at the end of the next subsection. + + Mode changes using fbset + ======================== + + You might use fbset to change the video mode, see "man fbset". Cyblafb + generally does assume that you know what you are doing. But it does + some checks, especially those that are needed to prevent you from + damaging your hardware. + + - only 8, 16, 24 and 32 bpp video modes are accepted + - interlaced video modes are not accepted + - double scan video modes are not accepted + - if a flat panel is found, cyblafb does not allow you + to program a resolution higher than the physical + resolution of the flat panel monitor + - cyblafb does not allow xres to differ from xres_virtual + - cyblafb does not allow vclk to exceed 230 MHz. As 32 bpp + and (currently) 24 bit modes use a doubled vclk internally, + the dotclock limit as seen by fbset is 115 MHz for those + modes and 230 MHz for 8 and 16 bpp modes. + + Any request that violates the rules given above will be ignored and + fbset will return an error. + + If you program a virtual y resolution higher than the hardware limit, + cyblafb will silently decrease that value to the highest possible + value. + + Attempts to disable acceleration are ignored. + + Some video modes that should work do not work as expected. If you use + the standard fb.modes, fbset 640x480-60 will program that mode, but + you will see a vertical area, about two characters wide, with only + much darker characters than the other characters on the screen. + Cyblafb does allow that mode to be set, as it does not violate the + official specifications. It would need a lot of code to reliably sort + out all invalid modes, playing around with the margin values will + give a valid mode quickly. And if cyblafb would detect such an invalid + mode, should it silently alter the requested values or should it + report an error? Both options have some pros and cons. As stated + above, none of the startup modes are affected, and if you set + verbosity to 1 or higher, cyblafb will print the fbset command that + would be needed to program that mode using fbset. + + +Other Parameters +================ + + +crt don't autodetect, assume monitor connected to + standard VGA connector + +fp don't autodetect, assume flat panel display + connected to flat panel monitor interface + +nativex inform driver about native x resolution of + flat panel monitor connected to special + interface (should be autodetected) + +stretch stretch image to adapt low resolution modes to + higer resolutions of flat panel monitors + connected to special interface + +center center image to adapt low resolution modes to + higer resolutions of flat panel monitors + connected to special interface + +memsize use if autodetected memsize is wrong ... + should never be necessary + +nopcirr disable PCI read retry +nopciwr disable PCI write retry +nopcirb disable PCI read bursts +nopciwb disable PCI write bursts + +bpp bpp for specified modes + valid values: 8 || 16 || 24 || 32 + +ref refresh rate for specified mode + valid values: 50 <= ref <= 85 + +mode 640x480 or 800x600 or 1024x768 or 1280x1024 + if not specified, the startup mode will be detected + and used, so you might also use the vga=??? parameter + described in vesafb.txt. If you do not specify a mode, + bpp and ref parameters are ignored. + +verbosity 0 is the default, increase to at least 2 for every + bug report! + +vesafb allows cyblafb to be loaded after vesafb has been + loaded. See sections "Module unloading ...". + + +Development hints +================= + +It's much faster do compile a module and to load the new version after +unloading the old module than to compile a new kernel and to reboot. So if you +try to work on cyblafb, it might be a good idea to use cyblafb as a module. +In real life, fast often means dangerous, and that's also the case here. If +you introduce a serious bug when cyblafb is compiled into the kernel, the +kernel will lock or oops with a high probability before the file system is +mounted, and the danger for your data is low. If you load a broken own version +of cyblafb on a running system, the danger for the integrity of the file +system is much higher as you might need a hard reset afterwards. Decide +yourself. + +Module unloading, the vfb method +================================ + +If you want to unload/reload cyblafb using the virtual framebuffer, you need +to enable vfb support in the kernel first. After that, load the modules as +shown below: + + modprobe vfb vfb_enable=1 + modprobe fbcon + modprobe cyblafb + fbset -fb /dev/fb1 1280x1024-60 -vyres 2662 + con2fb /dev/fb1 /dev/tty1 + ... + +If you now made some changes to cyblafb and want to reload it, you might do it +as show below: + + con2fb /dev/fb0 /dev/tty1 + ... + rmmod cyblafb + modprobe cyblafb + con2fb /dev/fb1 /dev/tty1 + ... + +Of course, you might choose another mode, and most certainly you also want to +map some other /dev/tty* to the real framebuffer device. You might also choose +to compile fbcon as a kernel module or place it permanently in the kernel. + +I do not know of any way to unload fbcon, and fbcon will prevent the +framebuffer device loaded first from unloading. [If there is a way, then +please add a description here!] + +Module unloading, the vesafb method +=================================== + +Configure the kernel: + + <*> Support for frame buffer devices + [*] VESA VGA graphics support + Cyberblade/i1 support + +Add e.g. "video=vesafb:ypan vga=0x307" to the kernel parameters. The ypan +parameter is important, choose any vga parameter you like as long as it is +a graphics mode. + +After booting, load cyblafb without any mode and bpp parameter and assign +cyblafb to individual ttys using con2fb, e.g.: + + modprobe cyblafb vesafb=1 + con2fb /dev/fb1 /dev/tty1 + +Unloading cyblafb works without problems after you assign vesafb to all +ttys again, e.g.: + + con2fb /dev/fb0 /dev/tty1 + rmmod cyblafb + diff --git a/Documentation/fb/cyblafb/whycyblafb b/Documentation/fb/cyblafb/whycyblafb new file mode 100644 index 000000000000..a123bc11e698 --- /dev/null +++ b/Documentation/fb/cyblafb/whycyblafb @@ -0,0 +1,85 @@ +I tried the following framebuffer drivers: + + - TRIDENTFB is full of bugs. Acceleration is broken for Blade3D + graphics cores like the cyberblade/i1. It claims to support a great + number of devices, but documentation for most of these devices is + unfortunately not available. There is _no_ reason to use tridentfb + for cyberblade/i1 + CRT users. VESAFB is faster, and the one + advantage, mode switching, is broken in tridentfb. + + - VESAFB is used by many distributions as a standard. Vesafb does + not support mode switching. VESAFB is a bit faster than the working + configurations of TRIDENTFB, but it is still too slow, even if you + use ypan. + + - EPIAFB (you'll find it on sourceforge) supports the Cyberblade/i1 + graphics core, but it still has serious bugs and developement seems + to have stopped. This is the one driver with TV-out support. If you + do need this feature, try epiafb. + +None of these drivers was a real option for me. + +I believe that is unreasonable to change code that announces to support 20 +devices if I only have more or less sufficient documentation for exactly one +of these. The risk of breaking device foo while fixing device bar is too high. + +So I decided to start CyBlaFB as a stripped down tridentfb. + +All code specific to other Trident chips has been removed. After that there +were a lot of cosmetic changes to increase the readability of the code. All +register names were changed to those mnemonics used in the datasheet. Function +and macro names were changed if they hindered easy understanding of the code. + +After that I debugged the code and implemented some new features. I'll try to +give a little summary of the main changes: + + - calculation of vertical and horizontal timings was fixed + + - video signal quality has been improved dramatically + + - acceleration: + + - fillrect and copyarea were fixed and reenabled + + - color expanding imageblit was newly implemented, color + imageblit (only used to draw the penguine) still uses the + generic code. + + - init of the acceleration engine was improved and moved to a + place where it really works ... + + - sync function has a timeout now and tries to reset and + reinit the accel engine if necessary + + - fewer slow copyarea calls when doing ypan scrolling by using + undocumented bit d21 of screen start address stored in + CR2B[5]. BIOS does use it also, so this should be safe. + + - cyblafb rejects any attempt to set modes that would cause vclk + values above reasonable 230 MHz. 32bit modes use a clock + multiplicator of 2, so fbset does show the correct values for + pixclock but not for vclk in this case. The fbset limit is 115 MHz + for 32 bpp modes. + + - cyblafb rejects modes known to be broken or unimplemented (all + interlaced modes, all doublescan modes for now) + + - cyblafb now works independant of the video mode in effect at startup + time (tridentfb does not init all needed registers to reasonable + values) + + - switching between video modes does work reliably now + + - the first video mode now is the one selected on startup using the + vga=???? mechanism or any of + - 640x480, 800x600, 1024x768, 1280x1024 + - 8, 16, 24 or 32 bpp + - refresh between 50 Hz and 85 Hz, 1 Hz steps (1280x1024-32 + is limited to 63Hz) + + - pci retry and pci burst mode are settable (try to disable if you + experience latency problems) + + - built as a module cyblafb might be unloaded and reloaded using + the vfb module and con2vt or might be used together with vesafb + -- cgit v1.2.2