Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Gustavo Sousa <gustavo.sousa@intel.com>,
	Ville Syrjala <ville.syrjala@linux.intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 6/8] drm/i915/scaler: Pimp scaler debugs
Date: Mon, 30 Dec 2024 14:58:31 +0200	[thread overview]
Message-ID: <87a5cdpbt4.fsf@intel.com> (raw)
In-Reply-To: <173507271978.1822.13474225879621112042@intel.com>

On Tue, 24 Dec 2024, Gustavo Sousa <gustavo.sousa@intel.com> wrote:
> Quoting Ville Syrjala (2024-12-19 10:08:25-03:00)
>>From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>
>>Include the standard "[CRTC:...]" information in the scaler debugs
>>to make life easier.
>
> Drive-by comment (and going a bit off-topic):
>
>     $ git grep '\[[A-Z]\+:%d:%s]' -- drivers/gpu/drm | wc -l
>     600
>
> Has someone already considered creating DRM_*_FMT and DRM_*_ARG() for
> those? E.g. DRM_CRTC_FMT and CRM_CRTC_ARG(crtc->base), which, IMO, would
> be easier to use and arguably more concise.

Personally, I'm not in favour. I dislike having to concatenate the
string constants all over the place.

> I tried doing a quick search on lore.kernel.org/dri-devel, but I'm not
> sure what would be good search terms to find previous attempts to see
> possible arguments against it.

We've gone through this a number of times, and some of the other options
are:

- Add allocated debug string to the objects, e.g. crtc->debug or
  crtc->id and print it with %s. It also works when you want to print
  the info of e.g. both the connector and the encoder.

- Add function pointers for debug logging in the drm objects, and have
  the drm_dbg* family of functions use them based on the type passed to
  it with generics. You'd do drm_dbg_kms(connector, "foo\n"); and that
  would add the [CONNECTOR:...] prefix. Falls short when you want to
  print the info of multiple objects.

- Object specific debug logging macros. connector_dbg() etc. I'm
  strongly against the proliferation of logging macros. All the variants
  (like once, ratelimited, etc.) get multiplied by the number of object
  types. (Yes, I also dislike the gt/guc macros, but I digress.) And
  this also doesn't solve the logging of multiple objects at once.

- Add printk format specifiers. There's apparently no way to do this in
  a human readable way, as anything nice throws off compiler printf
  format checks. So you end up with stuff like %pXYZ where the XYZ are
  meaningless magic letters. And they'd need to be implemented in kernel
  core.


BR,
Jani.


