4 files changed, 227 insertions, 7 deletions

diff --git a/Documentation/fb/00-INDEX b/Documentation/fb/00-INDEX
index a618fd99c9f0..30a70542e823 100644
--- a/Documentation/fb/00-INDEX
+++ b/Documentation/fb/00-INDEX
@@ -4,33 +4,41 @@ please mail me.
                                     Geert Uytterhoeven <geert@linux-m68k.org>
 
 00-INDEX
-        - this file
+        - this file.
 arkfb.txt
         - info on the fbdev driver for ARK Logic chips.
 aty128fb.txt
         - info on the ATI Rage128 frame buffer driver.
 cirrusfb.txt
         - info on the driver for Cirrus Logic chipsets.
+cmap_xfbdev.txt
+        - an introduction to fbdev's cmap structures.
 deferred_io.txt
         - an introduction to deferred IO.
+efifb.txt
+        - info on the EFI platform driver for Intel based Apple computers.
+ep93xx-fb.txt
+        - info on the driver for EP93xx LCD controller.
 fbcon.txt
         - intro to and usage guide for the framebuffer console (fbcon).
 framebuffer.txt
         - introduction to frame buffer devices.
-imacfb.txt
-        - info on the generic EFI platform driver for Intel based Macs.
+gxfb.txt
+        - info on the framebuffer driver for AMD Geode GX2 based processors.
 intel810.txt
         - documentation for the Intel 810/815 framebuffer driver.
 intelfb.txt
         - docs for Intel 830M/845G/852GM/855GM/865G/915G/945G fb driver.
 internals.txt
         - quick overview of frame buffer device internals.
+lxfb.txt
+        - info on the framebuffer driver for AMD Geode LX based processors.
 matroxfb.txt
         - info on the Matrox framebuffer driver for Alpha, Intel and PPC.
+metronomefb.txt
+        - info on the driver for the Metronome display controller.
 modedb.txt
         - info on the video mode database.
-matroxfb.txt
-        - info on the Matrox frame buffer driver.
 pvr2fb.txt
         - info on the PowerVR 2 frame buffer driver.
 pxafb.txt
@@ -39,13 +47,23 @@ s3fb.txt
         - info on the fbdev driver for S3 Trio/Virge chips.
 sa1100fb.txt
         - information about the driver for the SA-1100 LCD controller.
+sh7760fb.txt
+        - info on the SH7760/SH7763 integrated LCDC Framebuffer driver.
 sisfb.txt
         - info on the framebuffer device driver for various SiS chips.
 sstfb.txt
         - info on the frame buffer driver for 3dfx' Voodoo Graphics boards.
 tgafb.txt
-        - info on the TGA (DECChip 21030) frame buffer driver
+        - info on the TGA (DECChip 21030) frame buffer driver.
+tridentfb.txt
+        info on the framebuffer driver for some Trident chip based cards.
+uvesafb.txt
+        - info on the userspace VESA (VBE2+ compliant) frame buffer device.
 vesafb.txt
-        - info on the VESA frame buffer device
+        - info on the VESA frame buffer device.
+viafb.modes
+        - list of modes for VIA Integration Graphic Chip.
+viafb.txt
+        - info on the VIA Integration Graphic Chip console framebuffer driver.
 vt8623fb.txt
         - info on the fb driver for the graphics core in VIA VT8623 chipsets.
