1 ================================
2 Driver for PXA25x LCD controller
3 ================================
4
5 The driver supports the following options, either via
6 options=<OPTIONS> when modular or video=pxafb:<OPTIONS> when built in.
7
8 For example::
9
10 modprobe pxafb options=vmem:2M,mode:640x480-8,passive
11
12 or on the kernel command line::
13
14 video=pxafb:vmem:2M,mode:640x480-8,passive
15
16 vmem: VIDEO_MEM_SIZE
17
18 Amount of video memory to allocate (can be suffixed with K or M
19 for kilobytes or megabytes)
20
21 mode:XRESxYRES[-BPP]
22
23 XRES == LCCR1_PPL + 1
24
25 YRES == LLCR2_LPP + 1
26
27 The resolution of the display in pixels
28
29 BPP == The bit depth. Valid values are 1, 2, 4, 8 and 16.
30
31 pixclock:PIXCLOCK
32
33 Pixel clock in picoseconds
34
35 left:LEFT == LCCR1_BLW + 1
36
37 right:RIGHT == LCCR1_ELW + 1
38
39 hsynclen:HSYNC == LCCR1_HSW + 1
40
41 upper:UPPER == LCCR2_BFW
42
43 lower:LOWER == LCCR2_EFR
44
45 vsynclen:VSYNC == LCCR2_VSW + 1
46
47 Display margins and sync times
48
49 color | mono => LCCR0_CMS
50
51 umm...
52
53 active | passive => LCCR0_PAS
54
55 Active (TFT) or Passive (STN) display
56
57 single | dual => LCCR0_SDS
58
59 Single or dual panel passive display
60
61 4pix | 8pix => LCCR0_DPD
62
63 4 or 8 pixel monochrome single panel data
64
65 hsync:HSYNC, vsync:VSYNC
66
67 Horizontal and vertical sync. 0 => active low, 1 => active
68 high.
69
70 dpc:DPC
71
72 Double pixel clock. 1=>true, 0=>false
73
74 outputen:POLARITY
75
76 Output Enable Polarity. 0 => active low, 1 => active high
77
78 pixclockpol:POLARITY
79
80 pixel clock polarity
81 0 => falling edge, 1 => rising edge
82
83
84 Overlay Support for PXA27x and later LCD controllers
85 ====================================================
86
87 PXA27x and later processors support overlay1 and overlay2 on-top of the
88 base framebuffer (although under-neath the base is also possible). They
89 support palette and no-palette RGB formats, as well as YUV formats (only
90 available on overlay2). These overlays have dedicated DMA channels and
91 behave in a similar way as a framebuffer.
92
93 However, there are some differences between these overlay framebuffers
94 and normal framebuffers, as listed below:
95
96 1. overlay can start at a 32-bit word aligned position within the base
97 framebuffer, which means they have a start (x, y). This information
98 is encoded into var->nonstd (no, var->xoffset and var->yoffset are
99 not for such purpose).
100
101 2. overlay framebuffer is allocated dynamically according to specified
102 'struct fb_var_screeninfo', the amount is decided by::
103
104 var->xres_virtual * var->yres_virtual * bpp
105
106 bpp = 16 -- for RGB565 or RGBT555
107
108 bpp = 24 -- for YUV444 packed
109
110 bpp = 24 -- for YUV444 planar
111
112 bpp = 16 -- for YUV422 planar (1 pixel = 1 Y + 1/2 Cb + 1/2 Cr)
113
114 bpp = 12 -- for YUV420 planar (1 pixel = 1 Y + 1/4 Cb + 1/4 Cr)
115
116 NOTE:
117
118 a. overlay does not support panning in x-direction, thus
119 var->xres_virtual will always be equal to var->xres
120
121 b. line length of overlay(s) must be on a 32-bit word boundary,
122 for YUV planar modes, it is a requirement for the component
123 with minimum bits per pixel, e.g. for YUV420, Cr component
124 for one pixel is actually 2-bits, it means the line length
125 should be a multiple of 16-pixels
126
127 c. starting horizontal position (XPOS) should start on a 32-bit
128 word boundary, otherwise the fb_check_var() will just fail.
129
130 d. the rectangle of the overlay should be within the base plane,
131 otherwise fail
132
133 Applications should follow the sequence below to operate an overlay
134 framebuffer:
135
136 a. open("/dev/fb[1-2]", ...)
137 b. ioctl(fd, FBIOGET_VSCREENINFO, ...)
138 c. modify 'var' with desired parameters:
139
140 1) var->xres and var->yres
141 2) larger var->yres_virtual if more memory is required,
142 usually for double-buffering
143 3) var->nonstd for starting (x, y) and color format
144 4) var->{red, green, blue, transp} if RGB mode is to be used
145
146 d. ioctl(fd, FBIOPUT_VSCREENINFO, ...)
147 e. ioctl(fd, FBIOGET_FSCREENINFO, ...)
148 f. mmap
149 g. ...
150
151 3. for YUV planar formats, these are actually not supported within the
152 framebuffer framework, application has to take care of the offsets
153 and lengths of each component within the framebuffer.
154
155 4. var->nonstd is used to pass starting (x, y) position and color format,
156 the detailed bit fields are shown below::
157
158 31 23 20 10 0
159 +-----------------+---+----------+----------+
160 | ... unused ... |FOR| XPOS | YPOS |
161 +-----------------+---+----------+----------+
162
163 FOR - color format, as defined by OVERLAY_FORMAT_* in pxafb.h
164
165 - 0 - RGB
166 - 1 - YUV444 PACKED
167 - 2 - YUV444 PLANAR
168 - 3 - YUV422 PLANAR
169 - 4 - YUR420 PLANAR
170
171 XPOS - starting horizontal position
172
173 YPOS - starting vertical position
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.