summaryrefslogtreecommitdiff
path: root/Documentation/fb
diff options
context:
space:
mode:
authorEric Miao <ycmiao@ycmiao-hp520.(none)>2008-12-23 17:49:43 +0800
committerEric Miao <eric.miao@marvell.com>2008-12-29 18:00:04 +0800
commit198fc108ee4c2cd3f08954eae6a819c81c03214b (patch)
tree153fdb793142ef5ee8e0ab6198dcde32866b062c /Documentation/fb
parent3f16ff608a75c8bf28c8cafed12e076d67a3602a (diff)
[ARM] pxafb: add support for overlay1 and overlay2 as framebuffer devices
PXA27x and later processors support overlay1 and overlay2 on-top of the base framebuffer (although under-neath the base is also possible). They support palette and no-palette RGB formats, as well as YUV formats (only available on overlay2). These overlays have dedicated DMA channels and behave in a similar way as a framebuffer. This heavily simplified and re-structured work is based on the original pxafb_overlay.c (which is pending for mainline merge for a long time). The major problems with this pxafb_overlay.c are (if you are interested in the history): 1. heavily redundant (the control logics for overlay1 and overlay2 are actually identical except for some small operations, which are now abstracted into a 'pxafb_layer_ops' structure) 2. a lot of useless and un-tested code (two workarounds which are now fixed on mature silicons) 3. cursorfb is actually useless, hardware cursor should not be used this way, and the code was actually un-tested for a long time. The code in this patch should be self-explanatory, I tried to add minimum comments. As said, this is basically simplified, there are several things still on the pending list: 1. palette mode is un-supported and un-tested (although re-using the palette code of the base framebuffer is actually very easy now with previous clean-up patches) 2. fb_pan_display for overlay(s) is un-supported 3. the base framebuffer can actually be abstracted by 'pxafb_layer' as well, which will help further re-use of the code and keep a better and consistent structure. (This is the reason I named it 'pxafb_layer' instead of 'pxafb_overlay' or something alike) See Documentation/fb/pxafb.txt for additional usage information. Signed-off-by: Eric Miao <eric.miao@marvell.com> Cc: Rodolfo Giometti <giometti@linux.it> Signed-off-by: Eric Miao <ycmiao@ycmiao-hp520.(none)>
Diffstat (limited to 'Documentation/fb')
-rw-r--r--Documentation/fb/pxafb.txt84
1 files changed, 84 insertions, 0 deletions
diff --git a/Documentation/fb/pxafb.txt b/Documentation/fb/pxafb.txt
index ad94b5ca0095..d143a0a749f9 100644
--- a/Documentation/fb/pxafb.txt
+++ b/Documentation/fb/pxafb.txt
@@ -56,3 +56,87 @@ outputen:POLARITY
pixclockpol:POLARITY
pixel clock polarity
0 => falling edge, 1 => rising edge
+
+
+Overlay Support for PXA27x and later LCD controllers
+====================================================
+
+ PXA27x and later processors support overlay1 and overlay2 on-top of the
+ base framebuffer (although under-neath the base is also possible). They
+ support palette and no-palette RGB formats, as well as YUV formats (only
+ available on overlay2). These overlays have dedicated DMA channels and
+ behave in a similar way as a framebuffer.
+
+ However, there are some differences between these overlay framebuffers
+ and normal framebuffers, as listed below:
+
+ 1. overlay can start at a 32-bit word aligned position within the base
+ framebuffer, which means they have a start (x, y). This information
+ is encoded into var->nonstd (no, var->xoffset and var->yoffset are
+ not for such purpose).
+
+ 2. overlay framebuffer is allocated dynamically according to specified
+ 'struct fb_var_screeninfo', the amount is decided by:
+
+ var->xres_virtual * var->yres_virtual * bpp
+
+ bpp = 16 -- for RGB565 or RGBT555
+ = 24 -- for YUV444 packed
+ = 24 -- for YUV444 planar
+ = 16 -- for YUV422 planar (1 pixel = 1 Y + 1/2 Cb + 1/2 Cr)
+ = 12 -- for YUV420 planar (1 pixel = 1 Y + 1/4 Cb + 1/4 Cr)
+
+ NOTE:
+
+ a. overlay does not support panning in x-direction, thus
+ var->xres_virtual will always be equal to var->xres
+
+ b. line length of overlay(s) must be on a 32-bit word boundary,
+ for YUV planar modes, it is a requirement for the component
+ with minimum bits per pixel, e.g. for YUV420, Cr component
+ for one pixel is actually 2-bits, it means the line length
+ should be a multiple of 16-pixels
+
+ c. starting horizontal position (XPOS) should start on a 32-bit
+ word boundary, otherwise the fb_check_var() will just fail.
+
+ d. the rectangle of the overlay should be within the base plane,
+ otherwise fail
+
+ Applications should follow the sequence below to operate an overlay
+ framebuffer:
+
+ a. open("/dev/fb[1-2]", ...)
+ b. ioctl(fd, FBIOGET_VSCREENINFO, ...)
+ c. modify 'var' with desired parameters:
+ 1) var->xres and var->yres
+ 2) larger var->yres_virtual if more memory is required,
+ usually for double-buffering
+ 3) var->nonstd for starting (x, y) and color format
+ 4) var->{red, green, blue, transp} if RGB mode is to be used
+ d. ioctl(fd, FBIOPUT_VSCREENINFO, ...)
+ e. ioctl(fd, FBIOGET_FSCREENINFO, ...)
+ f. mmap
+ g. ...
+
+ 3. for YUV planar formats, these are actually not supported within the
+ framebuffer framework, application has to take care of the offsets
+ and lengths of each component within the framebuffer.
+
+ 4. var->nonstd is used to pass starting (x, y) position and color format,
+ the detailed bit fields are shown below:
+
+ 31 23 20 10 0
+ +-----------------+---+----------+----------+
+ | ... unused ... |FOR| XPOS | YPOS |
+ +-----------------+---+----------+----------+
+
+ FOR - color format, as defined by OVERLAY_FORMAT_* in pxafb.h
+ 0 - RGB
+ 1 - YUV444 PACKED
+ 2 - YUV444 PLANAR
+ 3 - YUV422 PLANAR
+ 4 - YUR420 PLANAR
+
+ XPOS - starting horizontal position
+ YPOS - starting vertical position