diff --git a/Documentation/fb/sm501.txt b/Documentation/fb/sm501.txt
new file mode 100644
index 000000000000..8d17aebd2648
--- /dev/null
+++ b/Documentation/fb/sm501.txt
@@ -0,0 +1,10 @@
+Configuration:
+
+You can pass the following kernel command line options to sm501 videoframebuffer:
+
+        sm501fb.bpp=    SM501 Display driver:
+                        Specifiy bits-per-pixel if not specified by 'mode'
+
+        sm501fb.mode=   SM501 Display driver:
+                        Specify resolution as
+                        "<xres>x<yres>[-<bpp>][@<refresh>]"
diff --git a/Documentation/fb/udlfb.txt b/Documentation/fb/udlfb.txt
new file mode 100644
index 000000000000..7fdde2a02a27
--- /dev/null
+++ b/Documentation/fb/udlfb.txt
@@ -0,0 +1,144 @@
+
+What is udlfb?
+===============
+
+This is a driver for DisplayLink USB 2.0 era graphics chips.
+
+DisplayLink chips provide simple hline/blit operations with some compression,
+pairing that with a hardware framebuffer (16MB) on the other end of the
+USB wire.  That hardware framebuffer is able to drive the VGA, DVI, or HDMI
+monitor with no CPU involvement until a pixel has to change.
+
+The CPU or other local resource does all the rendering; optinally compares the
+result with a local shadow of the remote hardware framebuffer to identify
+the minimal set of pixels that have changed; and compresses and sends those
+pixels line-by-line via USB bulk transfers.
+
+Because of the efficiency of bulk transfers and a protocol on top that
+does not require any acks - the effect is very low latency that
+can support surprisingly high resolutions with good performance for
+non-gaming and non-video applications.
+
+Mode setting, EDID read, etc are other bulk or control transfers. Mode
+setting is very flexible - able to set nearly arbitrary modes from any timing.
+
+Advantages of USB graphics in general:
+
+ * Ability to add a nearly arbitrary number of displays to any USB 2.0
+   capable system. On Linux, number of displays is limited by fbdev interface
+   (FB_MAX is currently 32). Of course, all USB devices on the same
+   host controller share the same 480Mbs USB 2.0 interface.
+
+Advantages of supporting DisplayLink chips with kernel framebuffer interface:
+
+ * The actual hardware functionality of DisplayLink chips matches nearly
+   one-to-one with the fbdev interface, making the driver quite small and
+   tight relative to the functionality it provides.
+ * X servers and other applications can use the standard fbdev interface
+   from user mode to talk to the device, without needing to know anything
+   about USB or DisplayLink's protocol at all. A "displaylink" X driver
+   and a slightly modified "fbdev" X driver are among those that already do.
+
+Disadvantages:
+
+ * Fbdev's mmap interface assumes a real hardware framebuffer is mapped.
+   In the case of USB graphics, it is just an allocated (virtual) buffer.
+   Writes need to be detected and encoded into USB bulk transfers by the CPU.
+   Accurate damage/changed area notifications work around this problem.
+   In the future, hopefully fbdev will be enhanced with an small standard
+   interface to allow mmap clients to report damage, for the benefit
+   of virtual or remote framebuffers.
+ * Fbdev does not arbitrate client ownership of the framebuffer well.
+ * Fbcon assumes the first framebuffer it finds should be consumed for console.
+ * It's not clear what the future of fbdev is, given the rise of KMS/DRM.
+
+How to use it?
+==============
+
+Udlfb, when loaded as a module, will match against all USB 2.0 generation
+DisplayLink chips (Alex and Ollie family). It will then attempt to read the EDID
+of the monitor, and set the best common mode between the DisplayLink device
+and the monitor's capabilities.
+
+If the DisplayLink device is successful, it will paint a "green screen" which
+means that from a hardware and fbdev software perspective, everything is good.
+
+At that point, a /dev/fb? interface will be present for user-mode applications
+to open and begin writing to the framebuffer of the DisplayLink device using
+standard fbdev calls.  Note that if mmap() is used, by default the user mode
+application must send down damage notifcations to trigger repaints of the
+changed regions.  Alternatively, udlfb can be recompiled with experimental
+defio support enabled, to support a page-fault based detection mechanism
+that can work without explicit notifcation.
+
+The most common client of udlfb is xf86-video-displaylink or a modified
+xf86-video-fbdev X server. These servers have no real DisplayLink specific
+code. They write to the standard framebuffer interface and rely on udlfb
+to do its thing.  The one extra feature they have is the ability to report
+rectangles from the X DAMAGE protocol extension down to udlfb via udlfb's
+damage interface (which will hopefully be standardized for all virtual
+framebuffers that need damage info). These damage notifications allow
+udlfb to efficiently process the changed pixels.
+
+Module Options
+==============
+
+Special configuration for udlfb is usually unnecessary. There are a few
+options, however.
+
+From the command line, pass options to modprobe
+modprobe udlfb defio=1 console=1
+
+Or for permanent option, create file like /etc/modprobe.d/options with text
+options udlfb defio=1 console=1
+
+Accepted options:
+
+fb_defio        Make use of the fb_defio (CONFIG_FB_DEFERRED_IO) kernel
+                module to track changed areas of the framebuffer by page faults.
+                Standard fbdev applications that use mmap but that do not
+                report damage, may be able to work with this enabled.
+                Disabled by default because of overhead and other issues.
+
+console         Allow fbcon to attach to udlfb provided framebuffers. This
+                is disabled by default because fbcon will aggressively consume
+                the first framebuffer it finds, which isn't usually what the
+                user wants in the case of USB displays.
+
+Sysfs Attributes
+================
+
+Udlfb creates several files in /sys/class/graphics/fb?
+Where ? is the sequential framebuffer id of the particular DisplayLink device
+
+edid                    If a valid EDID blob is written to this file (typically
+                        by a udev rule), then udlfb will use this EDID as a
+                        backup in case reading the actual EDID of the monitor
+                        attached to the DisplayLink device fails. This is
+                        especially useful for fixed panels, etc. that cannot
+                        communicate their capabilities via EDID. Reading
+                        this file returns the current EDID of the attached
+                        monitor (or last backup value written). This is
+                        useful to get the EDID of the attached monitor,
+                        which can be passed to utilities like parse-edid.
+
+metrics_bytes_rendered  32-bit count of pixel bytes rendered
+
+metrics_bytes_identical 32-bit count of how many of those bytes were found to be
+                        unchanged, based on a shadow framebuffer check
+
+metrics_bytes_sent      32-bit count of how many bytes were transferred over
+                        USB to communicate the resulting changed pixels to the
+                        hardware. Includes compression and protocol overhead
+
+metrics_cpu_kcycles_used 32-bit count of CPU cycles used in processing the
+                        above pixels (in thousands of cycles).
+
+metrics_reset           Write-only. Any write to this file resets all metrics
+                        above to zero.  Note that the 32-bit counters above
+                        roll over very quickly. To get reliable results, design
+                        performance tests to start and finish in a very short
+                        period of time (one minute or less is safe).
+
+--
+Bernie Thompson <bernie@plugable.com>
diff --git a/Documentation/fb/viafb.txt b/Documentation/fb/viafb.txt
index f3e046a6a987..444e34b52ae1 100644
--- a/Documentation/fb/viafb.txt
+++ b/Documentation/fb/viafb.txt
@@ -197,6 +197,54 @@ Notes:
        example,
            # fbset -depth 16
 
