SPRACX5 May 2021 DRA710 , DRA710 , DRA712 , DRA712 , DRA714 , DRA714 , DRA716 , DRA716 , DRA718 , DRA718 , DRA722 , DRA722 , DRA724 , DRA724 , DRA725 , DRA725 , DRA726 , DRA726 , DRA745 , DRA745 , DRA746 , DRA746 , DRA74P , DRA74P , DRA750 , DRA750 , DRA756 , DRA756 , DRA75P , DRA75P , DRA76P , DRA76P , DRA77P , DRA77P , DRA780 , DRA780 , DRA781 , DRA781 , DRA782 , DRA782 , DRA783 , DRA783 , DRA785 , DRA785 , DRA786 , DRA786 , DRA787 , DRA787 , DRA788 , DRA788 , DRA790 , DRA790 , DRA791 , DRA791 , DRA793 , DRA793 , DRA797 , DRA797 , TDA2EG-17 , TDA2EG-17 , TDA2HF , TDA2HF , TDA2HG , TDA2HG , TDA2HV , TDA2HV , TDA2LF , TDA2LF , TDA2P-ABZ , TDA2P-ABZ , TDA2P-ACD , TDA2P-ACD , TDA2SA , TDA2SA , TDA2SG , TDA2SG , TDA2SX , TDA2SX
Linux is a registered trademark of Linus Torvalds in the U.S. and other countries.
All trademarks are the property of their respective owners.
The DRM/KMS framework is dedicated to the management of the display, graphic and composition subsystems, as shown in Figure 1-1.
With the help of other Linux multimedia frameworks and applications. the DRM/KMS framework is typically used:
DRM device: Responsible for aggregating the other components. Device exposed to the user space (handles all user-space requests.)
DRM Framebuffer: This is a standard object storing information about the content to be displayed.
CRTC: CRTC stands for CRT Controller, it scans out frame buffer content to one or more displays and update the frame buffer.
Planes: A plane is an image layer
Encoder: Responsible for converting a frame into the appropriate format to be transmitted through the connector.
Connector: Represent a display connector (HDMI, DP, VGA, DVI, and so forth), transmit the signals to the display. Detect display connection/removal. Expose display supported modes.
In vision SDK Linux, DSS is controlled by software running on IPU. As a result, omapdrm needs to be disabled, and Linux based DRM applications cease to function properly as there is no DRM device capable of modesetting (displaying content). A virtual DRM framework was introduced to create multiple DRM devices capable of modesetting and expose them to User space.
Using the vDRM framework, on the one hand, vDRM support the Linux display. On the other hand, M4 can control the DSS hardware. So when the M4 starting, it can display content by M4.
Table 1-1 shows a DRM comparison of the DRM of PSDKLA and VISION SDK.
Type | PSDKLA | VISION SDK |
---|---|---|
DRM | DRM | Virtual DRM |
DSS | Controlled by A15 (Linux) | Controlled by M4 (RTOS) |
Omapdrm support | YES | NO |
Fb0 | YES | NO |
Normally, A IVI system may include the three parts: HMI plane, Logo plane and RVC video plane. A cluster system may include the two parts: HMI planes and animation planes.
As shown in Figure 1-2, the standard framework, the Direct Rendering Manager (DRM) resides in kernel space, so user-space programs must use kernel system calls to request its services. A library called libdrm was created to facilitate the interface of user-space programs with the DRM subsystem. This library is merely a wrapper that provides a function written in C for every ioctl of the DRM API, as well as constants, structures and other helper elements.
In this framework, the omapdrm needs to be disabled in Linux as DSS is controlled by software running on IPU. The Linux application that based DRM will not work as there is no DRM device capable of mode setting (displaying content).
Virtual DRM can create multiple DRM devices capable of modesetting and expose them to user space. Each DRM device can contain multiple DRM connectors, and each connector can be configured to expose a predefined resolution and frame rate. Each DRM connector internally creates a DRM encoder, a DRM plane (primary) and a DRM CRTC, which are needed by DRM APIs to function properly.
Additionally, each DRM device creates a vdrm-controller device which can be opened by Linux applications to read the buffers submitted by DRM applications. Vision SDK can run a chain (usecase) with multiple instances of dispDistSrcLink, where each link reads a vdrm-controller device to obtain buffers submitted by a DRM application to a particular CRTC in a virtual DRM device.
Linux applications can continue to call DRM APIs to display a DRM Frame buffer on a DRM CRTC, even when the vision SDK application / chain is not running, or the running chain does not contain the dispDistSrcLink associated with the CRTC.
From VISION SDK 0304, vDRM framework support in SDK.
For Linux to display content, it needs to run dispDistSrcLink and DisplayLink on M4 so that the Linux application buffer can transfer to the M4 for display. Use the following steps to run the Linux application:
SDK also provide the fast boot method to run the usecases. Use the following steps to run the usecase: