Root/
1 | Driver for PXA25x LCD controller |
2 | ================================ |
3 | |
4 | The driver supports the following options, either via |
5 | options=<OPTIONS> when modular or video=pxafb:<OPTIONS> when built in. |
6 | |
7 | For example: |
8 | modprobe pxafb options=vmem:2M,mode:640x480-8,passive |
9 | or on the kernel command line |
10 | video=pxafb:vmem:2M,mode:640x480-8,passive |
11 | |
12 | vmem: VIDEO_MEM_SIZE |
13 | Amount of video memory to allocate (can be suffixed with K or M |
14 | for kilobytes or megabytes) |
15 | |
16 | mode:XRESxYRES[-BPP] |
17 | XRES == LCCR1_PPL + 1 |
18 | YRES == LLCR2_LPP + 1 |
19 | The resolution of the display in pixels |
20 | BPP == The bit depth. Valid values are 1, 2, 4, 8 and 16. |
21 | |
22 | pixclock:PIXCLOCK |
23 | Pixel clock in picoseconds |
24 | |
25 | left:LEFT == LCCR1_BLW + 1 |
26 | right:RIGHT == LCCR1_ELW + 1 |
27 | hsynclen:HSYNC == LCCR1_HSW + 1 |
28 | upper:UPPER == LCCR2_BFW |
29 | lower:LOWER == LCCR2_EFR |
30 | vsynclen:VSYNC == LCCR2_VSW + 1 |
31 | Display margins and sync times |
32 | |
33 | color | mono => LCCR0_CMS |
34 | umm... |
35 | |
36 | active | passive => LCCR0_PAS |
37 | Active (TFT) or Passive (STN) display |
38 | |
39 | single | dual => LCCR0_SDS |
40 | Single or dual panel passive display |
41 | |
42 | 4pix | 8pix => LCCR0_DPD |
43 | 4 or 8 pixel monochrome single panel data |
44 | |
45 | hsync:HSYNC |
46 | vsync:VSYNC |
47 | Horizontal and vertical sync. 0 => active low, 1 => active |
48 | high. |
49 | |
50 | dpc:DPC |
51 | Double pixel clock. 1=>true, 0=>false |
52 | |
53 | outputen:POLARITY |
54 | Output Enable Polarity. 0 => active low, 1 => active high |
55 | |
56 | pixclockpol:POLARITY |
57 | pixel clock polarity |
58 | 0 => falling edge, 1 => rising edge |
59 | |
60 | |
61 | Overlay 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 |
143 |
Branches:
ben-wpan
ben-wpan-stefan
javiroman/ks7010
jz-2.6.34
jz-2.6.34-rc5
jz-2.6.34-rc6
jz-2.6.34-rc7
jz-2.6.35
jz-2.6.36
jz-2.6.37
jz-2.6.38
jz-2.6.39
jz-3.0
jz-3.1
jz-3.11
jz-3.12
jz-3.13
jz-3.15
jz-3.16
jz-3.18-dt
jz-3.2
jz-3.3
jz-3.4
jz-3.5
jz-3.6
jz-3.6-rc2-pwm
jz-3.9
jz-3.9-clk
jz-3.9-rc8
jz47xx
jz47xx-2.6.38
master
Tags:
od-2011-09-04
od-2011-09-18
v2.6.34-rc5
v2.6.34-rc6
v2.6.34-rc7
v3.9