Xilinx DRM KMS HDMI-Tx Driver

Xilinx DRM KMS HDMI-Tx Driver

The purpose of this page is to describe the Linux DRM driver for The HDMI 1.4/2.0 Transmitter Subsystem soft IP. 

For the HDMI 2.1 Transmitter Subsystem Driver, please see Xilinx DRM KMS HDMI 2.1 TX Subsystem Driver

Table of Contents

Introduction

The HDMI 1.4/2.0 Transmitter Subsystem is a feature-rich soft IP incorporating all the necessary logic to properly interface with PHY layers and provide HDMI® encoding functionality. The subsystem is a hierarchical IP that bundles a collection of HDMI TX-related IP sub-cores and outputs them as a single IP. The subsystem takes incoming video and audio streams and transfers them to an HDMI stream. The stream is then forwarded to the video PHY layer.

The HDMI 1.4/2.0 Transmitter Subsystem is a MAC subsystem which works with a Video PHY Controller (PHY) to create a video connectivity system. The HDMI 1.4/2.0 Transmitter Subsystem is tightly coupled with the Xilinx Video PHY Controller, which itself is independent and offer flexible architecture with multiple-protocol support. Both MAC and PHY are dynamically programmable through the AXI4-Lite interface.

MAC Interface with PHY

 

Driver Overview

HDMI Tx is the last node in the display pipeline. The linux driver is implemented as a sub-component of the Xilinx DRM KMS bridge driver and implements the encoder/connector interface. The subsystem includes the video timing generator and Tx sub-core. Driver implements the DRM callbacks to read the display EDID and present it to the framework anytime a display is connected. It works in tandem with the DRM bridge driver to validates each mode listed in the EDID and reject unsupported modes.

On mode change request from user application driver works in conjunction with DRM framework to validate the requested mode to ensure the stream can be generated by Tx core and is supported by the attached display. If requested mode is supported the driver will configure Tx sub-core for new mode and the internal video timing controller (VTC) to generate requisite video timing for it. It also configures the PHY layer for the new mode and manages all required interaction between MAC & PHY layer.

After mode setup is complete PHY state machine is reset and put into a wait state awaiting the reference clock for the new mode from an external clock source. DRM framework requests the registered clock producer (SI5324/SI5319 for Xilinx HDMI) to generate the clock for desired mode. Availability of this clock is checked by PHY using tx_refclk_rdy port pin. After this pin is asserted HIGH PHY’s internal state machine is triggered to lock onto the incoming frequency and stream transmission starts. As a last step the driver then configures the external LVDS to TMDS level shifter component (DP159), via CCF framework, which will convert the GT output signals to HDMI interface.

IP/Driver Features

 

IP Feature

2018.1 hdmi-modules

2018.3 and onward hdmi-modules

compatible string 

xlnx,v-hdmi-tx-ss-3.1

xlnx,v-hdmi-tx-ss-3.1

IP Version Supported

3.1

3.1

HDMI 2.0 and 1.4 compatible

Y

Y

pixel per clock 

IP supports 2 or 4 ppc

Driver tested for 2 ppc only.

IP supports 2 or 4 ppc

Driver tested for 2 ppc only.

Supports resolutions up to 4,096 x 2,160 @60 fps

Y

Y

8, 10, 12, and 16-bit Deep-color support

8 & 10-bit Only

8 & 10-bit Only

Support color space for RGB, YUV 4:4:4, YUV 4:2:2, YUV 4:2:0

Support all color spaces

Support all color spaces

Support AXI4-Stream Video output stream and
Native Video output stream

Axi-Stream Video Only

Axi-Stream Video Only

Optional High Bandwidth Digital Copy Protection (HDCP) 1.4 support

Y

Y

Optional HDCP 2.2 support

Y

Y

Optional Video over AXIS compliant NTSC/PAL Support

Y

Y

Optional Video over AXIS compliantYUV420 Support

Y

Y

Xilinx DRM bridge support

                  N

                            Y (from 2022.1)

