Re: [PATCH v2 5/5] drm/i915/display: Cover all possible pipes in TP_printk()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Quoting Ville Syrjälä (2024-09-23 17:18:39-03:00)
>On Mon, Sep 23, 2024 at 05:06:00PM -0300, Gustavo Sousa wrote:
>> Quoting Ville Syrjälä (2024-09-23 16:23:27-03:00)
>> >On Mon, Sep 23, 2024 at 04:02:54PM -0300, Gustavo Sousa wrote:
>> >> Tracepoints that display frame and scanline counters for all pipes were
>> >> added with commit 1489bba82433 ("drm/i915: Add cxsr toggle tracepoint")
>> >> and commit 0b2599a43ca9 ("drm/i915: Add pipe enable/disable
>> >> tracepoints"). At that time, we only had pipes A, B and C. Now that we
>> >> can also have pipe D, the TP_printk() calls are missing it.
>> >> 
>> >> As a quick and dirty fix for that, let's define two common macros to be
>> >> used for the format and values respectively, and also ensure we raise a
>> >> build bug if more pipes are added to enum pipe.
>> >> 
>> >> In the future, we should probably have a way of printing information for
>> >> available pipes only.
>> >> 
>> >> Cc: Matt Roper <matthew.d.roper@xxxxxxxxx>
>> >> Signed-off-by: Gustavo Sousa <gustavo.sousa@xxxxxxxxx>
>> >> ---
>> >>  .../drm/i915/display/intel_display_trace.h    | 43 +++++++++++++------
>> >>  1 file changed, 29 insertions(+), 14 deletions(-)
>> >> 
>> >> diff --git a/drivers/gpu/drm/i915/display/intel_display_trace.h b/drivers/gpu/drm/i915/display/intel_display_trace.h
>> >> index eec9aeddad96..9bd8f1e505b0 100644
>> >> --- a/drivers/gpu/drm/i915/display/intel_display_trace.h
>> >> +++ b/drivers/gpu/drm/i915/display/intel_display_trace.h
>> >> @@ -31,6 +31,29 @@
>> >>  #define _TRACE_PIPE_A        0
>> >>  #define _TRACE_PIPE_B        1
>> >>  #define _TRACE_PIPE_C        2
>> >> +#define _TRACE_PIPE_D        3
>> >> +
>> >> +/*
>> >> + * FIXME: Several TP_printk() calls below display frame and scanline numbers for
>> >> + * all possible pipes (regardless of whether they are available) and that is
>> >> + * done with a constant format string. A better approach would be to generate
>> >> + * that info dynamically based on available pipes, but, while we do not have
>> >> + * that implemented yet, let's assert that the constant format string indeed
>> >> + * covers all possible pipes.
>> >> + */
>> >> +static_assert(I915_MAX_PIPES - 1 == _TRACE_PIPE_D);
>> >> +
>> >> +#define _PIPES_FRAME_AND_SCANLINE_FMT                \
>> >> +        "pipe A: frame=%u, scanline=%u"                \
>> >> +        ", pipe B: frame=%u, scanline=%u"        \
>> >> +        ", pipe C: frame=%u, scanline=%u"        \
>> >> +        ", pipe D: frame=%u, scanline=%u"
>> >
>> >Hmm. We have a lot of tracpoints that just print these for a single
>> >pipe. Is there any decent way to make this macro just for one pipe,
>> >and then resuse it for all the tracepoints whether they trace one
>> >pipe or all of them?
>> 
>> Maybe what we could do is to have a local struct pipe_counters type
>> and have _PIPE_COUNTERS_FMT and _PIPE_COUNTERS_VALUES for it. Then they
>> could be used here as well as for the single-pipe cases.
>
>Can we use structs here or would that confuse trace-cmd as well?

Ugh... Right. I'm afraid that would not work indeed.

I quickly scammed through libtraceevent's event-parse.c and it looks
like it does not support that.

--
Gustavo Sousa




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux