Lines Matching +full:display +full:- +full:related
2 Display Core Debug tools
6 driver from the display perspective. This page introduces debug mechanisms and
7 procedures to help you identify if some issues are related to display code.
9 Narrow down display issues
12 Since the display is the driver's visual component, it is common to see users
13 reporting issues as a display when another component causes the problem. This
14 section equips users to determine if a specific issue was caused by the display
18 ---------------------------
43 (**Display Manager**), was loaded, which means that display can be part of the
45 amdgpu loads the display component, indicating that we don't have a
46 display issue.
49 display version of the hardware in use, which can be retrieved from the dmesg
52 dmesg | grep -i 'display core'
56 [ 4.655828] [drm] Display Core v3.2.285 initialized on DCN 3.2
60 * **The DC version (e.g., v3.2.285)**: Display developers release a new DC version
63 version of the display code. Remember from page :ref:`Display Core <amdgpu-display-core>`,
64 that every week the new patches for display are heavily tested with IGT and
78 dmesg | grep -i 'ATOM BIOS'
82 [ 4.274534] amdgpu: ATOM BIOS: 113-D7020100-102
86 Avoid loading display core
87 --------------------------
90 the issue; if you suspect that the display is not part of the problem and your
92 the display component from the equation. First, you need to identify `dm` ID
121 necessary to use the display component to reproduce the issue (e.g., play a
124 **Note: This will probably lead to the absence of a display output.**
126 Display flickering
127 ------------------
129 Display flickering might have multiple causes; one is the lack of proper power
133 bash -c "echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level"
137 is less likely that the issue is related to power management. If the issue
139 the display should not be ignored since this could be a DPM issues. From the
140 display side, if the power increase fixes the issue, it is worth debugging the
144 Display artifacts
145 -----------------
153 of the display parameters, but the userspace might also cause this issue. One
159 rendering, and the display code just got the framebuffer already corrupted.
166 structure usually facilitates the bring-up phase since developers can start
173 indication of Sub-Viewport issues; after the users identified the target DCN,
183 Display core provides a feature named visual confirmation, which is a set of
194 ---------------------
196 If you want to enable or debug multiple planes in a specific user-space
206 * The color indicates the format - For example, red is AR24 and green is NV12
224 ----------------
233 bottom of the display covering the entire display width and another bar
242 using Display Test Next (DTN) log, which can be captured via debugfs by using::
247 change in real-time by using something like::
249 sudo watch -d cat /sys/kernel/debug/dri/0/amdgpu_dm_dtn_log
251 When reporting a bug related to DC, consider attaching this log before and
263 From the display perspective, pay attention to the firmware of the DMCU and
278 ------------
280 .. csv-table::
281 :header-rows: 1
283 :file: ./trace-groups-table.csv
302 So, when reporting bugs related to features such as PSR and ABM, consider