Contents[hide]Introduction- This page gives a basic description of DSS hardware, the linux kernel drivers which implement it, how to build the drivers as modules or built-in, and how one can test and use the drivers. - The drivers described here are omapdss, omapdrm and omapfb. - The guide applies to both 3.12 and the current mainline kernel. DRA7x and ARM437x is missing in the mainline kernel though. - For a generic linux kernel guide, try: http://processors.wiki./index.php/Linux_Kernel_Users_Guide Supported DevicesDRA7x evm, AM437x evm, OMAP5 uevm, OMAP4 Panda. Driver FeaturesSupported FeaturesomapdrmDRM Plane Features:
DRM CRTC Features:
DRM Interfaces: HDMI Interface
RGB Interface
omapfb- standard FB ioctls supported - custom ioctls like OMAPFB_SYNC_GFX, OMAPFB_UPDATE_WINDOW, OMAPFB_SETUP_PLANE, OMAPFB_QUERY_PLANE and OMAPFB_SET_UPDATE_MODE(see include/uapi/linux/omapfb.h for all the custom OMAPFB ioctls) - Support for both auto and manual update displays. Changes from 3.12 to 3.15
- omap4 hdmi driver re-ordering done to simplify addition of omap5 hdmi. - misc fixes: de_level, topolly panel driver, dvi i2c related.
- add dedicated fck PLL support. - omapdrm deferred probe, and module insertion/removal fixes. - misc fixes: omap3 scaling, omap4+ dispc preloading, dispc context restore Unsupported Features/Limitations
Hardware ArchitectureThe Display Subsystem (DSS) is a hardware block responsible for fetching video and graphic images from memory, and display it on to a LCD or TV setup through various standard interfaces. It sounds like a simple block, but it actually isn't (consider looking at TRM for more details). DSS hardware has 2 major sub-blocks: DISPC and the encoders. In addition to the SoC's DSS, boards often contain external encoders (for example, DPI to DVI encoder) and display panels.  An overview of the DSS hardware. The arrows show how ovlerlays/pipelines are connected to overlay managers, which are further connected to encoders, which finally create an encoded pixel stream for display on to LCD or TV. The different colors of the blocks show the new sub-blocks added in subsequent DSS revisions 1. Display Controller(DISPC)DISPC is the block which is responsible of fetching image buffers from the memory through DMA pipelines, and then create a pixel stream for the encoder. The pixel stream comprises of a composition of one or more image layers which we finally want to present on the display. DISPC can be split into 2 major sub-blocks: 1. OverlaysOverlays (or Pipelines or DMA channels) consist of the HW block which perform DMA to fetch image pixels (of different color formats) from RAM. Besides performing DMA, overlays perform other functions like replication, ARGB expansion, scaling, color conversion, VC1 range mapping on the input pixels before it's passed on to the overlay manager. An overlay manager recieves pixel data from one or more such pipelines, and performs the task of composing them and passing it on to the encoder. There are 2 different types of overlays: Graphic overlays: These overlays are capable of fetching RGB color formats, and also bitmap formats through LUTs. They don't support scaling or color conversion and are generally intended to display a layer renderded by a GPU according to the size of the display.
Color formats supported: BITMAP 1-bpp, BITMAP 2-bpp, BITMAP 4-bpp, BITMAP 8-bpp, xRGB12-4444, RGBx12-4444, ARGB16-4444, RGBA16-4444, RGB16-565, xRGB16-1555, ARGB16-1555, xRGB24-8888, RGBx24-8888, RGB24-888, ARGB32-8888, RGBA32-8888, BGRA32-8888. Video overlays: These overlays are capable of fetching RGB and YUV color formats. They support scaling and color conversion. They are intended for displaying video content coming from a decoder block. Color formats supported: The RGB formats as above, UYUV4:2:2, YUV2 4:2:2, YUV4:2:0 – NV12, YUV4:2:0 – NV21 (NV12/NV21 isn't supported in older DSS revisions). The number of overlays within DSS varies with the DSS revision used in the SoC. Below is the information for the following SoCs: OMAP2/3/AM437x: One Graphics (GFX) and Two Video overlays (VID1, VID2). OMAP4/5/DRA7x: One Graphics (GFX) and Three Video overlays (VID1, VID2, and VID3). 2. Overlay Managers (Compositors and timing generators):Overlay managers are the blocks which take ARGB image content from one or more overlays, layer them to form a compositionm, and create a pixel stream with the timings as per required by the encoder/panel. It has 2 functions: Compositor: These take ARGB data from multiple overlays, composing them on the basis of their position with respect to the complete overlay manager size. Tasks like alpha blending, color-keying, z-order and color phase rotation, dithering are also performed by the compositor in the overlay manager. Timing generator: This part of the overlay manager is responsible of providing the pixel stream generated by the compositor above according to the timings desired by the encoder or the panel. The timing generator is a state machine which provides RGB data along with control signals like pixel clock, hsync, vsync, data enable. This timing info is used by the encoder/panel to display the composited frame on the screen. There are 2 types of overlay managers: LCD managers: These are primarily used for encoders like DPI, DSI and RFBI and which connect to LCD panels. The timing generator derives its pixel clock from either the DSS functional clock, or a PLL within the DSS. TV managers: These are primarily used for encoders like HDMI and VENC which connect to TV and monitors. The timing generator derives gets the pixel clock from the connected encoder. The number of overlay managers within DSS varies with the DSS revision used in the SoC. Below is the information for the following SoCs: OMAP2/3/AM437x: One LCD manager (LCD) and One TV manager (TV) OMAP4: 2 LCD managers (LCD1, LCD2) and One TV manager (TV) OMAP5/DRA7x: 3 LCD managers (LCD1, LCD2, LCD3) and One TV manager (TV) 2. Display Encoders (or interfaces)These form the 2nd component of DSS. They take a pixel stream from an overlay manager, and encode it into a standard which is understood by the LCD panel/monitor. These standards are specified by MIPI or general video/display bodies. MIPI DPI encoder: This is the simplest encoder, it passes the overlay manager video port output (consisting of RGB data lines and control signals) directly to SoC pins. The number of RGB data lines used is configurable, and is set on the basis of the color depth supported by the LCD panel. HDMI encoder: This adapts the HDMI spec. It consists of a CORE block which implements the HDMI protocol, a PLL block which provides the clock required for the pixel clock and HDMI TMDS lines, and a PHY block which encodes the pixels and data into the TMDS format. MIPI DSI encoder: This encoder takes parallel RGB data from an overlay manager video port, and encodes it into a serial format. It consists of the Protocol engine which implements the MIPI DSI spec to create serial data, and command information, a PLL block which provides clocks to the overlay manager, protocol engine and the PHY, a DSI PHY block which follows the MIPI D-PHY spec, this uses a LVDS like protocol to transmit serial data to the DSI display. DSI supports 2 modes, command and video modes. More info can be found in the TRM. MIPI DBI/RFBI encoder: This encoder transmits data to a panel without any timing generation info. The panel is expected to have an internal buffer which it displays on to the LCD using it's own timing generator. VENC encoder: This encoder converts digital pixel data into a composite or s-video analog output supporting the NTSC and PAL standards. It's hardly used these days. The number and type of encoders within DSS varies with the DSS revision used in the SoC. These are the encoders present in the following SoCs: OMAP2: DPI, RFBI and VENC. OMAP3430: DPI, RFBI, VENC, SDI. OMAP3630: DPI, RFBI, VENC, DSI. OMAP4430: DPI, 2 DSIs, RFBI, VENC and HDMI. OMAP4460/OMAP5: DPI, 2 DSIs, RFBI and HDMI. DRA7xx: 3 DPIs, RFBI and HDMI. Driver ArchitectureThe driver for the DSS IP is omapdss. The drivers to implement framebuffer and DRM/KMS devices are omapfb and omapdrm respectively. omapfb or omapdrm internally use omapdss api to configure DSS. DSS Documentation in the kernel source can be found here: Documentation/arm/OMAP/DSS omapdssomapdss comprises of a collection of platform drivers which represent the DSS IP (DISPC and encoders), and an interface to panel drivers. It enumerates the entities: overlays, overlay managers, outputs and displays. These entities have corresponding ops and helper funcs which a higher layer driver can use to configure the DSS hardware. The current users of omapdss are omapfb, omap_vout and omapdrm. When used by omapfb/omap_vout, the omapdss driver is configured in a compatibility mode. omapdss controls both the Panel/Encoder and DISPC hardware using a layer called APPLY, which makes sure that the user's request are aligned with VSYNCS. When used by omapdrm, the ompadss driver is configured in a mode where it only configures the Panel and Encoder hardware. DISPC configuration exists in the omapdrm driver.
omapfbomapfb implements Linux fbdev framebuffer for DSS. An important thing to note is that compared to simpler display hardware solutions where a framebuffer matches a display (which is the case for which fbdev was originally designed), omapfb models overlays with framebuffers. By default, GFX overlay is fb0, VID1/2 overlays are fb1/2. This means that changing the size of an fb changes the size of an overlay (whereas with more conventional cases changing fb size changes the video resolution). omapfb has a bunch of custom ioctls to control DSS specific features. See include/uapi/linux/omapfb.h for the details, and http://git./display/omapfb-tests for examples. omapdrmomapdrm is the DRM kernel driver for DSS. It's not a standalone driver, it requires the omapdss module to function. The mapping of DRM entities to DSS hardware and panels is as follows: drm_plane -> DSS pipeline/overlay drm_crtc -> DSS overlay manager drm_encoder -> Display drm_connector -> " The omapdrm driver directly configures the DISPC registers. Whereas, omapdss configures the panel and the endocer IP(HDMI/DSI etc).This is the reason why DRM encoders and connectors are represented by omap_dss_device panel entities. The encoder and panel are internally configured by omapdss through display and encoder drivers. There is per-crtc worker thread. This takes in modeset and pageflip requests from user space. It collects these requests for the overlay manager corresponding to the crtc, the default pipeline connected to crtc, and extra pipelines(a drmModeSetPlane call) connected to the overlay manager. These are queued in a work queue at the time of a vblank, that's when a new configuration can be programmed into DISPC shadow registers. Somt of the comments in 'drivers/gpu/drm/omapdrm/omap_drv.h' are useful to understand the mechanism omapdrm uses to apply configurations. Driver ConfigurationSource Location
drivers/video/omap2/dss/
drivers/video/omap2/displays-new
drivers/video/omap2/omapfb
drivers/gpu/drm/omapdrm/ Kernel Configuration OptionsKernel config(built-in)With omapfb
$ make ARCH=arm menuconfig
... ... Kernel Features ---> Boot options ---> CPU Power Management ---> Floating point emulation ---> Userspace binary formats ---> Power management options ---> [*] Networking support ---> Device Drivers ---> ... ...
... ... [ ] ARM Versatile Express platform infrastructure -*- Voltage and Current Regulator Support ---> <M> Multimedia support ---> Graphics support ---> <M> Sound card support ---> ... ...
... ... < > Direct Rendering Manager (XFree86 4.1.0 and higher DRI support) ----> < > Lowlevel video output switch controls <*> Support for frame buffer devices ---> <*> OMAP2+ Display Subsystem support ---> [ ] Exynos Video driver support ----> [*] Backlight & LCD device support ---> Console display driver support ---> [*] Bootup logo ---> ...
--- OMAP2+ Display Subsystem support
[ ] Debug support
[ ] Debugfs filesystem support
[*] DPI support
[*] DRA75X DPI support
[*] VENC support
[*] HDMI support
[*] OMAP5 HDMI support
[*] SDI support
[*] DSI support
(0) Minimum FCK/PCK ratio (for scaling)
[*] Sleep 20ms after VENC reset
<*> OMAP2+ frame buffer support --->
OMAP Display Device Drivers (new device model) --->
<*> TFP410 DPI to DVI Encoder <*> TPD12S015 HDMI ESD protection and level shifter <*> TPD12S015 HDMI ESD protection and level shifter on DRA7 EVM <*> Sil9022 DPI to HDMI Encoder <*> DVI Connector <*> HDMI Connector <*> Analog TV Connector <*> Generic DPI panel <*> Generic DSI Command Mode Panel <*> ACX565AKM Panel <*> LG.Philips LB035Q02 LCD Panel <*> Sharp LS037V7DW01 LCD Panel <*> TPO TD043MTEA1 LCD Panel <*> NEC NL8048HL11 Panel <*> Three Five DPI panel
With omapdrm
[*] VGA Arbitration
(16) Maximum number of GPUs
<*> Direct Rendering Manager (XFree86 4.1.0 and higher DRI support) --->
I2C encoder or helper chips --->
< > 3dfx Banshee/Voodoo3+ (NEW)
...
...
< > DRM Support for R-Car Display Unit (NEW)
< > DRM Support for SH Mobile (NEW)
<*> OMAP DRM
(2) Number of CRTCs
< > DRM Support for TI LCDC Display Controller (NEW)
< > QXL virtual GPU (NEW)
< > Lowlevel video output switch controls
-*- Support for frame buffer devices --->
<*> OMAP2+ Display Subsystem support --->
[ ] Exynos Video driver support ----
[*] Backlight & LCD device support --->
Console display driver support --->
...
...
--- OMAP2+ Display Subsystem support
[ ] Debug support
[ ] Debugfs filesystem support
[*] DPI support
[*] DRA75X DPI support
[*] VENC support
[*] HDMI support
[*] OMAP5 HDMI support
[*] SDI support
[*] DSI support
(0) Minimum FCK/PCK ratio (for scaling)
[*] Sleep 20ms after VENC reset
OMAP Display Device Drivers (new device model) --->
Kernel config(modules)With omapfbBuilding omapfb as modules is similar to building it as built-in. With omapdrmBuilding omapdrm as modules is similar to building it as built-in. Driver UsageLoading ModulesLoading omapfbinsmod cfbcopyarea.ko isnmod cfbfillrect.ko insmod cfbimgblt.ko insmod omapdss.ko # these are panel and encoder driver modules for pandaboard, you might want to put your desired modules here insmod encoder-tpd12s015.ko insmod connector-hdmi.ko insmod encoder-tfp410.ko insmod connector-dvi.ko # and finally, insert omapfb insmod omapfb.ko Loading omapdrminsmod drm.ko insmod drm_kms_helper.ko insmod fb_sys_fops.ko insmod syscopyarea.ko insmod sysimgblt.ko insmod sysfillrect.ko insmod omapdss.ko # these are panel and encoder driver modules for pandaboard, you might want to put your desired modules here insmod encoder-tpd12s015.ko insmod connector-hdmi.ko insmod encoder-tfp410.ko insmod connector-dvi.ko # and finally, insert omapdrm insmod omapdrm.ko Using omapdssThrough omapfbomapfb functionality can be tested by any fb based test applications. Booting up the kernel with a boot logo, or using the framebuffer console are the simplest options. You can push a "test image" from /dev/urandom to fb: cat /dev/urandom > /dev/fb0 And you can also save the current data from fb to study on your PC: cat /dev/fb0 > file.raw Framebuffer properties can be seen and modified through the sysfs attributes in: /sys/class/graphics/fb0/ There are some sysfs attributes which are specific to omapfb. For example, the arrtibute "overlays" can be used to assign the DSS overlays to a frambuffer device:
echo "0" > /sys/class/graphics/fb0/overlays
echo "1" > /sys/class/graphics/fb0/overlays
echo "0,1" > /sys/class/graphics/fb0/overlays
echo "" > /sys/class/graphics/fb0/overlays In order to boout up with a specific mode, the following omapfb bootarg can be used: omapfb.mode=<xres>x<yres>[M][R][-<bpp>][@<refresh>][i][m] or <name>[-<bpp>][@<refresh>] More info available in the following kernel documentation: Documentation/fb/modedb.txt Documentation/arm/OMAP/DSS A test suite maintained to test omapfb can be found here: http://git./display/omapfb-tests Some useful tests from the suite are:
Through omapdrmUser space applications abstract DRM/KMS ioctls through the libdrm library. libdrm also provides the modetest utility which can be used to view the state of differnt DRM entities(planes, crtcs, encoders and connectors) and the connections between them. libdrm can be taken from: git://anongit.freedesktop.org/git/mesa/drm Build instructions(assuming dependencies are met with): ./autogen.sh --disable-intel --disable-radeon --disable-nouveau --disable-vmwgfx --enable-omap-experimental-api make install Modetest without any arguments gives a state of the Modetest can be used to show a pattern on a connector. It can also be used to connect a plane to a crtc. Use the following instruction to get specific details: ./tests/modetest/modetest --help Another repository to test omapdrm is the omapdrm available here: git://github.com/robclark/omapdrmtest.git Build instructions: ./autogen.sh --disable-x11 make install There are a few testcases available in the repo: fliptest, dmabuftest, viddec3test, kmscube. Apart from fliptest, all the other testcases require some other module to be enabled. fliptest performs page flips on a particular crtc, and displays a pattern filled to the buffer by the CPU. The following extecutes fliptest on the given connector, with the provided mode: ./fliptest -s connector-id[@crtc-id]:mode The option '-t' allows us to use Tiled 2D buffers: ./fliptest [-t <container_type>] -s connector-id[@crtc-id]:mode container_type can be 8, 16, 32 and auto SOC specific InformationThe below section provides details on Soc specific DSS limitation and features. Any specific test changes or shortcomings are also documented. AM437xFeatures & LimitationsDSS on AM437x has 3 pipelines - 1 GFX and 2 Video pipelines. The DSS IP which is re use of OMAP3 DSS supporting DPI, RFBI and VENC. But on AM437x we only use DPI. HDMI support is added via an external chip. On the development board, we use DPI-LCD panel of resolution 800 x 480. The LCD panel is 7 inch touch panel (osd057T0559-34TS) from osd displays. Silicon Image's Sii9022 is the DPI to HDMI converter available on board. Though the external chip supports 1080p on AM437x due to inherent limitation of DSS IP we support a maximum of 720p@60 fps. On the platform there is a GPIO provided to switch between LCD and HDMI. Default settings are to provide data and clock to LCD. If HDMI is to be used, the Gpio has to move to LOW (0). More on Gpio usage can be read in How to test HDMI section. More information on DSS can be found in AM437x TRM and for more info on Sii9022, contact Silicon Image. How to test LCD on AM437xLCD is the default display on AM437x.In the Display Device Drivers menu (see section on built in), select Generic DPI panel. With this the LCD will be up and you can test it out. Note that the backlight for LCD is through pwm backlight. Refer the corresponsing driver document for backlight manipulation. How to test HDMI on AM437xHDMI support on AM437x is through external chip - Sii9022. Hence to use HDMI, in Display Device Drivers menu (see section on built in), select connector HDMI and Sil9022 DPI to HDMI Encoder. The Gpio to toggle from LCD to HDMI is part of the Sii9022 driver and hence no manual gpio modification is necessary. Refer the device tree node if GPIO number and other details are required. Since LCD is default display on Am437x, to use HDMI, add the below string to the boot arg - works only for OMAPFB. omapdss.def_disp=display1 This ensures HDMI is selected over LCD. Also the below bootarg we can provide the required resolution as well. Eg: for 720p60: omapdss.def_disp=display1 omapfb.mode=display1:1280x720MR-24@60 Refer OMAPFB section for details on different modes to use.
- display0 = &lcd0;
- display1 = &hdmi0;
+ display0 = &hdmi0;
+ display1 = &lcd0;
NOTE: Since the same DPI lines are used for both LCD and HDMI, currently we can only statically choose the display at boot time. HDMI Audio and HDMI Hot plug is not supported yet. DRA7The DSS IP on DRA7xx is a derivative of the DSS IP in OMAP5. The DSI protocol and PHY blocks are removed. 2 more DPI interfaces are added. HDMI is as it was on OMAP5. On the Vayu EVM, DSS interfaces are connected as follows: DPI1/VOUT1 -> TFCS 9700 7" LCD panel(connected via a daughter card, TLC59108 chip on the daughter card provides GPIOs for backlight and power control ). DPI2/VOUT2 -> Unused. DPI3/VOUT3 -> FPD Link(panel to be connected to a serializer/de-serializer board via FPDLink cable). HDMI -> HDMI level shifter and connector. When building the kernel or modules. Set the following config options to enable DRA7x outputs: CONFIG_OMAP2_DSS_DRA7XX_DPI CONFIG_OMAP5_DSS_HDMI (Found in Device Drivers -> Graphics support -> OMAP2+ Display Subsystem support ->) Set the following config options to enable the panel drivers: CONFIG_DISPLAY_PANEL_TFCS9700 CONFIG_DISPLAY_DRA_EVM_ENCODER_TPD12S015 (Found in Device Drivers -> Graphics support -> OMAP2+ Display Subsystem support -> OMAP Display Device Drivers (new device model)->) CONFIG_GPIO_PCF857X (Found in Device Drivers -> GPIO Support ->) The Device Tree nodes for the lcd and hdmi panels are in the dra7-evm.dts, with display0 as the lcd panel(node is named as tlc5910), and display1 as the hdmi connector(named as hdmi0). When using omapfb, the default device can be changes either using the bootargs, or changing the node assigned to display0. When using omapdrm, we make sure that CONFIG_NUM_CRTCS is set to 2, to ensure both LCD and HDMI can be used together. Hot Plug Detect for HDMI doesn't work on DRA7 EVM boards which have a revision lower than RevE. We need to make sure to add an extra DT parameter in the dra7-evm.dts file for early revision boards.
tpd12s015: encoder@0 {
compatible = "ti,draevm-tpd12s015";
video-source = <&hdmi>;
gpios = <&pcf_hdmi 4 0>, /* P4, CT CP HPD */
<&pcf_hdmi 5 0>, /* P5, LS OE */
<&gpio7 12 0>; /* gpio7_12/sp1_cs2, HPD */
+ disable-hpd;
};
|
|
|
