[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 <Knut_Petersen@t-online.de>
Cc: Muli Ben-Yehuda <mulix@mulix.org>
Acked-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

14 files changed, 2266 insertions, 2 deletions

diff --git a/Documentation/fb/cyblafb/bugs b/Documentation/fb/cyblafb/bugs
new file mode 100644
index 00000000000..f90cc66ea91
--- /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 00000000000..0eb3b443dc2
--- /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 00000000000..bb1aac04842
--- /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 00000000000..cf4351fc32f
--- /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 00000000000..eb4e47a9cea
--- /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 00000000000..80fb2f89b6c
--- /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 00000000000..e627c8f5421
--- /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
+	<M>   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 00000000000..a123bc11e69
--- /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
+
diff --git a/MAINTAINERS b/MAINTAINERS
index 8429bdb1d2a..9c9a86d0685 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -626,6 +626,12 @@ M:	rmk@arm.linux.org.uk
 W:	http://www.arm.linux.org.uk/
 S:	Maintained
 
+CYBLAFB FRAMEBUFFER DRIVER
+P:	Knut Petersen
+M:	Knut_Petersen@t-online.de
+L:	linux-fbdev-devel@lists.sourceforge.net
+S:	Maintained
+
 CYCLADES 2X SYNC CARD DRIVER
 P:	Arnaldo Carvalho de Melo
 M:	acme@conectiva.com.br
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index e906b542179..e27aefd49ea 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -1177,6 +1177,32 @@ config FB_VOODOO1
 	  Please read the <file:Documentation/fb/README-sstfb.txt> for supported
 	  options and other important info  support.
 
+config FB_CYBLA
+	tristate "Cyberblade/i1 support"
+	depends on FB && PCI
+	select FB_CFB_IMAGEBLIT
+	select FB_SOFT_CURSOR
+	select VIDEO_SELECT
+	---help---
+	  This driver is supposed to support the Trident Cyberblade/i1
+	  graphics core integrated in the VIA VT8601A North Bridge,
+	  also known as VIA Apollo PLE133.
+
+	  Status:
+	   - Developed, tested and working on EPIA 5000 and EPIA 800.
+	   - Does work reliable on all systems with CRT/LCD connected to
+	     normal VGA ports.
+	   - Should work on systems that do use the internal LCD port, but
+	     this is absolutely not tested.
+
+	  Character imageblit, copyarea and rectangle fill are hw accelerated,
+	  ypan scrolling is used by default.
+
+	  Please do read <file:Documentation/fb/cyblafb/*>.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called cyblafb.
+
 config FB_TRIDENT
 	tristate "Trident support"
 	depends on FB && PCI
@@ -1190,8 +1216,12 @@ config FB_TRIDENT
 	  but also on some motherboards. For more information, read
 	  <file:Documentation/fb/tridentfb.txt>
 
+	  Cyberblade/i1 support will be removed soon, use the cyblafb driver
+	  instead.
+
 	  Say Y if you have such a graphics board.
 
+
 	  To compile this driver as a module, choose M here: the
 	  module will be called tridentfb.
 
@@ -1202,7 +1232,6 @@ config FB_TRIDENT_ACCEL
 	This will compile the Trident frame buffer device with
 	acceleration functions.
 
-
 config FB_PM3
 	tristate "Permedia3 support"
 	depends on FB && PCI && BROKEN
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index b018df4e95c..8478d217aaf 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -50,7 +50,8 @@ obj-$(CONFIG_FB_CT65550)          += chipsfb.o
 obj-$(CONFIG_FB_IMSTT)            += imsttfb.o
 obj-$(CONFIG_FB_S3TRIO)           += S3triofb.o
 obj-$(CONFIG_FB_FM2)              += fm2fb.o
-obj-$(CONFIG_FB_TRIDENT)	  += tridentfb.o
+obj-$(CONFIG_FB_CYBLA)            += cyblafb.o
+obj-$(CONFIG_FB_TRIDENT)          += tridentfb.o
 obj-$(CONFIG_FB_STI)              += stifb.o
 obj-$(CONFIG_FB_FFB)              += ffb.o sbuslib.o
 obj-$(CONFIG_FB_CG6)              += cg6.o sbuslib.o
diff --git a/drivers/video/cyblafb.c b/drivers/video/cyblafb.c
new file mode 100644
index 00000000000..ae2762cb560
--- /dev/null
+++ b/drivers/video/cyblafb.c
@@ -0,0 +1,1456 @@
+/*
+ * Frame buffer driver for Trident Cyberblade/i1 graphics core
+ *
+ * Copyright 2005 Knut Petersen <Knut_Petersen@t-online.de>
+ *
+ * CREDITS:
+ *	tridentfb.c by Jani Monoses
+ *	see files above for further credits
+ *
+ * TODO:
+ *
+ */
+
+#define CYBLAFB_DEBUG 0
+
+#include <linux/config.h>
+#include <linux/module.h>
+#include <linux/string.h>
+#include <linux/fb.h>
+#include <linux/init.h>
+#include <linux/pci.h>
+#include <asm/types.h>
+#include <video/cyblafb.h>
+
+#define VERSION "0.54"
+
+struct cyblafb_par {
+	u32 pseudo_pal[16];
+	struct fb_ops ops;
+};
+
+static struct fb_fix_screeninfo cyblafb_fix __devinitdata = {
+	.id = "CyBla",
+	.type = FB_TYPE_PACKED_PIXELS,
+	.ypanstep = 1,
+	.visual = FB_VISUAL_PSEUDOCOLOR,
+	.accel = FB_ACCEL_NONE,
+};
+
+static char *mode __devinitdata = NULL;
+static int bpp __devinitdata = 8;
+static int ref __devinitdata = 75;
+static int fp __devinitdata;
+static int crt __devinitdata;
+static int memsize __devinitdata;
+static int vesafb __devinitdata;
+
+static int nativex;
+static int center;
+static int stretch;
+static int pciwb = 1;
+static int pcirb = 1;
+static int pciwr = 1;
+static int pcirr = 1;
+static int verbosity;
+static int displaytype;
+
+static void __iomem * io_virt; // iospace virtual memory address
+
+module_param(mode,charp,0);
+module_param(bpp,int,0);
+module_param(ref,int,0);
+module_param(fp,int,0);
+module_param(crt,int,0);
+module_param(nativex,int,0);
+module_param(center,int,0);
+module_param(stretch,int,0);
+module_param(pciwb,int,0);
+module_param(pcirb,int,0);
+module_param(pciwr,int,0);
+module_param(pcirr,int,0);
+module_param(memsize,int,0);
+module_param(verbosity,int,0);
+module_param(vesafb,int,0);
+
+//=========================================
+//
+// Port access macros for memory mapped io
+//
+//=========================================
+
+#define out8(r,v) writeb(v,io_virt+r)
+#define out32(r,v) writel(v,io_virt+r)
+#define in8(r) readb(io_virt+r)
+#define in32(r) readl(io_virt+r)
+
+//======================================
+//
+// Hardware access inline functions
+//
+//======================================
+
+static inline unsigned char read3X4(int reg)
+{
+	out8(0x3D4,reg);
+	return in8(0x3D5);
+}
+
+static inline unsigned char read3C4(int reg)
+{
+	out8(0x3C4,reg);
+	return in8(0x3C5);
+}
+
+static inline unsigned char read3CE(int reg)
+{
+	out8(0x3CE,reg);
+	return in8(0x3CF);
+}
+
+static inline void write3X4(int reg,unsigned char val)
+{
+	out8(0x3D4,reg);
+	out8(0x3D5,val);
+}
+
+static inline void write3C4(int reg,unsigned char val)
+{
+	out8(0x3C4,reg);
+	out8(0x3C5,val);
+}
+
+static inline void write3CE(int reg,unsigned char val)
+{
+	out8(0x3CE,reg);
+	out8(0x3CF,val);
+}
+
+static inline void write3C0(int reg,unsigned char val)
+{
+	in8(0x3DA);	// read to reset index
+	out8(0x3C0,reg);
+	out8(0x3C0,val);
+}
+
+//=================================================
+//
+// Enable memory mapped io and unprotect registers
+//
+//=================================================
+
+static inline void enable_mmio(void)
+{
+	int tmp;
+
+	outb(0x0B,0x3C4);
+	inb(0x3C5);		// Set NEW mode
+	outb(SR0E,0x3C4);	// write enable a lot of extended ports
+	outb(0x80,0x3C5);
+
+	outb(SR11,0x3C4);	// write enable those extended ports that
+	outb(0x87,0x3C5);	// are not affected by SR0E_New
+
+	outb(CR1E,0x3d4);	// clear write protect bit for port 0x3c2
+	tmp=inb(0x3d5) & 0xBF;
+	outb(CR1E,0x3d4);
+	outb(tmp,0x3d5);
+
+	outb(CR39,0x3D4);
+	outb(inb(0x3D5)|0x01,0x3D5); // Enable mmio, everything else untouched
+}
+
+//=================================================
+//
+// Set pixel clock VCLK1
+//   - multipliers set elswhere
+//   - freq in units of 0.01 MHz
+//
+//=================================================
+
+static void set_vclk(struct cyblafb_par *par, int freq)
+{
+	u32 m,n,k;
+	int f,fi,d,di;
+	u8 lo=0,hi=0;
+
+	d = 2000;
+	k = freq >= 10000 ? 0 : freq >= 5000 ? 1 : freq >= 2500 ? 2 : 3;
+	for(m = 0;m<64;m++)
+	for(n = 0;n<250;n++) { // max 249 is a hardware limit for cybla/i1 !
+		fi = (int)(((5864727*(n+8))/((m+2)*(1<<k)))>>12);
+		if ((di = abs(fi - freq)) < d) {
+			d = di;
+			f = fi;
+			lo = (u8) n;
+			hi = (u8) ((k<<6) | m);
+		}
+	}
+	write3C4(SR19,hi);
+	write3C4(SR18,lo);
+	if(verbosity > 1)
+		output("pixclock = %d.%02d MHz, k/m/n %x %x %x\n",
+		freq/100,freq%100,(hi&0xc0)>>6,hi&0x3f,lo);
+}
+
+//================================================
+//
+// Cyberblade specific Graphics Engine (GE) setup
+//
+//================================================
+
+static void cyblafb_setup_GE(int pitch,int bpp)
+{
+	int base = (pitch>>3)<<20;
+
+	switch (bpp) {
+		case  8: base |= (0<<29); break;
+		case 15: base |= (5<<29); break;
+		case 16: base |= (1<<29); break;
+		case 24:
+		case 32: base |= (2<<29); break;
+	}
+
+	write3X4(CR36,0x90);	// reset GE
+	write3X4(CR36,0x80);	// enable GE
+
+	out32(GE24,1<<7);	// reset all GE pointers
+	ou