mirror of
https://github.com/torvalds/linux.git
synced 2025-11-04 10:40:15 +02:00
c41028a2a1
For features that are implemented primarily in DMUB (e.g. PSR), it is useful to be able to trace them at a DMUB level from the kernel, especially when debugging issues. So, introduce a debugfs interface that is able to read and set the DMUB trace mask dynamically at runtime and document how to use it. Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
118 lines
4.3 KiB
ReStructuredText
118 lines
4.3 KiB
ReStructuredText
========================
|
|
Display Core Debug tools
|
|
========================
|
|
|
|
DC Visual Confirmation
|
|
======================
|
|
|
|
Display core provides a feature named visual confirmation, which is a set of
|
|
bars added at the scanout time by the driver to convey some specific
|
|
information. In general, you can enable this debug option by using::
|
|
|
|
echo <N> > /sys/kernel/debug/dri/0/amdgpu_dm_visual_confirm
|
|
|
|
Where `N` is an integer number for some specific scenarios that the developer
|
|
wants to enable, you will see some of these debug cases in the following
|
|
subsection.
|
|
|
|
Multiple Planes Debug
|
|
---------------------
|
|
|
|
If you want to enable or debug multiple planes in a specific user-space
|
|
application, you can leverage a debug feature named visual confirm. For
|
|
enabling it, you will need::
|
|
|
|
echo 1 > /sys/kernel/debug/dri/0/amdgpu_dm_visual_confirm
|
|
|
|
You need to reload your GUI to see the visual confirmation. When the plane
|
|
configuration changes or a full update occurs there will be a colored bar at
|
|
the bottom of each hardware plane being drawn on the screen.
|
|
|
|
* The color indicates the format - For example, red is AR24 and green is NV12
|
|
* The height of the bar indicates the index of the plane
|
|
* Pipe split can be observed if there are two bars with a difference in height
|
|
covering the same plane
|
|
|
|
Consider the video playback case in which a video is played in a specific
|
|
plane, and the desktop is drawn in another plane. The video plane should
|
|
feature one or two green bars at the bottom of the video depending on pipe
|
|
split configuration.
|
|
|
|
* There should **not** be any visual corruption
|
|
* There should **not** be any underflow or screen flashes
|
|
* There should **not** be any black screens
|
|
* There should **not** be any cursor corruption
|
|
* Multiple plane **may** be briefly disabled during window transitions or
|
|
resizing but should come back after the action has finished
|
|
|
|
Pipe Split Debug
|
|
----------------
|
|
|
|
Sometimes we need to debug if DCN is splitting pipes correctly, and visual
|
|
confirmation is also handy for this case. Similar to the MPO case, you can use
|
|
the below command to enable visual confirmation::
|
|
|
|
echo 1 > /sys/kernel/debug/dri/0/amdgpu_dm_visual_confirm
|
|
|
|
In this case, if you have a pipe split, you will see one small red bar at the
|
|
bottom of the display covering the entire display width and another bar
|
|
covering the second pipe. In other words, you will see a bit high bar in the
|
|
second pipe.
|
|
|
|
DTN Debug
|
|
=========
|
|
|
|
DC (DCN) provides an extensive log that dumps multiple details from our
|
|
hardware configuration. Via debugfs, you can capture those status values by
|
|
using Display Test Next (DTN) log, which can be captured via debugfs by using::
|
|
|
|
cat /sys/kernel/debug/dri/0/amdgpu_dm_dtn_log
|
|
|
|
Since this log is updated accordingly with DCN status, you can also follow the
|
|
change in real-time by using something like::
|
|
|
|
sudo watch -d cat /sys/kernel/debug/dri/0/amdgpu_dm_dtn_log
|
|
|
|
When reporting a bug related to DC, consider attaching this log before and
|
|
after you reproduce the bug.
|
|
|
|
DMUB Firmware Debug
|
|
===================
|
|
|
|
Sometimes, dmesg logs aren't enough. This is especially true if a feature is
|
|
implemented primarily in DMUB firmware. In such cases, all we see in dmesg when
|
|
an issue arises is some generic timeout error. So, to get more relevant
|
|
information, we can trace DMUB commands by enabling the relevant bits in
|
|
`amdgpu_dm_dmub_trace_mask`.
|
|
|
|
Currently, we support the tracing of the following groups:
|
|
|
|
Trace Groups
|
|
------------
|
|
|
|
.. csv-table::
|
|
:header-rows: 1
|
|
:widths: 1, 1
|
|
:file: ./trace-groups-table.csv
|
|
|
|
**Note: Not all ASICs support all of the listed trace groups**
|
|
|
|
So, to enable just PSR tracing you can use the following command::
|
|
|
|
# echo 0x8020 > /sys/kernel/debug/dri/0/amdgpu_dm_dmub_trace_mask
|
|
|
|
Then, you need to enable logging trace events to the buffer, which you can do
|
|
using the following::
|
|
|
|
# echo 1 > /sys/kernel/debug/dri/0/amdgpu_dm_dmcub_trace_event_en
|
|
|
|
Lastly, after you are able to reproduce the issue you are trying to debug,
|
|
you can disable tracing and read the trace log by using the following::
|
|
|
|
# echo 0 > /sys/kernel/debug/dri/0/amdgpu_dm_dmcub_trace_event_en
|
|
# cat /sys/kernel/debug/dri/0/amdgpu_dm_dmub_tracebuffer
|
|
|
|
So, when reporting bugs related to features such as PSR and ABM, consider
|
|
enabling the relevant bits in the mask before reproducing the issue and
|
|
attach the log that you obtain from the trace buffer in any bug reports that you
|
|
create.
|