From: Daniel Vetter <daniel@ffwll.ch>
To: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Cc: amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org,
"Harry Wentland" <harry.wentland@amd.com>,
"Leo Li" <sunpeng.li@amd.com>,
"Alex Deucher" <alexander.deucher@amd.com>,
"Christian König" <christian.koenig@amd.com>,
"David Airlie" <airlied@linux.ie>,
"Daniel Vetter" <daniel@ffwll.ch>,
"Nicholas Kazlauskas" <nicholas.kazlauskas@amd.com>,
hersenxs.wu@amd.com
Subject: Re: [PATCH v2 0/4] Enlarge tracepoints in the display component
Date: Wed, 16 Sep 2020 11:12:14 +0200 [thread overview]
Message-ID: <20200916091214.GY438822@phenom.ffwll.local> (raw)
In-Reply-To: <20200911145927.401322-1-Rodrigo.Siqueira@amd.com>
On Fri, Sep 11, 2020 at 10:59:23AM -0400, Rodrigo Siqueira wrote:
> Debug issues related to display can be a challenge due to the complexity
> around this topic and different source of information might help in this
> process. We already have support for tracepoints inside the display
> component, i.e., we have the basic functionalities available and we just
> need to expand it in order to make it more valuable for debugging. For
> this reason, this patchset reworks part of the current tracepoint
> options and add different sets of tracing inside amdgpu_dm, display
> core, and DCN10. The first patch of this series just rework part of the
> current tracepoints and the last set of patches introduces new
> tracepoints.
>
> This first patchset version is functional. Please, let me know what I
> can improve in the current version but also let me know what kind of
> tracepoint I can add for the next version.
>
> Finally, I want to highlight that this work is based on a set of patches
> originally made by Nicholas Kazlauskas.
>
> Change in V2:
> - I added another patch for capturing the clock state for different display
> architecture.
Hm I'm not super sure tracepoints for state dumping are the right thing
here. We kinda have the atomic state dumping code with all the various
callbacks, and you can extend that pretty easily. Gives you full state
dump in debugfs, plus a few function to dump into dmesg.
Maybe what we need is a function to dump this also into printk tracepoint
(otoh with Sean Paul's tracepoint work we'd get that through the dmesg
stuff already), and then you could do it there?
Upside is that for customers they'd get a much more consistent way to
debug display issues across different drivers.
For low-level hw debug what we do is give the hw guys an mmio trace, and
they replay it on the fancy boxes :-) So for that I think this here is
again too high level, but maybe what you have is a bit different.
-Daniel
>
> Rodrigo Siqueira (4):
> drm/amd/display: Rework registers tracepoint
> drm/amd/display: Add tracepoint for amdgpu_dm
> drm/amd/display: Add pipe_state tracepoint
> drm/amd/display: Add tracepoint for capturing clocks state
>
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 17 +
> .../amd/display/amdgpu_dm/amdgpu_dm_trace.h | 712 +++++++++++++++++-
> .../dc/clk_mgr/dce112/dce112_clk_mgr.c | 5 +
> .../display/dc/clk_mgr/dcn10/rv1_clk_mgr.c | 4 +
> .../display/dc/clk_mgr/dcn20/dcn20_clk_mgr.c | 4 +
> .../amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c | 4 +
> .../display/dc/clk_mgr/dcn30/dcn30_clk_mgr.c | 4 +
> drivers/gpu/drm/amd/display/dc/core/dc.c | 11 +
> .../gpu/drm/amd/display/dc/dce/dce_clk_mgr.c | 5 +
> .../amd/display/dc/dcn10/dcn10_hw_sequencer.c | 17 +-
> 10 files changed, 747 insertions(+), 36 deletions(-)
>
> --
> 2.28.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
next prev parent reply other threads:[~2020-09-16 9:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-11 14:59 Rodrigo Siqueira
2020-09-11 14:59 ` [PATCH v2 1/4] drm/amd/display: Rework registers tracepoint Rodrigo Siqueira
2020-09-11 17:13 ` Kazlauskas, Nicholas
2020-09-11 14:59 ` [PATCH v2 2/4] drm/amd/display: Add tracepoint for amdgpu_dm Rodrigo Siqueira
2020-09-11 14:59 ` [PATCH v2 3/4] drm/amd/display: Add pipe_state tracepoint Rodrigo Siqueira
2020-09-11 17:11 ` Kazlauskas, Nicholas
2020-09-11 14:59 ` [PATCH v2 4/4] drm/amd/display: Add tracepoint for capturing clocks state Rodrigo Siqueira
2020-09-16 9:12 ` Daniel Vetter [this message]
2020-09-16 15:27 ` [PATCH v2 0/4] Enlarge tracepoints in the display component Kazlauskas, Nicholas
2020-09-17 11:36 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200916091214.GY438822@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=Rodrigo.Siqueira@amd.com \
--cc=airlied@linux.ie \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=harry.wentland@amd.com \
--cc=hersenxs.wu@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nicholas.kazlauskas@amd.com \
--cc=sunpeng.li@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®