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
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.