Documentation/arm/OMAP/DSS - kernel/msm-4.19 - Gitiles

 OMAP2/3 Display Subsystem
 -------------------------

 This is an almost total rewrite of the OMAP FB driver in drivers/video/omap
 (let's call it DSS1). The main differences between DSS1 and DSS2 are DSI,
 TV-out and multiple display support, but there are lots of small improvements
 also.

 The DSS2 driver (omapdss module) is in arch/arm/plat-omap/dss/, and the FB,
 panel and controller drivers are in drivers/video/omap2/. DSS1 and DSS2 live
 currently side by side, you can choose which one to use.

 Features
 --------

 Working and tested features include:

 - MIPI DPI (parallel) output
 - MIPI DSI output in command mode
 - MIPI DBI (RFBI) output
 - SDI output
 - TV output
 - All pieces can be compiled as a module or inside kernel
 - Use DISPC to update any of the outputs
 - Use CPU to update RFBI or DSI output
 - OMAP DISPC planes
 - RGB16, RGB24 packed, RGB24 unpacked
 - YUV2, UYVY
 - Scaling
 - Adjusting DSS FCK to find a good pixel clock
 - Use DSI DPLL to create DSS FCK

 Tested boards include:
 - OMAP3 SDP board
 - Beagle board
 - N810

 omapdss driver
 --------------

 The DSS driver does not itself have any support for Linux framebuffer, V4L or
 such like the current ones, but it has an internal kernel API that upper level
 drivers can use.

 The DSS driver models OMAP's overlays, overlay managers and displays in a
 flexible way to enable non-common multi-display configuration. In addition to
 modelling the hardware overlays, omapdss supports virtual overlays and overlay
 managers. These can be used when updating a display with CPU or system DMA.

 omapdss driver support for audio
 --------------------------------
 There exist several display technologies and standards that support audio as
 well. Hence, it is relevant to update the DSS device driver to provide an audio
 interface that may be used by an audio driver or any other driver interested in
 the functionality.

 The audio_enable function is intended to prepare the relevant
 IP for playback (e.g., enabling an audio FIFO, taking in/out of reset
 some IP, enabling companion chips, etc). It is intended to be called before
 audio_start. The audio_disable function performs the reverse operation and is
 intended to be called after audio_stop.

 While a given DSS device driver may support audio, it is possible that for
 certain configurations audio is not supported (e.g., an HDMI display using a
 VESA video timing). The audio_supported function is intended to query whether
 the current configuration of the display supports audio.

 The audio_config function is intended to configure all the relevant audio
 parameters of the display. In order to make the function independent of any
 specific DSS device driver, a struct omap_dss_audio is defined. Its purpose
 is to contain all the required parameters for audio configuration. At the
 moment, such structure contains pointers to IEC-60958 channel status word
 and CEA-861 audio infoframe structures. This should be enough to support
 HDMI and DisplayPort, as both are based on CEA-861 and IEC-60958.

 The audio_enable/disable, audio_config and audio_supported functions could be
 implemented as functions that may sleep. Hence, they should not be called
 while holding a spinlock or a readlock.

 The audio_start/audio_stop function is intended to effectively start/stop audio
 playback after the configuration has taken place. These functions are designed
 to be used in an atomic context. Hence, audio_start should return quickly and be
 called only after all the needed resources for audio playback (audio FIFOs,
 DMA channels, companion chips, etc) have been enabled to begin data transfers.
 audio_stop is designed to only stop the audio transfers. The resources used
 for playback are released using audio_disable.

 The enum omap_dss_audio_state may be used to help the implementations of
 the interface to keep track of the audio state. The initial state is _DISABLED;
 then, the state transitions to _CONFIGURED, and then, when it is ready to
 play audio, to _ENABLED. The state _PLAYING is used when the audio is being
 rendered.


 Panel and controller drivers
 ----------------------------

 The drivers implement panel or controller specific functionality and are not
 usually visible to users except through omapfb driver.  They register
 themselves to the DSS driver.

 omapfb driver
 -------------

 The omapfb driver implements arbitrary number of standard linux framebuffers.
 These framebuffers can be routed flexibly to any overlays, thus allowing very
 dynamic display architecture.

 The driver exports some omapfb specific ioctls, which are compatible with the
 ioctls in the old driver.

 The rest of the non standard features are exported via sysfs. Whether the final
 implementation will use sysfs, or ioctls, is still open.

 V4L2 drivers
 ------------

 V4L2 is being implemented in TI.

 From omapdss point of view the V4L2 drivers should be similar to framebuffer
 driver.

 Architecture
 --------------------

 Some clarification what the different components do:

     - Framebuffer is a memory area inside OMAP's SRAM/SDRAM that contains the
       pixel data for the image. Framebuffer has width and height and color
       depth.
     - Overlay defines where the pixels are read from and where they go on the
       screen. The overlay may be smaller than framebuffer, thus displaying only
       part of the framebuffer. The position of the overlay may be changed if
       the overlay is smaller than the display.
     - Overlay manager combines the overlays in to one image and feeds them to
       display.
     - Display is the actual physical display device.

 A framebuffer can be connected to multiple overlays to show the same pixel data
 on all of the overlays. Note that in this case the overlay input sizes must be
 the same, but, in case of video overlays, the output size can be different. Any
 framebuffer can be connected to any overlay.

 An overlay can be connected to one overlay manager. Also DISPC overlays can be
 connected only to DISPC overlay managers, and virtual overlays can be only
 connected to virtual overlays.

 An overlay manager can be connected to one display. There are certain
 restrictions which kinds of displays an overlay manager can be connected:

     - DISPC TV overlay manager can be only connected to TV display.
     - Virtual overlay managers can only be connected to DBI or DSI displays.
     - DISPC LCD overlay manager can be connected to all displays, except TV
       display.

 Sysfs
 -----
 The sysfs interface is mainly used for testing. I don't think sysfs
 interface is the best for this in the final version, but I don't quite know
 what would be the best interfaces for these things.

 The sysfs interface is divided to two parts: DSS and FB.

 /sys/class/graphics/fb? directory:
 mirror		0=off, 1=on
 rotate		Rotation 0-3 for 0, 90, 180, 270 degrees
 rotate_type	0 = DMA rotation, 1 = VRFB rotation
 overlays	List of overlay numbers to which framebuffer pixels go
 phys_addr	Physical address of the framebuffer
 virt_addr	Virtual address of the framebuffer
 size		Size of the framebuffer

 /sys/devices/platform/omapdss/overlay? directory:
 enabled		0=off, 1=on
 input_size	width,height (ie. the framebuffer size)
 manager		Destination overlay manager name
 name
 output_size	width,height
 position	x,y
 screen_width	width
 global_alpha   	global alpha 0-255 0=transparent 255=opaque

 /sys/devices/platform/omapdss/manager? directory:
 display				Destination display
 name
 alpha_blending_enabled		0=off, 1=on
 trans_key_enabled		0=off, 1=on
 trans_key_type			gfx-destination, video-source
 trans_key_value			transparency color key (RGB24)
 default_color			default background color (RGB24)

 /sys/devices/platform/omapdss/display? directory:
 ctrl_name	Controller name
 mirror		0=off, 1=on
 update_mode	0=off, 1=auto, 2=manual
 enabled		0=off, 1=on
 name
 rotate		Rotation 0-3 for 0, 90, 180, 270 degrees
 timings		Display timings (pixclock,xres/hfp/hbp/hsw,yres/vfp/vbp/vsw)
 		When writing, two special timings are accepted for tv-out:
 		"pal" and "ntsc"
 panel_name
 tear_elim	Tearing elimination 0=off, 1=on
 output_type	Output type (video encoder only): "composite" or "svideo"

 There are also some debugfs files at <debugfs>/omapdss/ which show information
 about clocks and registers.

 Examples
 --------

 The following definitions have been made for the examples below:

 ovl0=/sys/devices/platform/omapdss/overlay0
 ovl1=/sys/devices/platform/omapdss/overlay1
 ovl2=/sys/devices/platform/omapdss/overlay2

 mgr0=/sys/devices/platform/omapdss/manager0
 mgr1=/sys/devices/platform/omapdss/manager1

 lcd=/sys/devices/platform/omapdss/display0
 dvi=/sys/devices/platform/omapdss/display1
 tv=/sys/devices/platform/omapdss/display2

 fb0=/sys/class/graphics/fb0
 fb1=/sys/class/graphics/fb1
 fb2=/sys/class/graphics/fb2

 Default setup on OMAP3 SDP
 --------------------------

 Here's the default setup on OMAP3 SDP board. All planes go to LCD. DVI
 and TV-out are not in use. The columns from left to right are:
 framebuffers, overlays, overlay managers, displays. Framebuffers are
 handled by omapfb, and the rest by the DSS.

 FB0 --- GFX  -\            DVI
 FB1 --- VID1 --+- LCD ---- LCD
 FB2 --- VID2 -/   TV ----- TV

 Example: Switch from LCD to DVI
 ----------------------

 w=`cat $dvi/timings | cut -d "," -f 2 | cut -d "/" -f 1`
 h=`cat $dvi/timings | cut -d "," -f 3 | cut -d "/" -f 1`

 echo "0" > $lcd/enabled
 echo "" > $mgr0/display
 fbset -fb /dev/fb0 -xres $w -yres $h -vxres $w -vyres $h
 # at this point you have to switch the dvi/lcd dip-switch from the omap board
 echo "dvi" > $mgr0/display
 echo "1" > $dvi/enabled

 After this the configuration looks like:

 FB0 --- GFX  -\         -- DVI
 FB1 --- VID1 --+- LCD -/   LCD
 FB2 --- VID2 -/   TV ----- TV

 Example: Clone GFX overlay to LCD and TV
 -------------------------------

 w=`cat $tv/timings | cut -d "," -f 2 | cut -d "/" -f 1`
 h=`cat $tv/timings | cut -d "," -f 3 | cut -d "/" -f 1`

 echo "0" > $ovl0/enabled
 echo "0" > $ovl1/enabled

 echo "" > $fb1/overlays
 echo "0,1" > $fb0/overlays

 echo "$w,$h" > $ovl1/output_size
 echo "tv" > $ovl1/manager

 echo "1" > $ovl0/enabled
 echo "1" > $ovl1/enabled

 echo "1" > $tv/enabled

 After this the configuration looks like (only relevant parts shown):

 FB0 +-- GFX  ---- LCD ---- LCD
      \- VID1 ---- TV  ---- TV

 Misc notes
 ----------

 OMAP FB allocates the framebuffer memory using the OMAP VRAM allocator.

 Using DSI DPLL to generate pixel clock it is possible produce the pixel clock
 of 86.5MHz (max possible), and with that you get 1280x1024@57 output from DVI.

 Rotation and mirroring currently only supports RGB565 and RGB8888 modes. VRFB
 does not support mirroring.

 VRFB rotation requires much more memory than non-rotated framebuffer, so you
 probably need to increase your vram setting before using VRFB rotation. Also,
 many applications may not work with VRFB if they do not pay attention to all
 framebuffer parameters.

 Kernel boot arguments
 ---------------------

 vram=<size>[,<physaddr>]
 	- Amount of total VRAM to preallocate and optionally a physical start
 	  memory address. For example, "10M". omapfb allocates memory for
 	  framebuffers from VRAM.

 omapfb.mode=<display>:<mode>[,...]
 	- Default video mode for specified displays. For example,
 	  "dvi:800x400MR-24@60".  See drivers/video/modedb.c.
 	  There are also two special modes: "pal" and "ntsc" that
 	  can be used to tv out.

 omapfb.vram=<fbnum>:<size>[@<physaddr>][,...]
 	- VRAM allocated for a framebuffer. Normally omapfb allocates vram
 	  depending on the display size. With this you can manually allocate
 	  more or define the physical address of each framebuffer. For example,
 	  "1:4M" to allocate 4M for fb1.

 omapfb.debug=<y|n>
 	- Enable debug printing. You have to have OMAPFB debug support enabled
 	  in kernel config.

 omapfb.test=<y|n>
 	- Draw test pattern to framebuffer whenever framebuffer settings change.
 	  You need to have OMAPFB debug support enabled in kernel config.

 omapfb.vrfb=<y|n>
 	- Use VRFB rotation for all framebuffers.

 omapfb.rotate=<angle>
 	- Default rotation applied to all framebuffers.
 	  0 - 0 degree rotation
 	  1 - 90 degree rotation
 	  2 - 180 degree rotation
 	  3 - 270 degree rotation

 omapfb.mirror=<y|n>
 	- Default mirror for all framebuffers. Only works with DMA rotation.

 omapdss.def_disp=<display>
 	- Name of default display, to which all overlays will be connected.
 	  Common examples are "lcd" or "tv".

 omapdss.debug=<y|n>
 	- Enable debug printing. You have to have DSS debug support enabled in
 	  kernel config.

 TODO
 ----

 DSS locking

 Error checking
 - Lots of checks are missing or implemented just as BUG()

 System DMA update for DSI
 - Can be used for RGB16 and RGB24P modes. Probably not for RGB24U (how
   to skip the empty byte?)

 OMAP1 support
 - Not sure if needed
	OMAP2/3 Display Subsystem
	-------------------------

	This is an almost total rewrite of the OMAP FB driver in drivers/video/omap
	(let's call it DSS1). The main differences between DSS1 and DSS2 are DSI,
	TV-out and multiple display support, but there are lots of small improvements
	also.

	The DSS2 driver (omapdss module) is in arch/arm/plat-omap/dss/, and the FB,
	panel and controller drivers are in drivers/video/omap2/. DSS1 and DSS2 live
	currently side by side, you can choose which one to use.

	Features
	--------

	Working and tested features include:

	- MIPI DPI (parallel) output
	- MIPI DSI output in command mode
	- MIPI DBI (RFBI) output
	- SDI output
	- TV output
	- All pieces can be compiled as a module or inside kernel
	- Use DISPC to update any of the outputs
	- Use CPU to update RFBI or DSI output
	- OMAP DISPC planes
	- RGB16, RGB24 packed, RGB24 unpacked
	- YUV2, UYVY
	- Scaling
	- Adjusting DSS FCK to find a good pixel clock
	- Use DSI DPLL to create DSS FCK

	Tested boards include:
	- OMAP3 SDP board
	- Beagle board
	- N810

	omapdss driver
	--------------

	The DSS driver does not itself have any support for Linux framebuffer, V4L or
	such like the current ones, but it has an internal kernel API that upper level
	drivers can use.

	The DSS driver models OMAP's overlays, overlay managers and displays in a
	flexible way to enable non-common multi-display configuration. In addition to
	modelling the hardware overlays, omapdss supports virtual overlays and overlay
	managers. These can be used when updating a display with CPU or system DMA.

	omapdss driver support for audio
	--------------------------------
	There exist several display technologies and standards that support audio as
	well. Hence, it is relevant to update the DSS device driver to provide an audio
	interface that may be used by an audio driver or any other driver interested in
	the functionality.

	The audio_enable function is intended to prepare the relevant
	IP for playback (e.g., enabling an audio FIFO, taking in/out of reset
	some IP, enabling companion chips, etc). It is intended to be called before
	audio_start. The audio_disable function performs the reverse operation and is
	intended to be called after audio_stop.

	While a given DSS device driver may support audio, it is possible that for
	certain configurations audio is not supported (e.g., an HDMI display using a
	VESA video timing). The audio_supported function is intended to query whether
	the current configuration of the display supports audio.

	The audio_config function is intended to configure all the relevant audio
	parameters of the display. In order to make the function independent of any
	specific DSS device driver, a struct omap_dss_audio is defined. Its purpose
	is to contain all the required parameters for audio configuration. At the
	moment, such structure contains pointers to IEC-60958 channel status word
	and CEA-861 audio infoframe structures. This should be enough to support
	HDMI and DisplayPort, as both are based on CEA-861 and IEC-60958.

	The audio_enable/disable, audio_config and audio_supported functions could be
	implemented as functions that may sleep. Hence, they should not be called
	while holding a spinlock or a readlock.

	The audio_start/audio_stop function is intended to effectively start/stop audio
	playback after the configuration has taken place. These functions are designed
	to be used in an atomic context. Hence, audio_start should return quickly and be
	called only after all the needed resources for audio playback (audio FIFOs,
	DMA channels, companion chips, etc) have been enabled to begin data transfers.
	audio_stop is designed to only stop the audio transfers. The resources used
	for playback are released using audio_disable.

	The enum omap_dss_audio_state may be used to help the implementations of
	the interface to keep track of the audio state. The initial state is _DISABLED;
	then, the state transitions to _CONFIGURED, and then, when it is ready to
	play audio, to _ENABLED. The state _PLAYING is used when the audio is being
	rendered.


	Panel and controller drivers
	----------------------------

	The drivers implement panel or controller specific functionality and are not
	usually visible to users except through omapfb driver. They register
	themselves to the DSS driver.

	omapfb driver
	-------------

	The omapfb driver implements arbitrary number of standard linux framebuffers.
	These framebuffers can be routed flexibly to any overlays, thus allowing very
	dynamic display architecture.

	The driver exports some omapfb specific ioctls, which are compatible with the
	ioctls in the old driver.

	The rest of the non standard features are exported via sysfs. Whether the final
	implementation will use sysfs, or ioctls, is still open.

	V4L2 drivers
	------------

	V4L2 is being implemented in TI.

	From omapdss point of view the V4L2 drivers should be similar to framebuffer
	driver.

	Architecture
	--------------------

	Some clarification what the different components do:

	- Framebuffer is a memory area inside OMAP's SRAM/SDRAM that contains the
	pixel data for the image. Framebuffer has width and height and color
	depth.
	- Overlay defines where the pixels are read from and where they go on the
	screen. The overlay may be smaller than framebuffer, thus displaying only
	part of the framebuffer. The position of the overlay may be changed if
	the overlay is smaller than the display.
	- Overlay manager combines the overlays in to one image and feeds them to
	display.
	- Display is the actual physical display device.

	A framebuffer can be connected to multiple overlays to show the same pixel data
	on all of the overlays. Note that in this case the overlay input sizes must be
	the same, but, in case of video overlays, the output size can be different. Any
	framebuffer can be connected to any overlay.

	An overlay can be connected to one overlay manager. Also DISPC overlays can be
	connected only to DISPC overlay managers, and virtual overlays can be only
	connected to virtual overlays.

	An overlay manager can be connected to one display. There are certain
	restrictions which kinds of displays an overlay manager can be connected:

	- DISPC TV overlay manager can be only connected to TV display.
	- Virtual overlay managers can only be connected to DBI or DSI displays.
	- DISPC LCD overlay manager can be connected to all displays, except TV
	display.

	Sysfs
	-----
	The sysfs interface is mainly used for testing. I don't think sysfs
	interface is the best for this in the final version, but I don't quite know
	what would be the best interfaces for these things.

	The sysfs interface is divided to two parts: DSS and FB.

	/sys/class/graphics/fb? directory:
	mirror 0=off, 1=on
	rotate Rotation 0-3 for 0, 90, 180, 270 degrees
	rotate_type 0 = DMA rotation, 1 = VRFB rotation
	overlays List of overlay numbers to which framebuffer pixels go
	phys_addr Physical address of the framebuffer
	virt_addr Virtual address of the framebuffer
	size Size of the framebuffer

	/sys/devices/platform/omapdss/overlay? directory:
	enabled 0=off, 1=on
	input_size width,height (ie. the framebuffer size)
	manager Destination overlay manager name
	name
	output_size width,height
	position x,y
	screen_width width
	global_alpha global alpha 0-255 0=transparent 255=opaque

	/sys/devices/platform/omapdss/manager? directory:
	display Destination display
	name
	alpha_blending_enabled 0=off, 1=on
	trans_key_enabled 0=off, 1=on
	trans_key_type gfx-destination, video-source
	trans_key_value transparency color key (RGB24)
	default_color default background color (RGB24)

	/sys/devices/platform/omapdss/display? directory:
	ctrl_name Controller name
	mirror 0=off, 1=on
	update_mode 0=off, 1=auto, 2=manual
	enabled 0=off, 1=on
	name
	rotate Rotation 0-3 for 0, 90, 180, 270 degrees
	timings Display timings (pixclock,xres/hfp/hbp/hsw,yres/vfp/vbp/vsw)
	When writing, two special timings are accepted for tv-out:
	"pal" and "ntsc"
	panel_name
	tear_elim Tearing elimination 0=off, 1=on
	output_type Output type (video encoder only): "composite" or "svideo"

	There are also some debugfs files at <debugfs>/omapdss/ which show information
	about clocks and registers.

	Examples
	--------

	The following definitions have been made for the examples below:

	ovl0=/sys/devices/platform/omapdss/overlay0
	ovl1=/sys/devices/platform/omapdss/overlay1
	ovl2=/sys/devices/platform/omapdss/overlay2

	mgr0=/sys/devices/platform/omapdss/manager0
	mgr1=/sys/devices/platform/omapdss/manager1

	lcd=/sys/devices/platform/omapdss/display0
	dvi=/sys/devices/platform/omapdss/display1
	tv=/sys/devices/platform/omapdss/display2

	fb0=/sys/class/graphics/fb0
	fb1=/sys/class/graphics/fb1
	fb2=/sys/class/graphics/fb2

	Default setup on OMAP3 SDP
	--------------------------

	Here's the default setup on OMAP3 SDP board. All planes go to LCD. DVI
	and TV-out are not in use. The columns from left to right are:
	framebuffers, overlays, overlay managers, displays. Framebuffers are
	handled by omapfb, and the rest by the DSS.

	FB0 --- GFX -\ DVI
	FB1 --- VID1 --+- LCD ---- LCD
	FB2 --- VID2 -/ TV ----- TV

	Example: Switch from LCD to DVI
	----------------------

	w=`cat $dvi/timings \| cut -d "," -f 2 \| cut -d "/" -f 1`
	h=`cat $dvi/timings \| cut -d "," -f 3 \| cut -d "/" -f 1`

	echo "0" > $lcd/enabled
	echo "" > $mgr0/display
	fbset -fb /dev/fb0 -xres $w -yres $h -vxres $w -vyres $h
	# at this point you have to switch the dvi/lcd dip-switch from the omap board
	echo "dvi" > $mgr0/display
	echo "1" > $dvi/enabled

	After this the configuration looks like:

	FB0 --- GFX -\ -- DVI
	FB1 --- VID1 --+- LCD -/ LCD
	FB2 --- VID2 -/ TV ----- TV

	Example: Clone GFX overlay to LCD and TV
	-------------------------------

	w=`cat $tv/timings \| cut -d "," -f 2 \| cut -d "/" -f 1`
	h=`cat $tv/timings \| cut -d "," -f 3 \| cut -d "/" -f 1`

	echo "0" > $ovl0/enabled
	echo "0" > $ovl1/enabled

	echo "" > $fb1/overlays
	echo "0,1" > $fb0/overlays

	echo "$w,$h" > $ovl1/output_size
	echo "tv" > $ovl1/manager

	echo "1" > $ovl0/enabled
	echo "1" > $ovl1/enabled

	echo "1" > $tv/enabled

	After this the configuration looks like (only relevant parts shown):

	FB0 +-- GFX ---- LCD ---- LCD
	\- VID1 ---- TV ---- TV

	Misc notes
	----------

	OMAP FB allocates the framebuffer memory using the OMAP VRAM allocator.

	Using DSI DPLL to generate pixel clock it is possible produce the pixel clock
	of 86.5MHz (max possible), and with that you get 1280x1024@57 output from DVI.

	Rotation and mirroring currently only supports RGB565 and RGB8888 modes. VRFB
	does not support mirroring.

	VRFB rotation requires much more memory than non-rotated framebuffer, so you
	probably need to increase your vram setting before using VRFB rotation. Also,
	many applications may not work with VRFB if they do not pay attention to all
	framebuffer parameters.

	Kernel boot arguments
	---------------------

	vram=<size>[,<physaddr>]
	- Amount of total VRAM to preallocate and optionally a physical start
	memory address. For example, "10M". omapfb allocates memory for
	framebuffers from VRAM.

	omapfb.mode=<display>:<mode>[,...]
	- Default video mode for specified displays. For example,
	"dvi:800x400MR-24@60". See drivers/video/modedb.c.
	There are also two special modes: "pal" and "ntsc" that
	can be used to tv out.

	omapfb.vram=<fbnum>:<size>[@<physaddr>][,...]
	- VRAM allocated for a framebuffer. Normally omapfb allocates vram
	depending on the display size. With this you can manually allocate
	more or define the physical address of each framebuffer. For example,
	"1:4M" to allocate 4M for fb1.

	omapfb.debug=<y\|n>
	- Enable debug printing. You have to have OMAPFB debug support enabled
	in kernel config.

	omapfb.test=<y\|n>
	- Draw test pattern to framebuffer whenever framebuffer settings change.
	You need to have OMAPFB debug support enabled in kernel config.

	omapfb.vrfb=<y\|n>
	- Use VRFB rotation for all framebuffers.

	omapfb.rotate=<angle>
	- Default rotation applied to all framebuffers.
	0 - 0 degree rotation
	1 - 90 degree rotation
	2 - 180 degree rotation
	3 - 270 degree rotation

	omapfb.mirror=<y\|n>
	- Default mirror for all framebuffers. Only works with DMA rotation.

	omapdss.def_disp=<display>
	- Name of default display, to which all overlays will be connected.
	Common examples are "lcd" or "tv".

	omapdss.debug=<y\|n>
	- Enable debug printing. You have to have DSS debug support enabled in
	kernel config.

	TODO
	----

	DSS locking

	Error checking
	- Lots of checks are missing or implemented just as BUG()

	System DMA update for DSI
	- Can be used for RGB16 and RGB24P modes. Probably not for RGB24U (how
	to skip the empty byte?)

	OMAP1 support
	- Not sure if needed