Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Wajdeczko <michal.wajdeczko@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: <intel-xe@lists.freedesktop.org>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Thomas Hellstrom <thomas.hellstrom@intel.com>
Subject: Re: [PATCH 5/7] drm/xe: Define verbose debug macros
Date: Thu, 4 Sep 2025 00:19:33 +0200	[thread overview]
Message-ID: <da185812-efc4-4085-832a-3e10b6bc68a5@intel.com> (raw)
In-Reply-To: <z5gfl545upuwn2eg4didegof4xdj55rxmo4g65tswpbijgqykj@omcamj3erznn>



On 9/4/2025 12:06 AM, Lucas De Marchi wrote:
> On Wed, Sep 03, 2025 at 11:36:10PM +0200, Michal Wajdeczko wrote:
>> We might want to add (and in some cases already have) some debug
>> level messages that are too verbose and need to be guarded by the
>> CONFIG_DRM_XE_DEBUG. To simplify that define verbose variant of
>> our printk debug macros that will be compiled out on non-debug
>> builds, in same way like we already did with xe_asserts() macros.
> 
> thinking out loud... aren't we going too overboard with this?
> Looking at other places in the kernel we have pr_debug() and that's
> awesome as we can simply enable it via dyndbg when we want, with the
> granularity that matters for the issue we are looking at.

even if some dbg logs are disabled by default and not printing
anything until explicitly enabled by dyndbg or drm.debug flags,
they still add some code/text to the driver footprint.

and this patch just allows to add more logs for debug builds
and strip them in production where we know no one will use them

but still, this is just a proposal

> 
> Lucas De Marchi
> 
>>
>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>> ---
>> drivers/gpu/drm/xe/xe_gt_printk.h   | 6 ++++++
>> drivers/gpu/drm/xe/xe_printk.h      | 6 ++++++
>> drivers/gpu/drm/xe/xe_tile_printk.h | 6 ++++++
>> 3 files changed, 18 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/xe/xe_gt_printk.h b/drivers/gpu/drm/xe/xe_gt_printk.h
>> index 8dc4217ddb4e..69c4553d0f80 100644
>> --- a/drivers/gpu/drm/xe/xe_gt_printk.h
>> +++ b/drivers/gpu/drm/xe/xe_gt_printk.h
>> @@ -35,6 +35,12 @@
>> #define xe_gt_dbg(_gt, _fmt, ...) \
>>     xe_gt_printk((_gt), dbg, _fmt, ##__VA_ARGS__)
>>
>> +#if IS_ENABLED(CONFIG_DRM_XE_DEBUG)
>> +#define xe_gt_dbg_verbose        xe_gt_dbg
>> +#else
>> +#define xe_gt_dbg_verbose(_gt, ...)    typecheck(struct xe_gt *, (_gt))
>> +#endif
>> +
>> #define xe_gt_WARN_type(_gt, _type, _condition, _fmt, ...) \
>>     xe_tile_WARN##_type((_gt)->tile, _condition, _fmt, ## __VA_ARGS__)
>>
>> diff --git a/drivers/gpu/drm/xe/xe_printk.h b/drivers/gpu/drm/xe/xe_printk.h
>> index 691d3611b889..9ffa26c869da 100644
>> --- a/drivers/gpu/drm/xe/xe_printk.h
>> +++ b/drivers/gpu/drm/xe/xe_printk.h
>> @@ -36,6 +36,12 @@
>> #define xe_dbg(_xe, _fmt, ...) \
>>     xe_printk((_xe), dbg, _fmt, ##__VA_ARGS__)
>>
>> +#if IS_ENABLED(CONFIG_DRM_XE_DEBUG)
>> +#define xe_dbg_verbose            xe_dbg
>> +#else
>> +#define xe_dbg_verbose(_xe, ...)    typecheck(struct xe_device *, (_xe))
>> +#endif
>> +
>> #define xe_WARN_type(_xe, _type, _condition, _fmt, ...) \
>>     drm_WARN##_type(&(_xe)->drm, _condition, _fmt, ## __VA_ARGS__)
>>
>> diff --git a/drivers/gpu/drm/xe/xe_tile_printk.h b/drivers/gpu/drm/xe/xe_tile_printk.h
>> index ed951cdb08cb..33ebfd9722d3 100644
>> --- a/drivers/gpu/drm/xe/xe_tile_printk.h
>> +++ b/drivers/gpu/drm/xe/xe_tile_printk.h
>> @@ -34,6 +34,12 @@
>> #define xe_tile_dbg(_tile, _fmt, ...) \
>>     xe_tile_printk((_tile), dbg, _fmt, ##__VA_ARGS__)
>>
>> +#if IS_ENABLED(CONFIG_DRM_XE_DEBUG)
>> +#define xe_tile_dbg_verbose        xe_tile_dbg
>> +#else
>> +#define xe_tile_dbg_verbose(_tile, ...)    typecheck(struct xe_tile *, (_tile))
>> +#endif
>> +
>> #define xe_tile_WARN_type(_tile, _type, _condition, _fmt, ...) \
>>     xe_WARN##_type((_tile)->xe, _condition, _fmt, ## __VA_ARGS__)
>>
>> -- 
>> 2.47.1
>>


  reply	other threads:[~2025-09-03 22:19 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-03 21:36 [PATCH 0/7] RFC: Add dedicated printk macros for tile and device Michal Wajdeczko
2025-09-03 21:36 ` [PATCH 1/7] drm/xe: Keep xe_gt_err() macro definitions together Michal Wajdeczko
2025-09-03 21:59   ` Lucas De Marchi
2025-09-03 21:36 ` [PATCH 2/7] drm/xe: Drop "gt_" prefix from xe_gt_WARN() macros Michal Wajdeczko
2025-09-03 22:00   ` Lucas De Marchi
2025-09-03 21:36 ` [PATCH 3/7] drm/xe: Prepare format for GT-oriented messages in one place Michal Wajdeczko
2025-09-09 13:55   ` Rodrigo Vivi
2025-09-03 21:36 ` [PATCH 4/7] drm/xe: Add dedicated printk macros for tile and device Michal Wajdeczko
2025-09-09 13:57   ` Rodrigo Vivi
2025-09-03 21:36 ` [PATCH 5/7] drm/xe: Define verbose debug macros Michal Wajdeczko
2025-09-03 22:06   ` Lucas De Marchi
2025-09-03 22:19     ` Michal Wajdeczko [this message]
2025-09-09 14:01       ` Rodrigo Vivi
2025-09-03 21:36 ` [PATCH 6/7] drm/xe: Use tile-oriented messages in GGTT code Michal Wajdeczko
2025-09-09 13:58   ` Rodrigo Vivi
2025-09-03 21:36 ` [PATCH 7/7] drm/xe: Use tile-oriented messages in LMTT code Michal Wajdeczko
2025-09-09 13:58   ` Rodrigo Vivi
2025-09-03 21:43 ` ✗ CI.checkpatch: warning for RFC: Add dedicated printk macros for tile and device Patchwork
2025-09-03 21:44 ` ✓ CI.KUnit: success " Patchwork
2025-09-03 22:21 ` ✗ Xe.CI.BAT: failure " Patchwork
2025-09-04  4:49 ` ✗ Xe.CI.Full: " 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=da185812-efc4-4085-832a-3e10b6bc68a5@intel.com \
    --to=michal.wajdeczko@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=thomas.hellstrom@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