diff options
Diffstat (limited to 'drivers')
| -rw-r--r-- | drivers/staging/Kconfig | 2 | ||||
| -rw-r--r-- | drivers/staging/Makefile | 1 | ||||
| -rw-r--r-- | drivers/staging/udlfb/Kconfig | 14 | ||||
| -rw-r--r-- | drivers/staging/udlfb/Makefile | 1 | ||||
| -rw-r--r-- | drivers/staging/udlfb/udlfb.h | 117 | ||||
| -rw-r--r-- | drivers/staging/udlfb/udlfb.txt | 144 | ||||
| -rw-r--r-- | drivers/video/Kconfig | 14 | ||||
| -rw-r--r-- | drivers/video/Makefile | 1 | ||||
| -rw-r--r-- | drivers/video/udlfb.c (renamed from drivers/staging/udlfb/udlfb.c) | 3 |
9 files changed, 16 insertions, 281 deletions
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig index 5eafdf43555..df31a722807 100644 --- a/drivers/staging/Kconfig +++ b/drivers/staging/Kconfig @@ -111,8 +111,6 @@ source "drivers/staging/vt6655/Kconfig" source "drivers/staging/vt6656/Kconfig" -source "drivers/staging/udlfb/Kconfig" - source "drivers/staging/hv/Kconfig" source "drivers/staging/vme/Kconfig" diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile index a97a955c094..7a15c0c82b6 100644 --- a/drivers/staging/Makefile +++ b/drivers/staging/Makefile @@ -38,7 +38,6 @@ obj-$(CONFIG_USB_SERIAL_QUATECH_USB2) += quatech_usb2/ obj-$(CONFIG_OCTEON_ETHERNET) += octeon/ obj-$(CONFIG_VT6655) += vt6655/ obj-$(CONFIG_VT6656) += vt6656/ -obj-$(CONFIG_FB_UDL) += udlfb/ obj-$(CONFIG_HYPERV) += hv/ obj-$(CONFIG_VME_BUS) += vme/ obj-$(CONFIG_MRST_RAR_HANDLER) += memrar/ diff --git a/drivers/staging/udlfb/Kconfig b/drivers/staging/udlfb/Kconfig deleted file mode 100644 index 65bd5db4ca5..00000000000 --- a/drivers/staging/udlfb/Kconfig +++ /dev/null @@ -1,14 +0,0 @@ -config FB_UDL - tristate "Displaylink USB Framebuffer support" - depends on FB && USB - select FB_MODE_HELPERS - select FB_SYS_FILLRECT - select FB_SYS_COPYAREA - select FB_SYS_IMAGEBLIT - select FB_SYS_FOPS - select FB_DEFERRED_IO - ---help--- - This is a kernel framebuffer driver for DisplayLink USB devices. - Supports fbdev clients like xf86-video-fbdev, kdrive, fbi, and - mplayer -vo fbdev. Supports all USB 2.0 era DisplayLink devices. - To compile as a module, choose M here: the module name is udlfb. diff --git a/drivers/staging/udlfb/Makefile b/drivers/staging/udlfb/Makefile deleted file mode 100644 index 30d9e675b10..00000000000 --- a/drivers/staging/udlfb/Makefile +++ /dev/null @@ -1 +0,0 @@ -obj-$(CONFIG_FB_UDL) += udlfb.o diff --git a/drivers/staging/udlfb/udlfb.h b/drivers/staging/udlfb/udlfb.h deleted file mode 100644 index 6f9785e9d62..00000000000 --- a/drivers/staging/udlfb/udlfb.h +++ /dev/null @@ -1,117 +0,0 @@ -#ifndef UDLFB_H -#define UDLFB_H - -/* - * TODO: Propose standard fb.h ioctl for reporting damage, - * using _IOWR() and one of the existing area structs from fb.h - * Consider these ioctls deprecated, but they're still used by the - * DisplayLink X server as yet - need both to be modified in tandem - * when new ioctl(s) are ready. - */ -#define DLFB_IOCTL_RETURN_EDID 0xAD -#define DLFB_IOCTL_REPORT_DAMAGE 0xAA -struct dloarea { - int x, y; - int w, h; - int x2, y2; -}; - -struct urb_node { - struct list_head entry; - struct dlfb_data *dev; - struct delayed_work release_urb_work; - struct urb *urb; -}; - -struct urb_list { - struct list_head list; - spinlock_t lock; - struct semaphore limit_sem; - int available; - int count; - size_t size; -}; - -struct dlfb_data { - struct usb_device *udev; - struct device *gdev; /* &udev->dev */ - struct fb_info *info; - struct urb_list urbs; - struct kref kref; - char *backing_buffer; - int fb_count; - bool virtualized; /* true when physical usb device not present */ - struct delayed_work free_framebuffer_work; - atomic_t usb_active; /* 0 = update virtual buffer, but no usb traffic */ - atomic_t lost_pixels; /* 1 = a render op failed. Need screen refresh */ - char *edid; /* null until we read edid from hw or get from sysfs */ - size_t edid_size; - int sku_pixel_limit; - int base16; - int base8; - u32 pseudo_palette[256]; - /* blit-only rendering path metrics, exposed through sysfs */ - atomic_t bytes_rendered; /* raw pixel-bytes driver asked to render */ - atomic_t bytes_identical; /* saved effort with backbuffer comparison */ - atomic_t bytes_sent; /* to usb, after compression including overhead */ - atomic_t cpu_kcycles_used; /* transpired during pixel processing */ -}; - -#define NR_USB_REQUEST_I2C_SUB_IO 0x02 -#define NR_USB_REQUEST_CHANNEL 0x12 - -/* -BULK_SIZE as per usb-skeleton. Can we get full page and avoid overhead? */ -#define BULK_SIZE 512 -#define MAX_TRANSFER (PAGE_SIZE*16 - BULK_SIZE) -#define WRITES_IN_FLIGHT (4) - -#define MIN_EDID_SIZE 128 -#define MAX_EDID_SIZE 128 - -#define MAX_VENDOR_DESCRIPTOR_SIZE 256 - -#define GET_URB_TIMEOUT HZ -#define FREE_URB_TIMEOUT (HZ*2) - -#define BPP 2 -#define MAX_CMD_PIXELS 255 - -#define RLX_HEADER_BYTES 7 -#define MIN_RLX_PIX_BYTES 4 -#define MIN_RLX_CMD_BYTES (RLX_HEADER_BYTES + MIN_RLX_PIX_BYTES) - -#define RLE_HEADER_BYTES 6 -#define MIN_RLE_PIX_BYTES 3 -#define MIN_RLE_CMD_BYTES (RLE_HEADER_BYTES + MIN_RLE_PIX_BYTES) - -#define RAW_HEADER_BYTES 6 -#define MIN_RAW_PIX_BYTES 2 -#define MIN_RAW_CMD_BYTES (RAW_HEADER_BYTES + MIN_RAW_PIX_BYTES) - -#define DL_DEFIO_WRITE_DELAY 5 /* fb_deferred_io.delay in jiffies */ -#define DL_DEFIO_WRITE_DISABLE (HZ*60) /* "disable" with long delay */ - -/* remove these once align.h patch is taken into kernel */ -#define DL_ALIGN_UP(x, a) ALIGN(x, a) -#define DL_ALIGN_DOWN(x, a) ALIGN(x-(a-1), a) - -/* remove once this gets added to sysfs.h */ -#define __ATTR_RW(attr) __ATTR(attr, 0644, attr##_show, attr##_store) - -/* - * udlfb is both a usb device, and a framebuffer device. - * They may exist at the same time, but during various stages - * inactivity, teardown, or "virtual" operation, only one or the - * other will exist (one will outlive the other). So we can't - * call the dev_*() macros, because we don't have a stable dev object. - */ -#define dl_err(format, arg...) \ - pr_err("udlfb: " format, ## arg) -#define dl_warn(format, arg...) \ - pr_warning("udlfb: " format, ## arg) -#define dl_notice(format, arg...) \ - pr_notice("udlfb: " format, ## arg) -#define dl_info(format, arg...) \ - pr_info("udlfb: " format, ## arg) - -#endif diff --git a/drivers/staging/udlfb/udlfb.txt b/drivers/staging/udlfb/udlfb.txt deleted file mode 100644 index 7fdde2a02a2..00000000000 --- a/drivers/staging/udlfb/udlfb.txt +++ /dev/null @@ -1,144 +0,0 @@ - -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/drivers/video/Kconfig b/drivers/video/Kconfig index 27c1fb4b1e0..37771d0916e 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -2034,6 +2034,20 @@ config FB_SM501 If unsure, say N. +config FB_UDL + tristate "Displaylink USB Framebuffer support" + depends on FB && USB + select FB_MODE_HELPERS + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_DEFERRED_IO + ---help--- + This is a kernel framebuffer driver for DisplayLink USB devices. + Supports fbdev clients like xf86-video-fbdev, kdrive, fbi, and + mplayer -vo fbdev. Supports all USB 2.0 era DisplayLink devices. + To compile as a module, choose M here: the module name is udlfb. config FB_PNX4008_DUM tristate "Display Update Module support on Philips PNX4008 board" diff --git a/drivers/video/Makefile b/drivers/video/Makefile index 485e8ed1318..03678e3021a 100644 --- a/drivers/video/Makefile +++ b/drivers/video/Makefile @@ -122,6 +122,7 @@ obj-$(CONFIG_FB_PNX4008_DUM_RGB) += pnx4008/ obj-$(CONFIG_FB_IBM_GXT4500) += gxt4500.o obj-$(CONFIG_FB_PS3) += ps3fb.o obj-$(CONFIG_FB_SM501) += sm501fb.o +obj-$(CONFIG_FB_UDL) += udlfb.o obj-$(CONFIG_FB_XILINX) += xilinxfb.o obj-$(CONFIG_SH_MIPI_DSI) += sh_mipi_dsi.o obj-$(CONFIG_FB_SH_MOBILE_HDMI) += sh_mobile_hdmi.o diff --git a/drivers/staging/udlfb/udlfb.c b/drivers/video/udlfb.c index fed25105970..0cca4873d49 100644 --- a/drivers/staging/udlfb/udlfb.c +++ b/drivers/video/udlfb.c @@ -26,8 +26,7 @@ #include <linux/vmalloc.h> #include <linux/slab.h> #include <linux/delay.h> - -#include "udlfb.h" +#include <video/udlfb.h> static struct fb_fix_screeninfo dlfb_fix = { .id = "udlfb", |