>
> --
> Gustavo Sousa
>
>>
>>Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>---
>> drivers/gpu/drm/i915/display/skl_scaler.c | 25 +++++++++++++++--------
>> 1 file changed, 16 insertions(+), 9 deletions(-)
>>
>>diff --git a/drivers/gpu/drm/i915/display/skl_scaler.c b/drivers/gpu/drm/i915/display/skl_scaler.c
>>index cbc71e44fcbb..f6d76ef1a854 100644
>>--- a/drivers/gpu/drm/i915/display/skl_scaler.c
>>+++ b/drivers/gpu/drm/i915/display/skl_scaler.c
>>@@ -166,7 +166,8 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, bool force_detach,
>>         if (DISPLAY_VER(display) >= 9 && crtc_state->hw.enable &&
>>             need_scaler && adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE) {
>>                 drm_dbg_kms(display->drm,
>>-                            "Pipe/Plane scaling not supported with IF-ID mode\n");
>>+                            "[CRTC:%d:%s] scaling not supported with IF-ID mode\n",
>>+                            crtc->base.base.id, crtc->base.name);
>>                 return -EINVAL;
>>         }
>> 
>>@@ -186,8 +187,9 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, bool force_detach,
>>                         scaler_state->scalers[*scaler_id].in_use = false;
>> 
>>                         drm_dbg_kms(display->drm,
>>-                                    "scaler_user index %u.%u: "
>>+                                    "[CRTC:%d:%s] scaler_user index %u.%u: "
>>                                     "Staged freeing scaler id %d scaler_users = 0x%x\n",
>>+                                    crtc->base.base.id, crtc->base.name,
>>                                     crtc->pipe, scaler_user, *scaler_id,
>>                                     scaler_state->scaler_users);
>>                         *scaler_id = -1;
>>@@ -207,8 +209,9 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, bool force_detach,
>>             src_w > max_src_w || src_h > max_src_h ||
>>             dst_w > max_dst_w || dst_h > max_dst_h) {
>>                 drm_dbg_kms(display->drm,
>>-                            "scaler_user index %u.%u: src %ux%u dst %ux%u "
>>+                            "[CRTC:%d:%s] scaler_user index %u.%u: src %ux%u dst %ux%u "
>>                             "size is out of scaler range\n",
>>+                            crtc->base.base.id, crtc->base.name,
>>                             crtc->pipe, scaler_user, src_w, src_h,
>>                             dst_w, dst_h);
>>                 return -EINVAL;
>>@@ -224,16 +227,18 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, bool force_detach,
>>          */
>>         if (pipe_src_w > max_dst_w || pipe_src_h > max_dst_h) {
>>                 drm_dbg_kms(display->drm,
>>-                            "scaler_user index %u.%u: pipe src size %ux%u "
>>+                            "[CRTC:%d:%s] scaler_user index %u.%u: pipe src size %ux%u "
>>                             "is out of scaler range\n",
>>+                            crtc->base.base.id, crtc->base.name,
>>                             crtc->pipe, scaler_user, pipe_src_w, pipe_src_h);
>>                 return -EINVAL;
>>         }
>> 
>>         /* mark this plane as a scaler user in crtc_state */
>>         scaler_state->scaler_users |= (1 << scaler_user);
>>-        drm_dbg_kms(display->drm, "scaler_user index %u.%u: "
>>+        drm_dbg_kms(display->drm, "[CRTC:%d:%s] scaler_user index %u.%u: "
>>                     "staged scaling request for %ux%u->%ux%u scaler_users = 0x%x\n",
>>+                    crtc->base.base.id, crtc->base.name,
>>                     crtc->pipe, scaler_user, src_w, src_h, dst_w, dst_h,
>>                     scaler_state->scaler_users);
>> 
>>@@ -421,8 +426,8 @@ static int intel_atomic_setup_scaler(struct intel_crtc_scaler_state *scaler_stat
>> 
>>                 if (hscale < 0 || vscale < 0) {
>>                         drm_dbg_kms(display->drm,
>>-                                    "Scaler %d doesn't support required plane scaling\n",
>>-                                    *scaler_id);
>>+                                    "[CRTC:%d:%s] scaler %d doesn't support required plane scaling\n",
>>+                                    crtc->base.base.id, crtc->base.name, *scaler_id);
>>                         drm_rect_debug_print("src: ", src, true);
>>                         drm_rect_debug_print("dst: ", dst, false);
>> 
>>@@ -430,7 +435,8 @@ static int intel_atomic_setup_scaler(struct intel_crtc_scaler_state *scaler_stat
>>                 }
>>         }
>> 
>>-        drm_dbg_kms(display->drm, "Attached scaler id %u.%u to %s:%d\n",
>>+        drm_dbg_kms(display->drm, "[CRTC:%d:%s] attached scaler id %u.%u to %s:%d\n",
>>+                    crtc->base.base.id, crtc->base.name,
>>                     crtc->pipe, *scaler_id, name, idx);
>>         scaler_state->scalers[*scaler_id].mode = mode;
>> 
>>@@ -530,7 +536,8 @@ int intel_atomic_setup_scalers(struct intel_atomic_state *state,
>>         /* fail if required scalers > available scalers */
>>         if (num_scalers_need > crtc->num_scalers) {
>>                 drm_dbg_kms(display->drm,
>>-                            "Too many scaling requests %d > %d\n",
>>+                            "[CRTC:%d:%s] too many scaling requests %d > %d\n",
>>+                            crtc->base.base.id, crtc->base.name,
>>                             num_scalers_need, crtc->num_scalers);
>>                 return -EINVAL;
>>         }
>>-- 
>>2.45.2
>>

-- 
Jani Nikula, Intel

  reply	other threads:[~2024-12-30 12:58 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-19 13:08 [PATCH 0/8] drm/i915/scaler: Scaler cleanups and tracepoints Ville Syrjala
2024-12-19 13:08 ` [PATCH 1/8] drm/i915/scaler: Extract skl_scaler_min_src_size() Ville Syrjala
2024-12-20  8:47   ` Luca Coelho
2025-01-09 17:16     ` Ville Syrjälä
2024-12-19 13:08 ` [PATCH 2/8] drm/i915/scaler: Extract skl_scaler_max_src_size() Ville Syrjala
2024-12-20  8:47   ` Luca Coelho
2024-12-19 13:08 ` [PATCH 3/8] drm/i915/scaler: Extract skl_scaler_min_dst_size() Ville Syrjala
2024-12-20  8:50   ` Luca Coelho
2024-12-19 13:08 ` [PATCH 4/8] drm/i915/scaler: Extract skl_scaler_max_dst_size() Ville Syrjala
2024-12-20  8:52   ` Luca Coelho
2024-12-19 13:08 ` [PATCH 5/8] drm/i915/scaler: Nuke redundant code Ville Syrjala
2024-12-20  8:52   ` Luca Coelho
2024-12-19 13:08 ` [PATCH 6/8] drm/i915/scaler: Pimp scaler debugs Ville Syrjala
2024-12-20  8:55   ` Luca Coelho
2025-01-09 17:56     ` Ville Syrjälä
2024-12-24 20:38   ` Gustavo Sousa
2024-12-30 12:58     ` Jani Nikula [this message]
2024-12-31 12:56       ` Gustavo Sousa
2024-12-31 13:47         ` Jani Nikula
2024-12-19 13:08 ` [PATCH 7/8] drm/i915/scaler: s/excdeed/exceed/ Ville Syrjala
2024-12-20  8:55   ` Luca Coelho
2024-12-19 13:08 ` [PATCH 8/8] drm/i915/scaler: Add scaler tracepoints Ville Syrjala
2024-12-20  9:12   ` Luca Coelho
2024-12-19 14:26 ` ✗ Fi.CI.CHECKPATCH: warning for drm/i915/scaler: Scaler cleanups and tracepoints Patchwork
2024-12-19 14:40 ` ✓ i915.CI.BAT: success " Patchwork
2024-12-20  8:23 ` ✗ i915.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=87a5cdpbt4.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=gustavo.sousa@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ville.syrjala@linux.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