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

1 files changed, 85 insertions, 0 deletions

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
+