Note:

DRM bridge support verified with the display pipeline Framebuffer_read → VPSS (scaler_only) → HDMI-Tx

Missing Features / Known issues / Limitations in Driver

  • This driver support Xilinx DRM bridge, but verified when VPSS is connected as "Scaler_only" mode and without mixer.

 

Kernel Configuration Options for Driver


2018.1 and onwards Kernel brings-in the support for the new component based DRM framework from Xilinx. HDMI driver has been updated to work with the new framework and is not backward compatible with the old Xilinx DRM framework. 

The driver sources can be found here: https://github.com/Xilinx/hdmi-modules/tree/master/hdmi/xilinx-hdmi-tx

2018.1 and onwards: Supports ONLY the new Xilinx DRM framework driver and PL crtc and can be enabled via following configurations options
CONFIG_DRM_XLNX and CONFIG_DRM_XLNX_PL_DISP

The above defined options will only enable the new DRM framework. Since HDMI Tx driver is now added as an out-of-tree kernel module, there is not kernel configuration required. Instead user must include the driver in the rootfs. Following steps are required enable the driver

  • Make sure the meta-user layer has the recipe-hdmi included

  • For 2019.2 onwards

    • Add the recipe to petalinux image. Edit ./meta-user/conf/user-rootfsconfig and add the new recipe at the end

CONFIG_kernel-module-hdmi
  • For 2018.1 to 2019.1

    • Add the recipe to petalinux image. Edit ./meta-user/recipes-core/images/petalinux-image-full.bbappend and add the new recipe at the end

      • NOTE - While using 2018.1 petalinux, the file name was ./meta-user/recipes-core/images/petalinux-image.bbappend

IMAGE_INSTALL_append = " kernel-module-hdmi"
  • Next include the driver in the rootfs

% petalinux-config -c rootfs
  • Select "user-pakages->modules->kernel-module-hdmi", save and exit

  • Build the project

%petalinux-build

 

  • Starting from version 2025.1, the driver is built using the Yocto build process. To enable the HDMI module, add the following line to the local.conf file

    • IMAGE_INSTALL:append = " kernel-module-hdmi"

Device Tree Binding

The dts node should be defined with correct hardware configuration. How to define the node is documented in

2025.2: Documentation/devicetree/bindings/xlnx,v-hdmi-tx-ss.yaml

2025.1:Documentation/devicetree/bindings/xlnx,v-hdmi-tx-ss.yaml

2024.2: Documentation/devicetree/bindings/xlnx,v-hdmi-tx-ss.yaml

2022.1: Documentation/devicetree/bindings/xlnx,v-hdmi-tx-ss.txt

2021.2: Documentation/devicetree/bindings/xlnx,v-hdmi-tx-ss.txt

2021.1: Documentation/devicetree/bindings/xlnx,v-hdmi-tx-ss.txt

2020.2: Documentation/devicetree/bindings/xlnx,v-hdmi-tx-ss.txt

2020.1: Documentation/devicetree/bindings/xlnx,v-hdmi-tx-ss.txt

2019.2: Documentation/devicetree/bindings/xlnx,v-hdmi-tx-ss.txt

2019.1: Documentation/devicetree/bindings/xlnx,v-hdmi-tx-ss.txt

2018.3: Documentation/devicetree/bindings/xlnx,v-hdmi-tx-ss.txt

2018.1: Documentation/devicetree/bindings/xlnx%2Cv-hdmi-tx-ss.txt


Below is the example device tree for a design where the display pipeline flows from DDR memory through a framebuffer read DMA to an HDMI transmitter. Below device tree nodes are generated by SDT.

