.. _SD.Kernel.DisplayConfigurationAndBringUp: .. include:: /content/swdocs.rsts .. spelling:: Acer downscaling fbcon fbconsole Flatron num nvimp Viewsonic HDMI dts html hdmi tegra dcb Jetson Xavier platform specific configurations !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Hard-Coding Kernel Display Boot Mode for HDMI @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ The Linux kernel boot logs and text-mode login prompt fails to display on some monitors due to a known ``fbconsole`` pixel clock calculation issue. Affected monitors include: - Acer S277HK - Dell 24-inch 4K monitor - Viewsonic VP2780 - ASUS MX27UQ - Samsung 8500 UHD TV - NEC MultiSync LCD2070VX - LG Flatron W2246 - ASUS VW220TE NVIDIA has packaged a utility to update the kernel DTB file and work around this issue. Update the kernel DTB file @@@@@@@@@@@@@@@@@@@@@@@@@@ 1. Navigate to the kernel directory at:: /Linux_for_Tegra/kernel 2. Execute this command to update the DTB:: $ ./nv-enable-hard-coded-kernel-boot-display-mode.sh $ dtb/tegra194-p2888-0001-p2822-0000.dtb 3. Flash the system. After a successful boot, fbconsole displays in the specified mode. The default display mode is 720x480p@60Hz CEA. The DTB files are available at:: kernel/dtb/tegra194-p2888-0001-p2822-0000.dtb Specifying a Non-Default Mode ############################# 1. Open the utility in your preferred editor. 2. In the properties array, update the values to the left of the ‘:’ (colon) for each of the mode parameters. 3. Save the utility script and exit the editor. 4. Execute the utility again by completing the steps in `To update the kernel DTB file <#to-update-the-kernel-dtb-file>`__. Guidelines ########## - Any known working mode on the given Monitor/TV can be specified instead of the 720x480p mode. - If the ``nvidia,fbcon-default-mode`` node already exists, the script might print an error message. It is safe to ignore this message. - By default, the HDMI is mapped to SOR1 on both the platforms. If you updated it to SOR0, ensure that the node path is also updated and assigned to the fbcon_node variable in the script. nvimp_util: A Tool for Calculating Memory Bandwidth for a Particular Display Configuration (IMP) @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ `Is Mode Possible (IMP)` is an algorithm that can be used to determine: - With the bandwidth constraints, whether a proposed display configuration is possible. - If the configuration is possible, the expected bandwidth values that must be programmed into the hardware to support this configuration `Display configuration` loosely refers to the state of all active heads, windows, and cursors. Several factors can impact IMP, such as the maximum downscaling factor for each active window, the surface dimensions of each window, the raster timings on a particular head and so on. IMP takes all of these factors into account. ``nvimp_util`` is an offline utility that lets you input a display configuration through the command line and run IMP on it. If IMP passes, the utility outputs bandwidth values that you can specify in a device tree to support the display configuration. This topic explains how to use ``nvimp_util`` to run IMP and how to program device tree accordingly. You must have ``sudo`` permissions to run this tool. Command Line Options #################### Command line options for ``nvimp_util`` fall into two main categories: - Per-head - Per-window. The following tables describe these options: .. raw:: html :file: RequiredPerHeadOptions.htm :html:`
` .. raw:: html :file: OptionalPerHeadOptions.htm .. note:: Per-window options may be omitted completely. The *required* options must all be specified if the ``--window`` option (optional, in the subsequent table) is present. .. raw:: html :file: RequiredPerWindowOptions.htm :html:`
` .. raw:: html :file: OptionalPerWindowOptions.htm :html:`
` .. raw:: html :file: OtherOptions.htm Multi-Head/Multi-Window Input Configurations ############################################ ``nvimp_util`` allows you to specify input configurations that contain multiple active display heads and/or windows. All arguments that immediately follow a ``--head`` or ``--window`` option apply to that head or window. For example, suppose you want to specify an input configuration with the following head-to-window mapping: - HEAD0: WINDOW0, WINDOW1 - HEAD1: WINDOW2, WINDOW3 - HEAD2: WINDOW4, WINDOW5 The ``nvimp_util`` command line looks like this (where “...” represents other options):: # nvimp_util --head 0 --window 0 ... --window 1 ... \ --head 1 --window 2 ... --window 3 ... \ --head 2 --window 4 ... --window 5 ... Output Values ############# ``nvimp_util`` outputs bandwidth values calculated by IMP. These values must be programmed into hardware to support the proposed display configuration. Output values can be divided into three categories: - System - Per-window - Per-cursor. System values apply to the display as a whole. Per-window values apply to a specific window and Per-cursor values apply to a specific cursor. The following tables list the output values, with a brief description of each: .. raw:: html :file: SystemOutputValues.htm :html:`
` .. raw:: html :file: WindowOutputValues.htm :html:`
` .. raw:: html :file: CursorOutputValues.htm Device Tree Configuration ######################### ``nvimp_util`` prints the output values described above to the console. These values must then be programmed into a device tree. The Jetson display driver reads the values from device tree on boot and programs them into the hardware. For example, suppose that you run this ``nvimp_util`` command:: # nvimp_util -h 0 -p 100 -a 480 -b 640 -A 128 -B 505 -l 1 -g 257 -C 1 \ -W 1 -f FORMAT_4BPP_PACKED -s BLOCKLINEAR -x 640 -y 480 -X 640 -Y 480 -i 0 -j 0 -I 0 -J 0 -r 1 -z 1 \ -h 2 -p 74.25 -a 1280 -b 720 -A 370 -B 30 -l 1 -g 257 -C 1 \ -W 5 -f FORMAT_4BPP_PACKED -s BLOCKLINEAR -x 1280 -y 720 -X 1280 -Y 720 -i 0 -j 0 -I 0 -J 0 -r 0 -z 1 \ -W 2 -f FORMAT_1BPP_PACKED -s BLOCKLINEAR -x 1280 -y 720 -X 1280 -Y 720 -i 0 -j 0 -I 0 -J 0 -r 1 -z 0 The program displays this output:: Input parameters: Head: 0 pclkMHz: 100 h_active: 480 v_active: 640 h_blank: 128 v_blank: 505 output_lut_enable: 1 output_lut_size: 257 cursor_active: 1 Window: 1 color_format: FORMAT_4BPP_PACKED surface_format: BLOCKLINEAR sizeInX: 640 sizeInY: 480 sizeOutX: 640 sizeOutY: 480 pointInX: 0 pointInY: 0 pointOutX: 0 pointOutY: 0 rotation: 1 compression: 1 Head: 2 pclkMHz: 74.25 h_active: 1280 v_active: 720 h_blank: 370 v_blank: 30 output_lut_enable: 1 output_lut_size: 257 cursor_active: 1 Window: 5 color_format: FORMAT_4BPP_PACKED surface_format: BLOCKLINEAR sizeInX: 1280 sizeInY: 720 sizeOutX: 1280 sizeOutY: 720 pointInX: 0 pointInY: 0 pointOutX: 0 pointOutY: 0 rotation: 0 compression: 1 Window: 2 color_format: FORMAT_1BPP_PACKED surface_format: BLOCKLINEAR sizeInX: 1280 sizeInY: 720 sizeOutX: 1280 sizeOutY: 720 pointInX: 0 pointInY: 0 pointOutX: 0 pointOutY: 0 rotation: 1 compression: 0 \*******Input parameters parsing done******\ Number of Windows = 3 Window 1 is attached to Head 0 Window 5 is attached to Head 2 Window 2 is attached to Head 2 Number of Cursors = 2 Cursor 0 is attached to Head 0 Cursor 1 is attached to Head 2 Number of Heads = 2 Requested mode is possible! Add following values in device tree: /* Global settings */ nvidia,total_disp_bw_with_catchup = <0 1497231>; nvidia,total_disp_bw_without_catchup = <0 1361119>; nvidia,disp_emc_floor = <0 102000000>; nvidia,disp_min_hubclk = <0 28073088>; nvidia,total_win_fetch_slots = /bits/ 16 <15>; nvidia,total_cursor_fetch_slots = /bits/ 16 <8>; /* Window settings */ nvidia,imp_win_mapping = /bits/ 8 <1 5 2 >; nvidia,win_fetch_meter_slots = /bits/ 16 <15 8 2 >; nvidia,win_dvfs_watermark_values = <0 28274 0 16893 0 26794 >; nvidia,win_pipe_meter_values = <256 256 256 >; nvidia,win_mempool_buffer_entries = <0 2399 0 1269 0 280 >; nvidia,win_thread_groups = /bits/ 8 <-1 -1 0 >; /* Cursor settings */ nvidia,imp_head_mapping = /bits/ 8 <0 2 >; nvidia,cursor_fetch_meter_slots = /bits/ 16 <15 5 >; nvidia,cursor_dvfs_watermark_values = <0 9135 0 2762 >; nvidia,cursor_pipe_meter_values = <256 256 >; nvidia,cursor_mempool_buffer_entries = <0 798 0 241 >; .. note:: Although the ``nvimp_util`` output shows values for the compression, that setting is not implemented on T194 platforms, and is ignored. The values displayed above in the ``Global settings``, ``Window settings``, and ``Cursor settings`` sections must be copied to a device tree. Two groups of nodes are involved: - ``/host1x/disp_imp_table`` This node contains groups of IMP settings that have been calculated for certain configurations. The num_settings property specifies the number of IMP setting groups contained within the node. - ``/host1x/disp_imp_table/disp_imp_settings_`` This is a group of nodes; ```` is a number that corresponds to the order in which each node appears under ``/host1x/disp_imp_table``. That is, ```` is 0 for the first node, 1 for the second and so on. Each ``disp_imp_settings_`` node contains the IMP output settings that must be programmed for a specific input configuration. The device tree property names are the same as the corresponding parameter names that ``nvimp_util`` writes to the console. The window and cursor device tree properties each specify an *array* of values (one value per window or per cursor). Use the ``nvidia,imp_win_mapping`` and nvidia,imp_head_mapping properties to explicitly specify which window(s) or cursor(s) the node applies to. The following device tree properties operate on 64-bit numbers: - ``nvidia,total_disp_bw_with_catchup`` - ``nvidia,total_disp_bw_without_catchup`` - ``nvidia,disp_emc_floor`` - ``nvidia,disp_min_hubclk`` - ``nvidia,win_dvfs_watermark_values`` - ``nvidia,win_mempool_buffer_entries`` - ``nvidia,cursor_dvfs_watermark_values`` - ``nvidia,cursor_mempool_buffer_entries`` There are two simple approaches that you can use to copy the values to a device tree: - Edit the SoC-level IMP device tree settings directly. - **NVIDIA Jetson AGX Xavier series**: The SoC-level IMP device tree source file may be found at:: $TOP/hardware/nvidia/soc/t19x/kernel-dts/tegra194-soc/tegra194-soc-disp-imp.dtsi To copy your values over, delete or comment out the existing ``disp_imp_table`` node and add your own. - Create your own DTSI fragment with the appropriate ``disp_imp_table`` node. - **Jetson AGX Xavier series**: Insert your fragment into ``tegra194-soc-base.dtsi``. Comment out the ``#include`` at the top for the generic ``tegra194-soc-disp-imp.dtsi`` file. This is what the corresponding device tree entry will look like for the above example:: / { host1x { disp_imp_table: disp_imp_table { status = "okay"; num_settings = <1>; disp_imp_settings_0 { /* Global settings */ nvidia,total_disp_bw_with_catchup = <0 1497231>; nvidia,total_disp_bw_without_catchup = <0 1361119>; nvidia,disp_emc_floor = <0 102000000>; nvidia,disp_min_hubclk = <0 28073088>; nvidia,total_win_fetch_slots = /bits/ 16 <15>; nvidia,total_cursor_fetch_slots = /bits/ 16 <8>; /* Window settings */ nvidia,imp_win_mapping = /bits/ 8 <1 5 2 >; nvidia,win_fetch_meter_slots = /bits/ 16 <15 8 2 >; nvidia,win_dvfs_watermark_values = <0 28274 0 16893 0 26794 >; nvidia,win_pipe_meter_values = <256 256 256 >; nvidia,win_mempool_buffer_entries = <0 2399 0 1269 0 280 >; nvidia,win_thread_groups = /bits/ 8 <-1 -1 0 >; /* Cursor settings */ nvidia,imp_head_mapping = /bits/ 8 <0 2 >; nvidia,cursor_fetch_meter_slots = /bits/ 16 <15 5 >; nvidia,cursor_dvfs_watermark_values = <0 9135 0 2762 >; nvidia,cursor_pipe_meter_values = <256 256 >; nvidia,cursor_mempool_buffer_entries = <0 798 0 241 >; }; }; }; }; After you update the DTS, rebuild it and flash the new DTB blob onto the device. Seamless Display on DP (over USB-C) @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Seamless Display (display initialization by the bootloader) is not enabled on DP for Jetson AGX Xavier series in the current release. This is because for DP, the bootloader display polls for a maximum of 1 msec when the bootloader tries to detect whether HPD has been asserted by the sink. Different Type-C downstream devices that you might connect to the Type-C ports on Galen (cables, adapters, hubs and so on) might incur different amounts of latency before they trigger the handshake process needed to drive DP over Type-C. The delay is non-deterministic, so adding a loop to poll the HPD status could increase boot time. Hence, seamless display has been disabled on DP to avoid inconsistent behavior.