diff options
author | Tomi Valkeinen <tomi.valkeinen@nokia.com> | 2009-08-04 08:47:11 -0400 |
---|---|---|
committer | Tomi Valkeinen <tomi.valkeinen@nokia.com> | 2009-12-09 05:04:34 -0500 |
commit | 4d1a7c122aeae6ae9732be0a32f5e199fff63fb7 (patch) | |
tree | b97e3fcd365ca34d7e3854c7fc20b874bc89c47c /Documentation/arm | |
parent | 640f9ca5fd783393c832f6bb5c56368f4d18b820 (diff) |
OMAP: DSS2: Documentation for DSS2
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
Diffstat (limited to 'Documentation/arm')
-rw-r--r-- | Documentation/arm/OMAP/DSS | 317 |
1 files changed, 317 insertions, 0 deletions
diff --git a/Documentation/arm/OMAP/DSS b/Documentation/arm/OMAP/DSS new file mode 100644 index 00000000000..0af0e9eed5d --- /dev/null +++ b/Documentation/arm/OMAP/DSS | |||
@@ -0,0 +1,317 @@ | |||
1 | OMAP2/3 Display Subsystem | ||
2 | ------------------------- | ||
3 | |||
4 | This is an almost total rewrite of the OMAP FB driver in drivers/video/omap | ||
5 | (let's call it DSS1). The main differences between DSS1 and DSS2 are DSI, | ||
6 | TV-out and multiple display support, but there are lots of small improvements | ||
7 | also. | ||
8 | |||
9 | The DSS2 driver (omapdss module) is in arch/arm/plat-omap/dss/, and the FB, | ||
10 | panel and controller drivers are in drivers/video/omap2/. DSS1 and DSS2 live | ||
11 | currently side by side, you can choose which one to use. | ||
12 | |||
13 | Features | ||
14 | -------- | ||
15 | |||
16 | Working and tested features include: | ||
17 | |||
18 | - MIPI DPI (parallel) output | ||
19 | - MIPI DSI output in command mode | ||
20 | - MIPI DBI (RFBI) output | ||
21 | - SDI output | ||
22 | - TV output | ||
23 | - All pieces can be compiled as a module or inside kernel | ||
24 | - Use DISPC to update any of the outputs | ||
25 | - Use CPU to update RFBI or DSI output | ||
26 | - OMAP DISPC planes | ||
27 | - RGB16, RGB24 packed, RGB24 unpacked | ||
28 | - YUV2, UYVY | ||
29 | - Scaling | ||
30 | - Adjusting DSS FCK to find a good pixel clock | ||
31 | - Use DSI DPLL to create DSS FCK | ||
32 | |||
33 | Tested boards include: | ||
34 | - OMAP3 SDP board | ||
35 | - Beagle board | ||
36 | - N810 | ||
37 | |||
38 | omapdss driver | ||
39 | -------------- | ||
40 | |||
41 | The DSS driver does not itself have any support for Linux framebuffer, V4L or | ||
42 | such like the current ones, but it has an internal kernel API that upper level | ||
43 | drivers can use. | ||
44 | |||
45 | The DSS driver models OMAP's overlays, overlay managers and displays in a | ||
46 | flexible way to enable non-common multi-display configuration. In addition to | ||
47 | modelling the hardware overlays, omapdss supports virtual overlays and overlay | ||
48 | managers. These can be used when updating a display with CPU or system DMA. | ||
49 | |||
50 | Panel and controller drivers | ||
51 | ---------------------------- | ||
52 | |||
53 | The drivers implement panel or controller specific functionality and are not | ||
54 | usually visible to users except through omapfb driver. They register | ||
55 | themselves to the DSS driver. | ||
56 | |||
57 | omapfb driver | ||
58 | ------------- | ||
59 | |||
60 | The omapfb driver implements arbitrary number of standard linux framebuffers. | ||
61 | These framebuffers can be routed flexibly to any overlays, thus allowing very | ||
62 | dynamic display architecture. | ||
63 | |||
64 | The driver exports some omapfb specific ioctls, which are compatible with the | ||
65 | ioctls in the old driver. | ||
66 | |||
67 | The rest of the non standard features are exported via sysfs. Whether the final | ||
68 | implementation will use sysfs, or ioctls, is still open. | ||
69 | |||
70 | V4L2 drivers | ||
71 | ------------ | ||
72 | |||
73 | V4L2 is being implemented in TI. | ||
74 | |||
75 | From omapdss point of view the V4L2 drivers should be similar to framebuffer | ||
76 | driver. | ||
77 | |||
78 | Architecture | ||
79 | -------------------- | ||
80 | |||
81 | Some clarification what the different components do: | ||
82 | |||
83 | - Framebuffer is a memory area inside OMAP's SRAM/SDRAM that contains the | ||
84 | pixel data for the image. Framebuffer has width and height and color | ||
85 | depth. | ||
86 | - Overlay defines where the pixels are read from and where they go on the | ||
87 | screen. The overlay may be smaller than framebuffer, thus displaying only | ||
88 | part of the framebuffer. The position of the overlay may be changed if | ||
89 | the overlay is smaller than the display. | ||
90 | - Overlay manager combines the overlays in to one image and feeds them to | ||
91 | display. | ||
92 | - Display is the actual physical display device. | ||
93 | |||
94 | A framebuffer can be connected to multiple overlays to show the same pixel data | ||
95 | on all of the overlays. Note that in this case the overlay input sizes must be | ||
96 | the same, but, in case of video overlays, the output size can be different. Any | ||
97 | framebuffer can be connected to any overlay. | ||
98 | |||
99 | An overlay can be connected to one overlay manager. Also DISPC overlays can be | ||
100 | connected only to DISPC overlay managers, and virtual overlays can be only | ||
101 | connected to virtual overlays. | ||
102 | |||
103 | An overlay manager can be connected to one display. There are certain | ||
104 | restrictions which kinds of displays an overlay manager can be connected: | ||
105 | |||
106 | - DISPC TV overlay manager can be only connected to TV display. | ||
107 | - Virtual overlay managers can only be connected to DBI or DSI displays. | ||
108 | - DISPC LCD overlay manager can be connected to all displays, except TV | ||
109 | display. | ||
110 | |||
111 | Sysfs | ||
112 | ----- | ||
113 | The sysfs interface is mainly used for testing. I don't think sysfs | ||
114 | interface is the best for this in the final version, but I don't quite know | ||
115 | what would be the best interfaces for these things. | ||
116 | |||
117 | The sysfs interface is divided to two parts: DSS and FB. | ||
118 | |||
119 | /sys/class/graphics/fb? directory: | ||
120 | mirror 0=off, 1=on | ||
121 | rotate Rotation 0-3 for 0, 90, 180, 270 degrees | ||
122 | rotate_type 0 = DMA rotation, 1 = VRFB rotation | ||
123 | overlays List of overlay numbers to which framebuffer pixels go | ||
124 | phys_addr Physical address of the framebuffer | ||
125 | virt_addr Virtual address of the framebuffer | ||
126 | size Size of the framebuffer | ||
127 | |||
128 | /sys/devices/platform/omapdss/overlay? directory: | ||
129 | enabled 0=off, 1=on | ||
130 | input_size width,height (ie. the framebuffer size) | ||
131 | manager Destination overlay manager name | ||
132 | name | ||
133 | output_size width,height | ||
134 | position x,y | ||
135 | screen_width width | ||
136 | global_alpha global alpha 0-255 0=transparent 255=opaque | ||
137 | |||
138 | /sys/devices/platform/omapdss/manager? directory: | ||
139 | display Destination display | ||
140 | name | ||
141 | alpha_blending_enabled 0=off, 1=on | ||
142 | trans_key_enabled 0=off, 1=on | ||
143 | trans_key_type gfx-destination, video-source | ||
144 | trans_key_value transparency color key (RGB24) | ||
145 | default_color default background color (RGB24) | ||
146 | |||
147 | /sys/devices/platform/omapdss/display? directory: | ||
148 | ctrl_name Controller name | ||
149 | mirror 0=off, 1=on | ||
150 | update_mode 0=off, 1=auto, 2=manual | ||
151 | enabled 0=off, 1=on | ||
152 | name | ||
153 | rotate Rotation 0-3 for 0, 90, 180, 270 degrees | ||
154 | timings Display timings (pixclock,xres/hfp/hbp/hsw,yres/vfp/vbp/vsw) | ||
155 | When writing, two special timings are accepted for tv-out: | ||
156 | "pal" and "ntsc" | ||
157 | panel_name | ||
158 | tear_elim Tearing elimination 0=off, 1=on | ||
159 | |||
160 | There are also some debugfs files at <debugfs>/omapdss/ which show information | ||
161 | about clocks and registers. | ||
162 | |||
163 | Examples | ||
164 | -------- | ||
165 | |||
166 | The following definitions have been made for the examples below: | ||
167 | |||
168 | ovl0=/sys/devices/platform/omapdss/overlay0 | ||
169 | ovl1=/sys/devices/platform/omapdss/overlay1 | ||
170 | ovl2=/sys/devices/platform/omapdss/overlay2 | ||
171 | |||
172 | mgr0=/sys/devices/platform/omapdss/manager0 | ||
173 | mgr1=/sys/devices/platform/omapdss/manager1 | ||
174 | |||
175 | lcd=/sys/devices/platform/omapdss/display0 | ||
176 | dvi=/sys/devices/platform/omapdss/display1 | ||
177 | tv=/sys/devices/platform/omapdss/display2 | ||
178 | |||
179 | fb0=/sys/class/graphics/fb0 | ||
180 | fb1=/sys/class/graphics/fb1 | ||
181 | fb2=/sys/class/graphics/fb2 | ||
182 | |||
183 | Default setup on OMAP3 SDP | ||
184 | -------------------------- | ||
185 | |||
186 | Here's the default setup on OMAP3 SDP board. All planes go to LCD. DVI | ||
187 | and TV-out are not in use. The columns from left to right are: | ||
188 | framebuffers, overlays, overlay managers, displays. Framebuffers are | ||
189 | handled by omapfb, and the rest by the DSS. | ||
190 | |||
191 | FB0 --- GFX -\ DVI | ||
192 | FB1 --- VID1 --+- LCD ---- LCD | ||
193 | FB2 --- VID2 -/ TV ----- TV | ||
194 | |||
195 | Example: Switch from LCD to DVI | ||
196 | ---------------------- | ||
197 | |||
198 | w=`cat $dvi/timings | cut -d "," -f 2 | cut -d "/" -f 1` | ||
199 | h=`cat $dvi/timings | cut -d "," -f 3 | cut -d "/" -f 1` | ||
200 | |||
201 | echo "0" > $lcd/enabled | ||
202 | echo "" > $mgr0/display | ||
203 | fbset -fb /dev/fb0 -xres $w -yres $h -vxres $w -vyres $h | ||
204 | # at this point you have to switch the dvi/lcd dip-switch from the omap board | ||
205 | echo "dvi" > $mgr0/display | ||
206 | echo "1" > $dvi/enabled | ||
207 | |||
208 | After this the configuration looks like: | ||
209 | |||
210 | FB0 --- GFX -\ -- DVI | ||
211 | FB1 --- VID1 --+- LCD -/ LCD | ||
212 | FB2 --- VID2 -/ TV ----- TV | ||
213 | |||
214 | Example: Clone GFX overlay to LCD and TV | ||
215 | ------------------------------- | ||
216 | |||
217 | w=`cat $tv/timings | cut -d "," -f 2 | cut -d "/" -f 1` | ||
218 | h=`cat $tv/timings | cut -d "," -f 3 | cut -d "/" -f 1` | ||
219 | |||
220 | echo "0" > $ovl0/enabled | ||
221 | echo "0" > $ovl1/enabled | ||
222 | |||
223 | echo "" > $fb1/overlays | ||
224 | echo "0,1" > $fb0/overlays | ||
225 | |||
226 | echo "$w,$h" > $ovl1/output_size | ||
227 | echo "tv" > $ovl1/manager | ||
228 | |||
229 | echo "1" > $ovl0/enabled | ||
230 | echo "1" > $ovl1/enabled | ||
231 | |||
232 | echo "1" > $tv/enabled | ||
233 | |||
234 | After this the configuration looks like (only relevant parts shown): | ||
235 | |||
236 | FB0 +-- GFX ---- LCD ---- LCD | ||
237 | \- VID1 ---- TV ---- TV | ||
238 | |||
239 | Misc notes | ||
240 | ---------- | ||
241 | |||
242 | OMAP FB allocates the framebuffer memory using the OMAP VRAM allocator. | ||
243 | |||
244 | Using DSI DPLL to generate pixel clock it is possible produce the pixel clock | ||
245 | of 86.5MHz (max possible), and with that you get 1280x1024@57 output from DVI. | ||
246 | |||
247 | Rotation and mirroring currently only supports RGB565 and RGB8888 modes. VRFB | ||
248 | does not support mirroring. | ||
249 | |||
250 | VRFB rotation requires much more memory than non-rotated framebuffer, so you | ||
251 | probably need to increase your vram setting before using VRFB rotation. Also, | ||
252 | many applications may not work with VRFB if they do not pay attention to all | ||
253 | framebuffer parameters. | ||
254 | |||
255 | Kernel boot arguments | ||
256 | --------------------- | ||
257 | |||
258 | vram=<size> | ||
259 | - Amount of total VRAM to preallocate. For example, "10M". omapfb | ||
260 | allocates memory for framebuffers from VRAM. | ||
261 | |||
262 | omapfb.mode=<display>:<mode>[,...] | ||
263 | - Default video mode for specified displays. For example, | ||
264 | "dvi:800x400MR-24@60". See drivers/video/modedb.c. | ||
265 | There are also two special modes: "pal" and "ntsc" that | ||
266 | can be used to tv out. | ||
267 | |||
268 | omapfb.vram=<fbnum>:<size>[@<physaddr>][,...] | ||
269 | - VRAM allocated for a framebuffer. Normally omapfb allocates vram | ||
270 | depending on the display size. With this you can manually allocate | ||
271 | more or define the physical address of each framebuffer. For example, | ||
272 | "1:4M" to allocate 4M for fb1. | ||
273 | |||
274 | omapfb.debug=<y|n> | ||
275 | - Enable debug printing. You have to have OMAPFB debug support enabled | ||
276 | in kernel config. | ||
277 | |||
278 | omapfb.test=<y|n> | ||
279 | - Draw test pattern to framebuffer whenever framebuffer settings change. | ||
280 | You need to have OMAPFB debug support enabled in kernel config. | ||
281 | |||
282 | omapfb.vrfb=<y|n> | ||
283 | - Use VRFB rotation for all framebuffers. | ||
284 | |||
285 | omapfb.rotate=<angle> | ||
286 | - Default rotation applied to all framebuffers. | ||
287 | 0 - 0 degree rotation | ||
288 | 1 - 90 degree rotation | ||
289 | 2 - 180 degree rotation | ||
290 | 3 - 270 degree rotation | ||
291 | |||
292 | omapfb.mirror=<y|n> | ||
293 | - Default mirror for all framebuffers. Only works with DMA rotation. | ||
294 | |||
295 | omapdss.def_disp=<display> | ||
296 | - Name of default display, to which all overlays will be connected. | ||
297 | Common examples are "lcd" or "tv". | ||
298 | |||
299 | omapdss.debug=<y|n> | ||
300 | - Enable debug printing. You have to have DSS debug support enabled in | ||
301 | kernel config. | ||
302 | |||
303 | TODO | ||
304 | ---- | ||
305 | |||
306 | DSS locking | ||
307 | |||
308 | Error checking | ||
309 | - Lots of checks are missing or implemented just as BUG() | ||
310 | |||
311 | System DMA update for DSI | ||
312 | - Can be used for RGB16 and RGB24P modes. Probably not for RGB24U (how | ||
313 | to skip the empty byte?) | ||
314 | |||
315 | OMAP1 support | ||
316 | - Not sure if needed | ||
317 | |||