v_hdmi_tx_ss: v_hdmi_tx_ss@80020000 { xlnx,audio-enabled; interrupts = < 0 91 4 >; compatible = "xlnx,v-hdmi-tx-ss-3.2" , "xlnx,v-hdmi-tx-ss-3.1"; xlnx,highaddr = <0x8003ffff>; xlnx,exdes-topology = <0>; hdcp14-present = <0>; xlnx,video-mask-enable = <1>; xlnx,hdmi-version = <3>; xlnx,xlnx-hdmi-acr-ctrl = <&audio_ss_hdmi_acr_ctrl_0>; hdmitx-present = <1>; interrupt-parent = <&imux>; xlnx,rable = <0>; xlnx,ip-name = "v_hdmi_tx_ss"; hdmitx-connected = <&v_hdmi_tx_ss_v_hdmi_tx>; xlnx,hysteresis-level = <12>; reg = <0x0 0x80020000 0x0 0x20000>; xlnx,addr-width = <10>; xlnx,ch-width = <8>; xlnx,exdes-nidru; xlnx,exdes-rx-pll-selection = <0>; clocks = <&misc_clk_2>, <&zynqmp_clk 71>, <&misc_clk_0>, <&zynqmp_clk 72>, <&misc_clk_1>; xlnx,vid-interface = <0>; xlnx,max-bits-per-component = <8>; xlnx,snd-pcm = <&audio_ss_audio_formatter_0>; xlnx,exdes-tx-pll-selection = <6>; hdcp22-present = <0>; xlnx,add-mark-dbg = <0>; phy-names = "hdmi-phy0" , "hdmi-phy1" , "hdmi-phy2"; xlnx,edk-iptype = "PERIPHERAL"; vtc-present = <1>; xlnx,ddc2-en = <0>; phys = <&vid_phy_controllertxphy_lane0 0 1 1 1>, <&vid_phy_controllertxphy_lane1 0 1 1 1>, <&vid_phy_controllertxphy_lane2 0 1 1 1>; status = "okay"; xlnx,axi-lite-freq-hz = <0x5f5b9f5>; vtc-connected = <&v_hdmi_tx_ss_v_tc>; clock-names = "link_clk" , "s_axi_cpu_aclk" , "s_axis_audio_aclk" , "s_axis_video_aclk" , "video_clk"; xlnx,input-pixels-per-clock = <2>; hdcptimer-present = <0>; interrupt-names = "irq"; xlnx,include-yuv420-sup; xlnx,include-low-reso-vid; xlnx,name = "v_hdmi_tx_ss"; xlnx,exdes-axilite-freq = <100>; hdmitx_portsv_hdmi_tx_ss: ports { #address-cells = <1>; #size-cells = <0>; encoder_hdmi_portv_hdmi_tx_ss: port@0 { reg = <0>; encoderv_hdmi_tx_ss: endpoint { remote-endpoint = <&v_frmbuf_rdv_hdmi_tx_ss>; }; }; }; }; v_frmbuf_rd: v_frmbuf_rd@80010000 { xlnx,has-y-uv8 = <1>; reset-gpios = <&gpio 79 1>; xlnx,max-height = <2160>; xlnx,has-bgra8 = <0>; xlnx,has-rgba8 = <0>; xlnx,rable = <0>; xlnx,ip-name = "v_frmbuf_rd"; reg = <0x0 0x80010000 0x0 0x10000>; xlnx,s-axi-ctrl-addr-width = <0x7>; xlnx,pixels-per-clock = <2>; xlnx,samples-per-clock = <2>; xlnx,max-nr-planes = <2>; xlnx,has-bgr8 = <1>; xlnx,has-rgb8 = <1>; xlnx,has-y-uv8-420 = <1>; xlnx,has-yuyv8 = <1>; xlnx,has-y-u-v8 = <0>; interrupt-names = "interrupt"; compatible = "xlnx,v-frmbuf-rd-2.5" , "xlnx,axi-frmbuf-rd-v2.2"; xlnx,max-width = <3840>; xlnx,has-rgb16 = <0>; xlnx,vid-formats = "rgb888" , "xbgr8888" , "xrgb8888" , "bgr888" , "uyvy" , "y8" , "vuy888" , "xvuy8888" , "yuyv" , "nv12" , "nv16"; xlnx,has-bgrx8 = <1>; xlnx,has-rgbx8 = <1>; xlnx,has-rgbx10 = <0>; interrupt-parent = <&imux>; xlnx,aximm-num-outstanding = <4>; xlnx,has-uyvy8 = <1>; xlnx,has-rgbx12 = <0>; xlnx,aximm-burst-length = <16>; xlnx,aximm-addr-width = <64>; xlnx,video-width = <8>; xlnx,max-cols = <3840>; xlnx,has-yuv8 = <1>; status = "okay"; xlnx,has-y-uv10-420 = <0>; xlnx,has-yuva8 = <0>; xlnx,has-y-uv12-420 = <0>; xlnx,name = "v_frmbuf_rd"; interrupts = < 0 93 4 >; xlnx,fid; xlnx,has-y10 = <0>; xlnx,has-y-uv16-420 = <0>; xlnx,has-y12 = <0>; xlnx,has-alpha = <0>; xlnx,has-y-u-v10 = <0>; clocks = <&zynqmp_clk 72>; xlnx,has-y16 = <0>; xlnx,dma-align = <16>; xlnx,edk-iptype = "PERIPHERAL"; xlnx,has-interlaced = <1>; xlnx,has-yuv16 = <0>; xlnx,has-yuvx8 = <1>; xlnx,dma-addr-width = <64>; clock-names = "ap_clk"; xlnx,s-axi-ctrl-data-width = <0x20>; xlnx,has-y8 = <1>; xlnx,has-y-uv10 = <0>; xlnx,has-y-uv12 = <0>; xlnx,max-rows = <2160>; xlnx,has-yuvx10 = <0>; #dma-cells = <1>; xlnx,has-yuvx12 = <0>; xlnx,has-y-uv16 = <0>; xlnx,has-y-u-v8-420 = <0>; xlnx,max-data-width = <8>; xlnx,num-video-components = <3>; xlnx,aximm-data-width = <128>; }; v_pl_dispv_hdmi_tx_ss: drm-pl-disp-drvv_hdmi_tx_ss { compatible = "xlnx,pl-disp"; xlnx,vformat = "YUYV"; dmas = <&v_frmbuf_rd 0>; dma-names = "dma0"; pl_display_portv_hdmi_tx_ss: port@0 { reg = <0>; v_frmbuf_rdv_hdmi_tx_ss: endpoint { remote-endpoint = <&encoderv_hdmi_tx_ss>; }; }; };

The following system-user.dtsi entries need to be appended for various platforms to support onboard redriver components, which cannot be generated by the SDT tool.

  • system-user.dtsi for ZCU102 platform

&zynq_us_ss_0_fmch_axi_iic { /* Si5324 i2c clock generator */ si5324: clock-generator@68 { compatible = "silabs,si5324"; reg = <0x68>; #address-cells = <1>; #size-cells = <0>; #clock-cells = <1>; /* input clock(s); the XTAL is hard-wired on the ZCU102 board */ clocks = <&refhdmi>; clock-names = "xtal"; /* output clocks */ clk0 { reg = <0>; /* HDMI TX reference clock output frequency */ clock-frequency = <27000000>; }; /* this Si5324 output is not connected on the ZCU102 board clk1 { reg = <1>; }; */ }; /* DP159 exposes a virtual CCF clock. Upon .set_rate(), it adapts its retiming/driving behaviour */ dp159: hdmi-retimer@5e { compatible = "ti,dp159"; reg = <0x5e>; #address-cells = <1>; #size-cells = <0>; #clock-cells = <0>; }; }; &v_hdmi_tx_ss { clocks = <&misc_clk_1>, <&zynqmp_clk 71>, <&audio_ss_0_clk_wiz 0>, <&zynqmp_clk 72>, <&misc_clk_0>, <&si5324 0>, <&dp159>; clock-names = "link_clk" , "s_axi_cpu_aclk" , "s_axis_audio_aclk" , "s_axis_video_aclk" , "video_clk","txref-clk", "retimer-clk"; }; &vid_phy_controller{ clock-names = "drpclk" , "gtsouthrefclk0_in" , "gtsouthrefclk0_odiv2_in" , "mgtrefclk0_pad_n_in" , "mgtrefclk0_pad_p_in" , "mgtrefclk1_pad_n_in" , "mgtrefclk1_pad_p_in" , "vid_phy_axi4lite_aclk" , "vid_phy_rx_axi4s_aclk" , "vid_phy_sb_aclk" , "vid_phy_tx_axi4s_aclk", "dru-clk"; clocks = <&zynqmp_clk 71>, <&misc_clk_2>, <&misc_clk_2>, <&misc_clk_3>, <&misc_clk_3>, <&misc_clk_3>, <&misc_clk_3>, <&zynqmp_clk 71>, <&misc_clk_1>, <&zynqmp_clk 71>, <&misc_clk_1>, <&si570_2>; };

Device Control

Sysfs interface has been added to the driver to enable the user to query the current device status and/or change certain properties. Below table describes the available commands and the access permissions available

Command Name

Permission

Description

hdmi_info

Read-Only by all

Shows detected stream properties

hdmi_log

Read-Only by all

Shows event logs captured by the driver

hdcp_log

Read-Only by all

Shows event logs captured by the driver

hdcp_debugen

Write-Only by group and owner

1: Enable detailed logging of hdcp events
0: Disable detailed logging of hdcp events
(0 is the default)

hdcp_authenticate

Write by group and owner

Read by all

1: enable authentication upon stream up
0: disable

hdcp_encrypt

Write by group and owner

Read by all

1: enable encryption after authentication
0: do not enable encryption after authentication

hdcp_authenticated

Read-Only by all

1: Authentication successful
0: Un-authenticated

hdcp_encrypted

Read-Only by all

1: Input stream is encrypted
0: Input stream is unencrypted

hdcp_protect

Write by group and owner

Read by all

1: content must be protected - If the encrypted flag is not set, then the output will be blanked
0: no protection is required – disable hdcp blank

hdcp_key

R/W by owner only

Allows owner to write the HDCP key binary data (read from EEPROM) to IP

hdcp_password

R/W by owner only

Allows owner to set a password for the hdcp key in eeprom. After writing (first) password
and (then) key, upon reading back hdcp_password it returns "accepted" when the password
could decrypt the key. It reads back "rejected" in all other cases.

vphy_info

Read-Only by all

Shows video_phy status for both Rx and Tx

vphy_log

Read-Only by all

Shows event logs captured by both Rx and Tx


Sysfs entries are accessible at /sys/devices/platform/amba_pl\@0/<device_addr>/

For ex:
To read out information on current set output stream

%> cat /sys/devices/platform/amba_pl\@0/<device_addr>/hdmi_info

To enable detailed logging of hdcp events

 

%> echo 1 > /sys/devices/platform/amba_pl\@0/<device_addr>/hdcp_debug

 

HDCP Support

Driver supports HDCP1.4 and 2.2 Protocols and exposes the sysfs controls to allow user space to load the encrypted HDCP production keys and read-in the requisite password to decrypt the keys. If the provided password is able to decrypt the keys, keys will be loaded into the required IP blocks and the HDCP feature will be enabled. The driver boots with HDCP disabled as default state. User can load the keys any time after the system is running. An example application that demonstrates the HDCP key loading process from user space will be provided by Xilinx for customer reference. For details on HDCP Support provided by the soft IP please refer product guide pg235 on Xilinx.com

Disclaimer: It is user’s responsibility to provide and protect the confidential key data. HDCP Keys must be programmed into the EEPROM on the board.

Test procedure

HDMI-Tx can be manually configured to generate the required mode. An open source utility like modetest can be used to configure the display pipeline.

  • DDR ==> FB_Rd (DMA) ==> HDMI_Tx


Note: Since 2018.1 introduces a new Xilinx DRM driver, below test procedure will cover details for 2018.1 and later versions.
2018.1 and onwards: xlnx

2018.1 and onwards
Sample command to set a mode is shown below

%> modetest -M xlnx -s <connector_id>[@<crtc_id>]:<mode>[-<vrefresh>][@<format>

 

For ex:

 

%> modetest -M xlnx -s 30@28:1920x1080-60@YUYV &


Above command will generate a color bar pattern at requested resolution in DDR, configures the DMA to read the frame from DDR and configures the HDMI Tx for said resolution. As a final result Color Bar at defined resolution should be visible on screen.

Driver also supports changing output color formats dynamically. Available output color formats supported by DMA engine can be determined using modetest utility as shown below

root@zcu102:~# modetest -M xlnx Encoders: id crtc type possible crtcs possible clones 29 28 TMDS 0x00000001 0x00000000 Connectors: id encoder status name size (mm) modes encoders 30 29 connected HDMI-A-1 600x340 28 29 modes: name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot) 3840x2160 60 3840 4016 4104 4400 2160 2168 2178 2250 594000 flags: phsync, pvsync; type: preferred, driver 3840x2160 60 3840 4016 4104 4400 2160 2168 2178 2250 593407 flags: phsync, pvsync; type: driver 3840x2160 50 3840 4896 4984 5280 2160 2168 2178 2250 594000 flags: phsync, pvsync; type: driver 3840x2160 30 3840 4016 4104 4400 2160 2168 2178 2250 297000 flags: phsync, nvsync; type: driver 3840x2160 30 3840 4016 4104 4400 2160 2168 2178 2250 297000 flags: phsync, pvsync; type: driver 3840x2160 30 3840 4016 4104 4400 2160 2168 2178 2250 296703 flags: phsync, pvsync; type: driver 3840x2160 25 3840 4896 4984 5280 2160 2168 2178 2250 297000 flags: phsync, pvsync; type: driver 3840x2160 24 3840 5116 5204 5500 2160 2168 2178 2250 297000 flags: phsync, pvsync; type: driver 3840x2160 24 3840 5116 5204 5500 2160 2168 2178 2250 296703 flags: phsync, pvsync; type: driver 1920x1080 60 1920 2008 2052 2200 1080 1084 1089 1125 148500 flags: phsync, nvsync; type: driver 1920x1080 60 1920 2008 2052 2200 1080 1084 1089 1125 148500 flags: phsync, pvsync; type: driver 1920x1080 60 1920 2008 2052 2200 1080 1084 1089 1125 148352 flags: phsync, pvsync; type: driver 1920x1080 30 1920 2008 2052 2200 1080 1084 1089 1125 74250 flags: phsync, pvsync; type: driver 1920x1080 30 1920 2008 2052 2200 1080 1084 1089 1125 74176 flags: phsync, pvsync; type: driver 1920x1080 24 1920 2558 2602 2750 1080 1084 1089 1125 74250 flags: phsync, pvsync; type: driver 1920x1080 24 1920 2558 2602 2750 1080 1084 1089 1125 74176 flags: phsync, pvsync; type: driver 1600x900 60 1600 1624 1704 1800 900 901 904 1000 108000 flags: phsync, pvsync; type: driver 1280x1024 60 1280 1328 1440 1688 1024 1025 1028 1066 108000 flags: phsync, pvsync; type: driver 1280x800 60 1280 1328 1360 1440 800 803 809 823 71000 flags: phsync, nvsync; type: driver 1152x864 60 1152 1216 1336 1520 864 865 868 895 81579 flags: nhsync, pvsync; type: 1280x720 60 1280 1390 1430 1650 720 725 730 750 74250 flags: phsync, pvsync; type: driver 1280x720 60 1280 1390 1430 1650 720 725 730 750 74176 flags: phsync, pvsync; type: driver 1024x768 60 1024 1048 1184 1344 768 771 777 806 65000 flags: nhsync, nvsync; type: driver 800x600 60 800 840 968 1056 600 601 605 628 40000 flags: phsync, pvsync; type: driver 720x480 60 720 736 798 858 480 489 495 525 27027 flags: nhsync, nvsync; type: driver 720x480 60 720 736 798 858 480 489 495 525 27000 flags: nhsync, nvsync; type: driver 640x480 60 640 656 752 800 480 490 492 525 25200 flags: nhsync, nvsync; type: driver 640x480 60 640 656 752 800 480 490 492 525 25175 flags: nhsync, nvsync; type: driver props: 1 EDID: flags: immutable blob blobs: value: 00ffffffffffff001e6d085b92a10400 031a0103803c2278ea3035a7554ea326 0f50542108007140818081c0a9c0d1c0 81000101010108e80030f2705a80b058 8a0058542100001e04740030f2705a80 b0588a0058542100001a000000fd0038 3d1e873c000a202020202020000000fc 004c4720556c7472612048440a2001d9 020330714d902220050403020161605d 5e5f230907076d030c001000b83c2000 6001020367d85dc401788003e30f0003 023a801871382d40582c450058542100 001a0000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000026 2 DPMS: flags: enum enums: On=0 Standby=1 Suspend=2 Off=3 value: 0 5 link-status: flags: enum enums: Good=0 Bad=1 value: 0 CRTCs: id fb pos size 28 47 (0,0) (3840x2160) 3840x2160 60 3840 4016 4104 4400 2160 2168 2178 2250 594000 flags: phsync, pvsync; type: preferred, driver props: Planes: id crtc fb CRTC x,y x,y gamma size possible crtcs 27 28 47 0,0 0,0 0 0x00000001 formats: XB24 XB30 XR24 XV24 VU24 XV30 YUYV UYVY NV16 NV12 XV15 XV20 BG24 GREY Y10 RG24 props: 6 type: flags: immutable enum enums: Overlay=0 Primary=1 Cursor=2 value: 1 Frame buffers: id size pitch


Refer Line "formats" that indicates the FrameBuffer DMA IP configuration supports XB24 XB30 XR24 XV24 VU24 XV30 YUYV UYVY NV16 NV12 XV15 XV20 BG24 GREY Y10 color formats. This setting is configured by the DMA driver device tree node property xlnx,vid-formats

How to test DRM bridge with HDMI-Tx:

To support bridge functionality HDMI-Tx driver requires few DRM connector properties like height, width, aspect ratio and color format of input and output.

Following is the table of color formats and its equivalent media bus format value to be passed as DRM properties.

Refer the media bus formats here

Format

Media Bus Value

Format

Media Bus Value

RGB

4106

YUV444

8228

YUV420

8448

YUV422 

8207 

Sample command to perform upscale 720p@60(1280x720) to 1080p@60(1920x1080) :

%> modetest -D amba_pl@0:drm-dmaengine-drv -s 37:1280x720-60@BG24 -w 37:height_out:1080 -w 37:width_out:1920 -w 37:in_fmt:4106 -w 37:out_fmt:4106 -w 37:aspect_ratio:1

Sample command to perform downscale  1080p@60(1920x1080) to 720p@60(1280x720)

%> modetest -D amba_pl@0:drm-dmaengine-drv -s 37:1920x1080-60@BG24 -w 37:height_out:720 -w 37:width_out:1280 -w 37:in_fmt:4106 -w 37:out_fmt:4106 -w 37:aspect_ratio:1

    

DEBUG Capability

HDMI Linux driver implements the capability to tap IP status at pre-defined points in the control flow. User can enable the debug taps by uncommenting the pre-processor directive (#define DEBUG) to monitor the progress within the driver. All debug prints are sent to serial console and can be viewed in kernel dmesg buffer

Boards Supported

Driver has been tested on following boards

  • zcu102 Rev 1.0

  • zcu106 Rev 1.0

Driver has been tested with HDMI FrameBuffer Example Design design

Change Log

2025.2

  • Summary:

    • <No Change>

2025.1

2024.2

  • Summary:

    • <No change>

2024.1

2023.2

2023.1

2022.2

2022.1

2021.2

2021.1

2020.2