+
+[Configure viafb via /proc]
+---------------------------
+    The following files exist in /proc/viafb
+
+    supported_output_devices
+
+        This read-only file contains a full ',' separated list containing all
+        output devices that could be available on your platform. It is likely
+        that not all of those have a connector on your hardware but it should
+        provide a good starting point to figure out which of those names match
+        a real connector.
+        Example:
+        # cat /proc/viafb/supported_output_devices
+
+    iga1/output_devices
+    iga2/output_devices
+
+        These two files are readable and writable. iga1 and iga2 are the two
+        independent units that produce the screen image. Those images can be
+        forwarded to one or more output devices. Reading those files is a way
+        to query which output devices are currently used by an iga.
+        Example:
+        # cat /proc/viafb/iga1/output_devices
+        If there are no output devices printed the output of this iga is lost.
+        This can happen for example if only one (the other) iga is used.
+        Writing to these files allows adjusting the output devices during
+        runtime. One can add new devices, remove existing ones or switch
+        between igas. Essentially you can write a ',' separated list of device
+        names (or a single one) in the same format as the output to those
+        files. You can add a '+' or '-' as a prefix allowing simple addition
+        and removal of devices. So a prefix '+' adds the devices from your list
+        to the already existing ones, '-' removes the listed devices from the
+        existing ones and if no prefix is given it replaces all existing ones
+        with the listed ones. If you remove devices they are expected to turn
+        off. If you add devices that are already part of the other iga they are
+        removed there and added to the new one.
+        Examples:
+        Add CRT as output device to iga1
+        # echo +CRT > /proc/viafb/iga1/output_devices
+
+        Remove (turn off) DVP1 and LVDS1 as output devices of iga2
+        # echo -DVP1,LVDS1 > /proc/viafb/iga2/output_devices
+
+        Replace all iga1 output devices by CRT
+        # echo CRT > /proc/viafb/iga1/output_devices
+
+
 [Bootup with viafb]:
 --------------------
     Add the following line to your grub.conf: