Documentation/gpu/amdgpu/display/dc-debug.rst
Source file repositories/reference/linux-study-clean/Documentation/gpu/amdgpu/display/dc-debug.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/gpu/amdgpu/display/dc-debug.rst- Extension
.rst- Size
- 13275 bytes
- Lines
- 306
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
========================
Display Core Debug tools
========================
In this section, you will find helpful information on debugging the amdgpu
driver from the display perspective. This page introduces debug mechanisms and
procedures to help you identify if some issues are related to display code.
Narrow down display issues
==========================
Since the display is the driver's visual component, it is common to see users
reporting issues as a display when another component causes the problem. This
section equips users to determine if a specific issue was caused by the display
component or another part of the driver.
DC dmesg important messages
---------------------------
The dmesg log is the first source of information to be checked, and amdgpu
takes advantage of this feature by logging some valuable information. When
looking for the issues associated with amdgpu, remember that each component of
the driver (e.g., smu, PSP, dm, etc.) is loaded one by one, and this
information can be found in the dmesg log. In this sense, look for the part of
the log that looks like the below log snippet::
[ 4.254295] [drm] initializing kernel modesetting (IP DISCOVERY 0x1002:0x744C 0x1002:0x0E3B 0xC8).
[ 4.254718] [drm] register mmio base: 0xFCB00000
[ 4.254918] [drm] register mmio size: 1048576
[ 4.260095] [drm] add ip block number 0 <soc21_common>
[ 4.260318] [drm] add ip block number 1 <gmc_v11_0>
[ 4.260510] [drm] add ip block number 2 <ih_v6_0>
[ 4.260696] [drm] add ip block number 3 <psp>
[ 4.260878] [drm] add ip block number 4 <smu>
[ 4.261057] [drm] add ip block number 5 <dm>
[ 4.261231] [drm] add ip block number 6 <gfx_v11_0>
[ 4.261402] [drm] add ip block number 7 <sdma_v6_0>
[ 4.261568] [drm] add ip block number 8 <vcn_v4_0>
[ 4.261729] [drm] add ip block number 9 <jpeg_v4_0>
[ 4.261887] [drm] add ip block number 10 <mes_v11_0>
From the above example, you can see the line that reports that `<dm>`,
(**Display Manager**), was loaded, which means that display can be part of the
issue. If you do not see that line, something else might have failed before
amdgpu loads the display component, indicating that we don't have a
display issue.
After you identified that the DM was loaded correctly, you can check for the
display version of the hardware in use, which can be retrieved from the dmesg
log with the command::
dmesg | grep -i 'display core'
This command shows a message that looks like this::
[ 4.655828] [drm] Display Core v3.2.285 initialized on DCN 3.2
This message has two key pieces of information:
* **The DC version (e.g., v3.2.285)**: Display developers release a new DC version
every week, and this information can be advantageous in a situation where a
user/developer must find a good point versus a bad point based on a tested
version of the display code. Remember from page :ref:`Display Core <amdgpu-display-core>`,
that every week the new patches for display are heavily tested with IGT and
manual tests.
* **The DCN version (e.g., DCN 3.2)**: The DCN block is associated with the
hardware generation, and the DCN version conveys the hardware generation that
the driver is currently running. This information helps to narrow down the
code debug area since each DCN version has its files in the DC folder per DCN
component (from the example, the developer might want to focus on
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.