aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/fb/pxafb.txt
diff options
context:
space:
mode:
authorEric Miao <ycmiao@ycmiao-hp520.(none)>2008-12-23 04:49:43 -0500
committerEric Miao <eric.miao@marvell.com>2008-12-29 05:00:04 -0500
commit198fc108ee4c2cd3f08954eae6a819c81c03214b (patch)
tree153fdb793142ef5ee8e0ab6198dcde32866b062c /Documentation/fb/pxafb.txt
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/pxafb.txt')
-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
56pixclockpol:POLARITY 56pixclockpol:POLARITY
57 pixel clock polarity 57 pixel clock polarity
58 0 => falling edge, 1 => rising edge 58 0 => falling edge, 1 => rising edge
59
60
61Overlay Support for PXA27x and later LCD controllers
62====================================================
63
64 PXA27x and later processors support overlay1 and overlay2 on-top of the
65 base framebuffer (although under-neath the base is also possible). They
66 support palette and no-palette RGB formats, as well as YUV formats (only
67 available on overlay2). These overlays have dedicated DMA channels and
68 behave in a similar way as a framebuffer.
69
70 However, there are some differences between these overlay framebuffers
71 and normal framebuffers, as listed below:
72
73 1. overlay can start at a 32-bit word aligned position within the base
74 framebuffer, which means they have a start (x, y). This information
75 is encoded into var->nonstd (no, var->xoffset and var->yoffset are
76 not for such purpose).
77
78 2. overlay framebuffer is allocated dynamically according to specified
79 'struct fb_var_screeninfo', the amount is decided by:
80
81 var->xres_virtual * var->yres_virtual * bpp
82
83 bpp = 16 -- for RGB565 or RGBT555
84 = 24 -- for YUV444 packed
85 = 24 -- for YUV444 planar
86 = 16 -- for YUV422 planar (1 pixel = 1 Y + 1/2 Cb + 1/2 Cr)
87 = 12 -- for YUV420 planar (1 pixel = 1 Y + 1/4 Cb + 1/4 Cr)
88
89 NOTE:
90
91 a. overlay does not support panning in x-direction, thus
92 var->xres_virtual will always be equal to var->xres
93
94 b. line length of overlay(s) must be on a 32-bit word boundary,
95 for YUV planar modes, it is a requirement for the component
96 with minimum bits per pixel, e.g. for YUV420, Cr component
97 for one pixel is actually 2-bits, it means the line length
98 should be a multiple of 16-pixels
99
100 c. starting horizontal position (XPOS) should start on a 32-bit
101 word boundary, otherwise the fb_check_var() will just fail.
102
103 d. the rectangle of the overlay should be within the base plane,
104 otherwise fail
105
106 Applications should follow the sequence below to operate an overlay
107 framebuffer:
108
109 a. open("/dev/fb[1-2]", ...)
110 b. ioctl(fd, FBIOGET_VSCREENINFO, ...)
111 c. modify 'var' with desired parameters:
112 1) var->xres and var->yres
113 2) larger var->yres_virtual if more memory is required,
114 usually for double-buffering
115 3) var->nonstd for starting (x, y) and color format
116 4) var->{red, green, blue, transp} if RGB mode is to be used
117 d. ioctl(fd, FBIOPUT_VSCREENINFO, ...)
118 e. ioctl(fd, FBIOGET_FSCREENINFO, ...)
119 f. mmap
120 g. ...
121
122 3. for YUV planar formats, these are actually not supported within the
123 framebuffer framework, application has to take care of the offsets
124 and lengths of each component within the framebuffer.
125
126 4. var->nonstd is used to pass starting (x, y) position and color format,
127 the detailed bit fields are shown below:
128
129 31 23 20 10 0
130 +-----------------+---+----------+----------+
131 | ... unused ... |FOR| XPOS | YPOS |
132 +-----------------+---+----------+----------+
133
134 FOR - color format, as defined by OVERLAY_FORMAT_* in pxafb.h
135 0 - RGB
136 1 - YUV444 PACKED
137 2 - YUV444 PLANAR
138 3 - YUV422 PLANAR
139 4 - YUR420 PLANAR
140
141 XPOS - starting horizontal position
142 YPOS - starting vertical position