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 | |||
