From: John Harrison <john.c.harrison@intel.com>
To: Michal Wajdeczko <michal.wajdeczko@intel.com>,
<Intel-Xe@Lists.FreeDesktop.Org>,
"Souza, Jose" <jose.souza@intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [PATCH v5 1/8] drm/xe/guc: Remove spurious line feed in debug print
Date: Wed, 31 Jul 2024 12:56:30 -0700 [thread overview]
Message-ID: <a9ef6254-f428-47b7-827d-82ec94408ca2@intel.com> (raw)
In-Reply-To: <9306b3ec-3999-468b-8395-dc3b7900ff6f@intel.com>
On 7/30/2024 02:14, Michal Wajdeczko wrote:
>
> On 30.07.2024 01:17, John.C.Harrison@Intel.com wrote:
>> From: John Harrison <John.C.Harrison@Intel.com>
>>
>> Including line feeds at the start of a debug print messes up the
>> output when sent to dmesg. The break actually appears between all the
>> usefu
> typo
>
>> prefix information and the actual string being printed. In this
>> case, each block of data has a very clear start line and an extra
>> delimeter is really not necessary. So don't do it.
>>
>> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
>> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> there was some discussion about merging this one without a conclusion
>
> [1] https://patchwork.freedesktop.org/patch/601018/?series=135447&rev=1
The last comment was for Mesa people to shout if it would be a problem
and no-one shouted, so...
However, I would strongly argue that devcoredump exact layout and
content cannot be considered UABI because it is going to change as the
driver changes. Some of the information being printed is internal driver
state. Driver internals can never be UABI. If there are userland tools
parsing the dump then those tools have to be able to adapt to changing
core dump formats. There is also the argument that we are still in
force-probe so there is no fixed UABI yet anyway. So now is the time to
get the formatting as good as possible before officially going live.
John.
>
>> ---
>> drivers/gpu/drm/xe/xe_guc_ct.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/xe/xe_guc_ct.c b/drivers/gpu/drm/xe/xe_guc_ct.c
>> index beeeb120d1fc..422c3f5c87d8 100644
>> --- a/drivers/gpu/drm/xe/xe_guc_ct.c
>> +++ b/drivers/gpu/drm/xe/xe_guc_ct.c
>> @@ -1515,7 +1515,7 @@ void xe_guc_ct_snapshot_print(struct xe_guc_ct_snapshot *snapshot,
>> drm_puts(p, "H2G CTB (all sizes in DW):\n");
>> guc_ctb_snapshot_print(&snapshot->h2g, p);
>>
>> - drm_puts(p, "\nG2H CTB (all sizes in DW):\n");
>> + drm_puts(p, "G2H CTB (all sizes in DW):\n");
>> guc_ctb_snapshot_print(&snapshot->g2h, p);
>>
>> drm_printf(p, "\tg2h outstanding: %d\n",
next prev parent reply other threads:[~2024-07-31 19:56 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-29 23:17 [PATCH v5 0/8] drm/xe/guc: Improve quality and robustness of GuC log dumping John.C.Harrison
2024-07-29 23:17 ` [PATCH v5 1/8] drm/xe/guc: Remove spurious line feed in debug print John.C.Harrison
2024-07-30 9:14 ` Michal Wajdeczko
2024-07-31 19:56 ` John Harrison [this message]
2024-07-31 20:14 ` Souza, Jose
2024-08-01 18:14 ` Matthew Brost
2024-08-05 18:18 ` John Harrison
2024-07-29 23:17 ` [PATCH v5 2/8] drm/xe/guc: Copy GuC log prior to dumping John.C.Harrison
2024-07-29 23:17 ` [PATCH v5 3/8] drm/xe/guc: Use a two stage dump for GuC logs and add more info John.C.Harrison
2024-07-29 23:17 ` [PATCH v5 4/8] drm/print: Introduce drm_line_printer John.C.Harrison
2024-07-29 23:17 ` [PATCH v5 5/8] drm/xe/guc: Add a helper function for dumping GuC log to dmesg John.C.Harrison
2024-07-29 23:17 ` [PATCH v5 6/8] drm/xe/guc: Dead CT helper John.C.Harrison
2024-07-29 23:17 ` [PATCH v5 7/8] drm/xe/guc: Dump entire CTB on errors John.C.Harrison
2024-07-29 23:17 ` [PATCH v5 8/8] drm/xe/guc: Add GuC log to devcoredump captures John.C.Harrison
2024-08-04 22:36 ` Matthew Brost
2024-08-05 18:41 ` John Harrison
2024-08-05 20:46 ` Matthew Brost
2024-07-29 23:24 ` ✓ CI.Patch_applied: success for drm/xe/guc: Improve quality and robustness of GuC log dumping (rev3) Patchwork
2024-07-29 23:24 ` ✗ CI.checkpatch: warning " Patchwork
2024-07-29 23:25 ` ✓ CI.KUnit: success " Patchwork
2024-07-29 23:37 ` ✓ CI.Build: " Patchwork
2024-07-29 23:39 ` ✗ CI.Hooks: failure " Patchwork
2024-07-29 23:41 ` ✗ CI.checksparse: warning " Patchwork
2024-07-30 0:00 ` ✓ CI.BAT: success " Patchwork
2024-07-30 3:36 ` ✗ CI.FULL: failure " Patchwork
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=a9ef6254-f428-47b7-827d-82ec94408ca2@intel.com \
--to=john.c.harrison@intel.com \
--cc=Intel-Xe@Lists.FreeDesktop.Org \
--cc=jose.souza@intel.com \
--cc=michal.wajdeczko@intel.com \
--cc=rodrigo.vivi@intel.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