2021-12-08 13:05:17 +02:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0 */
|
|
|
|
/*
|
|
|
|
* Copyright © 2021 Intel Corporation
|
|
|
|
*/
|
|
|
|
|
|
|
|
#undef TRACE_SYSTEM
|
2025-01-27 23:30:55 +02:00
|
|
|
#ifdef I915
|
2021-12-08 13:05:17 +02:00
|
|
|
#define TRACE_SYSTEM i915
|
2025-01-27 23:30:55 +02:00
|
|
|
#else
|
|
|
|
#define TRACE_SYSTEM xe
|
|
|
|
#endif
|
2021-12-08 13:05:17 +02:00
|
|
|
|
|
|
|
#if !defined(__INTEL_DISPLAY_TRACE_H__) || defined(TRACE_HEADER_MULTI_READ)
|
|
|
|
#define __INTEL_DISPLAY_TRACE_H__
|
|
|
|
|
2024-10-16 10:52:28 -03:00
|
|
|
#include <linux/string.h>
|
2022-02-25 15:46:31 -08:00
|
|
|
#include <linux/string_helpers.h>
|
2021-12-08 13:05:17 +02:00
|
|
|
#include <linux/types.h>
|
|
|
|
#include <linux/tracepoint.h>
|
|
|
|
|
|
|
|
#include "intel_crtc.h"
|
2024-11-20 14:03:37 +02:00
|
|
|
#include "intel_display_core.h"
|
drm/i915/display: Fix out-of-bounds access in pipe-related tracepoints
Some display trace events use array members to store frame and scanline
counts for each pipe. However, those arrays are declared with 3 as the
hardcoded size, which cause out-of-bounds access when the trace event is
enabled on a platform that contains pipe D.
For example, when looking at the last 10 intel_pipe_enable events after
running IGT's testdisplay, we see the following on a MTL machine that
has pipe D available:
$ trace-cmd report -R -F intel_pipe_enable \
> | tail \
> | sed 's,\(frame=.*\) \(scanline=.*\),\n\t \1\n\t\2,'
testdisplay-6715 [002] 17591.063491: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[83, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [003] 17591.264742: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[89, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [003] 17591.464541: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[8f, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [001] 17591.695827: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[95, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [000] 17591.915841: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[9a, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [000] 17592.127114: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[a0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [002] 17592.358351: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[a8, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [002] 17592.580467: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[ae, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [000] 17592.950946: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[b8, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [004] 17593.079597: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[bf, 01, 00, 00, 01, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 3a, 04, 00, 00, 00, 00, 00, 00] pipe=1
Which shows zeros for pipe A's scanline counts. That happens because
pipe D's frame counts are overwriting them.
Let's fix that by making the arrays bring able to store info for all
possible pipes.
With the fix, we get the following:
$ trace-cmd report -R -F intel_pipe_enable \
> | tail \
> | sed 's,\(frame=.*\) \(scanline=.*\),\n\t \1\n\t\2,'
testdisplay-7040 [003] 18067.489565: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[8c, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[8e, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [002] 18067.699312: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[92, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[58, 02, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [002] 18067.908868: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[98, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[58, 02, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [002] 18068.122802: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[9d, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[58, 02, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [003] 18068.331019: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[a2, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [002] 18068.529067: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[a8, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [003] 18068.742033: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[ae, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [002] 18068.956229: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[b3, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[1f, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [002] 18069.295322: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[bb, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[7b, 08, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [010] 18069.423527: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[c2, 01, 00, 00, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[d0, 05, 00, 00, 3a, 04, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=1
Which makes more sense now.
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-2-gustavo.sousa@intel.com
2024-10-16 10:52:27 -03:00
|
|
|
#include "intel_display_limits.h"
|
2021-12-08 13:05:17 +02:00
|
|
|
#include "intel_display_types.h"
|
2023-01-16 14:56:12 +02:00
|
|
|
#include "intel_vblank.h"
|
2021-12-08 13:05:17 +02:00
|
|
|
|
2024-09-04 16:06:33 +03:00
|
|
|
#define __dev_name_display(display) dev_name((display)->drm->dev)
|
2024-12-18 19:36:49 +02:00
|
|
|
#define __dev_name_drm(obj) dev_name((obj)->dev->dev)
|
2022-11-11 14:31:20 +02:00
|
|
|
#define __dev_name_kms(obj) dev_name((obj)->base.dev->dev)
|
|
|
|
|
drm/i915/display: Do not use ids from enum pipe in TP_printk()
Because much of kernel tracepoints is implemented at the C preprocessor
level, C identifiers used in TP_printk() are saved verbatim in the event
format, even when they represent compile-time constant values.
As an example, we can look at the format for the intel_pipe_enable
event:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_enable/format | grep '^print fmt'
print fmt: "dev %s, pipe %c enable, pipe A: frame=%u, scanline=%u, pipe B: frame=%u, scanline=%u, pipe C: frame=%u, scanline=%u", __get_str(dev), REC->pipe_name, REC->frame[PIPE_A], REC->scanline[PIPE_A], REC->frame[PIPE_B], REC->scanline[PIPE_B], REC->frame[PIPE_C], REC->scanline[PIPE_C]
We see that PIPE_A, PIPE_B and PIPE_C are pasted directly in the format.
Because tools that interact with kernel tracepoints don't know about
those ids, they'll endup failing to parse the format or produce
corrupted output.
For example, we can see below that trace-cmd repeats PIPE_A's
frame/scanline counts for all pipes (probably because it evaluates
unknown ids as zero):
$ trace-cmd report -F intel_pipe_enable | tail -n5
testdisplay-8616 [000] 22048.276758: intel_pipe_enable: dev 0000:00:02.0, pipe A enable, pipe A: frame=861, scanline=480, pipe B: frame=861, scanline=480, pipe C: frame=861, scanline=480
testdisplay-8616 [001] 22048.490287: intel_pipe_enable: dev 0000:00:02.0, pipe A enable, pipe A: frame=867, scanline=480, pipe B: frame=867, scanline=480, pipe C: frame=867, scanline=480
testdisplay-8616 [003] 22048.700181: intel_pipe_enable: dev 0000:00:02.0, pipe A enable, pipe A: frame=872, scanline=400, pipe B: frame=872, scanline=400, pipe C: frame=872, scanline=400
testdisplay-8616 [002] 22049.054220: intel_pipe_enable: dev 0000:00:02.0, pipe A enable, pipe A: frame=881, scanline=2170, pipe B: frame=881, scanline=2170, pipe C: frame=881, scanline=2170
testdisplay-8616 [002] 22049.166851: intel_pipe_enable: dev 0000:00:02.0, pipe B enable, pipe A: frame=887, scanline=1632, pipe B: frame=887, scanline=1632, pipe C: frame=887, scanline=1632
, while in fact we have different values for each pipe, which can be
confirmed with the raw view of the events:
$ trace-cmd report -R -F intel_pipe_enable | tail -n5
testdisplay-8616 [000] 22048.276758: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[5d, 03, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe_name=A
testdisplay-8616 [001] 22048.490287: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[63, 03, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe_name=A
testdisplay-8616 [003] 22048.700181: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[68, 03, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[90, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe_name=A
testdisplay-8616 [002] 22049.054220: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[71, 03, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[7a, 08, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe_name=A
testdisplay-8616 [002] 22049.166851: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[77, 03, 00, 00, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[60, 06, 00, 00, 39, 04, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe_name=B
To fix that, we need a fix that looks more like a hack: use macros that
result to integer constants instead of enum pipe values. This fixes the
issue, but could break if, for whatever unlikely reason, the underlying
values in the enum are changed.
In the future, we should find a better way to handle this, but for now,
the hack took care of the job:
$ trace-cmd report -F intel_pipe_enable | tail -n5
testdisplay-9224 [003] 24324.455375: intel_pipe_enable: dev 0000:00:02.0, pipe A enable, pipe A: frame=1103, scanline=480, pipe B: frame=0, scanline=0, pipe C: frame=0, scanline=0
testdisplay-9224 [002] 24324.669845: intel_pipe_enable: dev 0000:00:02.0, pipe A enable, pipe A: frame=1109, scanline=480, pipe B: frame=0, scanline=0, pipe C: frame=0, scanline=0
testdisplay-9224 [003] 24324.900105: intel_pipe_enable: dev 0000:00:02.0, pipe A enable, pipe A: frame=1115, scanline=31, pipe B: frame=0, scanline=0, pipe C: frame=0, scanline=0
testdisplay-9224 [002] 24325.256408: intel_pipe_enable: dev 0000:00:02.0, pipe A enable, pipe A: frame=1124, scanline=2171, pipe B: frame=0, scanline=0, pipe C: frame=0, scanline=0
testdisplay-9224 [003] 24325.380789: intel_pipe_enable: dev 0000:00:02.0, pipe B enable, pipe A: frame=1131, scanline=979, pipe B: frame=1, scanline=1082, pipe C: frame=0, scanline=0
v2:
- Statically assert that PIPE_A == _TRACE_PIPE_A. (MattR)
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-5-gustavo.sousa@intel.com
2024-10-16 10:52:30 -03:00
|
|
|
/*
|
|
|
|
* Using identifiers from enum pipe in TP_printk() will confuse tools that
|
|
|
|
* parse /sys/kernel/debug/tracing/{xe,i915}/<event>/format. So we use CPP
|
|
|
|
* macros instead.
|
|
|
|
*/
|
|
|
|
#define _TRACE_PIPE_A 0
|
|
|
|
#define _TRACE_PIPE_B 1
|
|
|
|
#define _TRACE_PIPE_C 2
|
2024-10-16 10:52:31 -03:00
|
|
|
#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"
|
|
|
|
|
|
|
|
#define _PIPES_FRAME_AND_SCANLINE_VALUES \
|
|
|
|
__entry->frame[_TRACE_PIPE_A], __entry->scanline[_TRACE_PIPE_A] \
|
|
|
|
, __entry->frame[_TRACE_PIPE_B], __entry->scanline[_TRACE_PIPE_B] \
|
|
|
|
, __entry->frame[_TRACE_PIPE_C], __entry->scanline[_TRACE_PIPE_C] \
|
|
|
|
, __entry->frame[_TRACE_PIPE_D], __entry->scanline[_TRACE_PIPE_D]
|
drm/i915/display: Do not use ids from enum pipe in TP_printk()
Because much of kernel tracepoints is implemented at the C preprocessor
level, C identifiers used in TP_printk() are saved verbatim in the event
format, even when they represent compile-time constant values.
As an example, we can look at the format for the intel_pipe_enable
event:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_enable/format | grep '^print fmt'
print fmt: "dev %s, pipe %c enable, pipe A: frame=%u, scanline=%u, pipe B: frame=%u, scanline=%u, pipe C: frame=%u, scanline=%u", __get_str(dev), REC->pipe_name, REC->frame[PIPE_A], REC->scanline[PIPE_A], REC->frame[PIPE_B], REC->scanline[PIPE_B], REC->frame[PIPE_C], REC->scanline[PIPE_C]
We see that PIPE_A, PIPE_B and PIPE_C are pasted directly in the format.
Because tools that interact with kernel tracepoints don't know about
those ids, they'll endup failing to parse the format or produce
corrupted output.
For example, we can see below that trace-cmd repeats PIPE_A's
frame/scanline counts for all pipes (probably because it evaluates
unknown ids as zero):
$ trace-cmd report -F intel_pipe_enable | tail -n5
testdisplay-8616 [000] 22048.276758: intel_pipe_enable: dev 0000:00:02.0, pipe A enable, pipe A: frame=861, scanline=480, pipe B: frame=861, scanline=480, pipe C: frame=861, scanline=480
testdisplay-8616 [001] 22048.490287: intel_pipe_enable: dev 0000:00:02.0, pipe A enable, pipe A: frame=867, scanline=480, pipe B: frame=867, scanline=480, pipe C: frame=867, scanline=480
testdisplay-8616 [003] 22048.700181: intel_pipe_enable: dev 0000:00:02.0, pipe A enable, pipe A: frame=872, scanline=400, pipe B: frame=872, scanline=400, pipe C: frame=872, scanline=400
testdisplay-8616 [002] 22049.054220: intel_pipe_enable: dev 0000:00:02.0, pipe A enable, pipe A: frame=881, scanline=2170, pipe B: frame=881, scanline=2170, pipe C: frame=881, scanline=2170
testdisplay-8616 [002] 22049.166851: intel_pipe_enable: dev 0000:00:02.0, pipe B enable, pipe A: frame=887, scanline=1632, pipe B: frame=887, scanline=1632, pipe C: frame=887, scanline=1632
, while in fact we have different values for each pipe, which can be
confirmed with the raw view of the events:
$ trace-cmd report -R -F intel_pipe_enable | tail -n5
testdisplay-8616 [000] 22048.276758: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[5d, 03, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe_name=A
testdisplay-8616 [001] 22048.490287: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[63, 03, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe_name=A
testdisplay-8616 [003] 22048.700181: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[68, 03, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[90, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe_name=A
testdisplay-8616 [002] 22049.054220: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[71, 03, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[7a, 08, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe_name=A
testdisplay-8616 [002] 22049.166851: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[77, 03, 00, 00, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[60, 06, 00, 00, 39, 04, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe_name=B
To fix that, we need a fix that looks more like a hack: use macros that
result to integer constants instead of enum pipe values. This fixes the
issue, but could break if, for whatever unlikely reason, the underlying
values in the enum are changed.
In the future, we should find a better way to handle this, but for now,
the hack took care of the job:
$ trace-cmd report -F intel_pipe_enable | tail -n5
testdisplay-9224 [003] 24324.455375: intel_pipe_enable: dev 0000:00:02.0, pipe A enable, pipe A: frame=1103, scanline=480, pipe B: frame=0, scanline=0, pipe C: frame=0, scanline=0
testdisplay-9224 [002] 24324.669845: intel_pipe_enable: dev 0000:00:02.0, pipe A enable, pipe A: frame=1109, scanline=480, pipe B: frame=0, scanline=0, pipe C: frame=0, scanline=0
testdisplay-9224 [003] 24324.900105: intel_pipe_enable: dev 0000:00:02.0, pipe A enable, pipe A: frame=1115, scanline=31, pipe B: frame=0, scanline=0, pipe C: frame=0, scanline=0
testdisplay-9224 [002] 24325.256408: intel_pipe_enable: dev 0000:00:02.0, pipe A enable, pipe A: frame=1124, scanline=2171, pipe B: frame=0, scanline=0, pipe C: frame=0, scanline=0
testdisplay-9224 [003] 24325.380789: intel_pipe_enable: dev 0000:00:02.0, pipe B enable, pipe A: frame=1131, scanline=979, pipe B: frame=1, scanline=1082, pipe C: frame=0, scanline=0
v2:
- Statically assert that PIPE_A == _TRACE_PIPE_A. (MattR)
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-5-gustavo.sousa@intel.com
2024-10-16 10:52:30 -03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Paranoid sanity check that at least the enumeration starts at the
|
|
|
|
* same value as _TRACE_PIPE_A.
|
|
|
|
*/
|
|
|
|
static_assert(PIPE_A == _TRACE_PIPE_A);
|
|
|
|
|
2021-12-08 13:05:17 +02:00
|
|
|
TRACE_EVENT(intel_pipe_enable,
|
|
|
|
TP_PROTO(struct intel_crtc *crtc),
|
|
|
|
TP_ARGS(crtc),
|
|
|
|
|
|
|
|
TP_STRUCT__entry(
|
2022-11-11 14:31:20 +02:00
|
|
|
__string(dev, __dev_name_kms(crtc))
|
drm/i915/display: Fix out-of-bounds access in pipe-related tracepoints
Some display trace events use array members to store frame and scanline
counts for each pipe. However, those arrays are declared with 3 as the
hardcoded size, which cause out-of-bounds access when the trace event is
enabled on a platform that contains pipe D.
For example, when looking at the last 10 intel_pipe_enable events after
running IGT's testdisplay, we see the following on a MTL machine that
has pipe D available:
$ trace-cmd report -R -F intel_pipe_enable \
> | tail \
> | sed 's,\(frame=.*\) \(scanline=.*\),\n\t \1\n\t\2,'
testdisplay-6715 [002] 17591.063491: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[83, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [003] 17591.264742: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[89, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [003] 17591.464541: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[8f, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [001] 17591.695827: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[95, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [000] 17591.915841: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[9a, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [000] 17592.127114: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[a0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [002] 17592.358351: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[a8, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [002] 17592.580467: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[ae, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [000] 17592.950946: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[b8, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [004] 17593.079597: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[bf, 01, 00, 00, 01, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 3a, 04, 00, 00, 00, 00, 00, 00] pipe=1
Which shows zeros for pipe A's scanline counts. That happens because
pipe D's frame counts are overwriting them.
Let's fix that by making the arrays bring able to store info for all
possible pipes.
With the fix, we get the following:
$ trace-cmd report -R -F intel_pipe_enable \
> | tail \
> | sed 's,\(frame=.*\) \(scanline=.*\),\n\t \1\n\t\2,'
testdisplay-7040 [003] 18067.489565: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[8c, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[8e, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [002] 18067.699312: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[92, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[58, 02, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [002] 18067.908868: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[98, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[58, 02, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [002] 18068.122802: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[9d, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[58, 02, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [003] 18068.331019: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[a2, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [002] 18068.529067: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[a8, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [003] 18068.742033: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[ae, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [002] 18068.956229: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[b3, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[1f, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [002] 18069.295322: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[bb, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[7b, 08, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [010] 18069.423527: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[c2, 01, 00, 00, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[d0, 05, 00, 00, 3a, 04, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=1
Which makes more sense now.
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-2-gustavo.sousa@intel.com
2024-10-16 10:52:27 -03:00
|
|
|
__array(u32, frame, I915_MAX_PIPES)
|
|
|
|
__array(u32, scanline, I915_MAX_PIPES)
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__field(char, pipe_name)
|
2021-12-08 13:05:17 +02:00
|
|
|
),
|
|
|
|
TP_fast_assign(
|
2024-09-04 16:06:33 +03:00
|
|
|
struct intel_display *display = to_intel_display(crtc);
|
2021-12-08 13:05:17 +02:00
|
|
|
struct intel_crtc *it__;
|
2024-05-16 13:34:54 -04:00
|
|
|
__assign_str(dev);
|
2024-10-16 10:52:28 -03:00
|
|
|
memset(__entry->frame, 0,
|
|
|
|
sizeof(__entry->frame[0]) * I915_MAX_PIPES);
|
|
|
|
memset(__entry->scanline, 0,
|
|
|
|
sizeof(__entry->scanline[0]) * I915_MAX_PIPES);
|
2024-09-04 16:06:33 +03:00
|
|
|
for_each_intel_crtc(display->drm, it__) {
|
2021-12-08 13:05:17 +02:00
|
|
|
__entry->frame[it__->pipe] = intel_crtc_get_vblank_counter(it__);
|
|
|
|
__entry->scanline[it__->pipe] = intel_get_crtc_scanline(it__);
|
|
|
|
}
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__entry->pipe_name = pipe_name(crtc->pipe);
|
2021-12-08 13:05:17 +02:00
|
|
|
),
|
|
|
|
|
2024-10-16 10:52:31 -03:00
|
|
|
TP_printk("dev %s, pipe %c enable, " _PIPES_FRAME_AND_SCANLINE_FMT,
|
|
|
|
__get_str(dev), __entry->pipe_name, _PIPES_FRAME_AND_SCANLINE_VALUES)
|
2021-12-08 13:05:17 +02:00
|
|
|
);
|
|
|
|
|
|
|
|
TRACE_EVENT(intel_pipe_disable,
|
|
|
|
TP_PROTO(struct intel_crtc *crtc),
|
|
|
|
TP_ARGS(crtc),
|
|
|
|
|
|
|
|
TP_STRUCT__entry(
|
2022-11-11 14:31:20 +02:00
|
|
|
__string(dev, __dev_name_kms(crtc))
|
drm/i915/display: Fix out-of-bounds access in pipe-related tracepoints
Some display trace events use array members to store frame and scanline
counts for each pipe. However, those arrays are declared with 3 as the
hardcoded size, which cause out-of-bounds access when the trace event is
enabled on a platform that contains pipe D.
For example, when looking at the last 10 intel_pipe_enable events after
running IGT's testdisplay, we see the following on a MTL machine that
has pipe D available:
$ trace-cmd report -R -F intel_pipe_enable \
> | tail \
> | sed 's,\(frame=.*\) \(scanline=.*\),\n\t \1\n\t\2,'
testdisplay-6715 [002] 17591.063491: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[83, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [003] 17591.264742: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[89, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [003] 17591.464541: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[8f, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [001] 17591.695827: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[95, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [000] 17591.915841: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[9a, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [000] 17592.127114: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[a0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [002] 17592.358351: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[a8, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [002] 17592.580467: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[ae, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [000] 17592.950946: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[b8, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [004] 17593.079597: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[bf, 01, 00, 00, 01, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 3a, 04, 00, 00, 00, 00, 00, 00] pipe=1
Which shows zeros for pipe A's scanline counts. That happens because
pipe D's frame counts are overwriting them.
Let's fix that by making the arrays bring able to store info for all
possible pipes.
With the fix, we get the following:
$ trace-cmd report -R -F intel_pipe_enable \
> | tail \
> | sed 's,\(frame=.*\) \(scanline=.*\),\n\t \1\n\t\2,'
testdisplay-7040 [003] 18067.489565: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[8c, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[8e, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [002] 18067.699312: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[92, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[58, 02, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [002] 18067.908868: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[98, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[58, 02, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [002] 18068.122802: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[9d, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[58, 02, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [003] 18068.331019: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[a2, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [002] 18068.529067: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[a8, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [003] 18068.742033: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[ae, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [002] 18068.956229: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[b3, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[1f, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [002] 18069.295322: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[bb, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[7b, 08, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [010] 18069.423527: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[c2, 01, 00, 00, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[d0, 05, 00, 00, 3a, 04, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=1
Which makes more sense now.
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-2-gustavo.sousa@intel.com
2024-10-16 10:52:27 -03:00
|
|
|
__array(u32, frame, I915_MAX_PIPES)
|
|
|
|
__array(u32, scanline, I915_MAX_PIPES)
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__field(char, pipe_name)
|
2021-12-08 13:05:17 +02:00
|
|
|
),
|
|
|
|
|
|
|
|
TP_fast_assign(
|
2024-09-04 16:06:33 +03:00
|
|
|
struct intel_display *display = to_intel_display(crtc);
|
2021-12-08 13:05:17 +02:00
|
|
|
struct intel_crtc *it__;
|
2024-05-16 13:34:54 -04:00
|
|
|
__assign_str(dev);
|
2024-10-16 10:52:28 -03:00
|
|
|
memset(__entry->frame, 0,
|
|
|
|
sizeof(__entry->frame[0]) * I915_MAX_PIPES);
|
|
|
|
memset(__entry->scanline, 0,
|
|
|
|
sizeof(__entry->scanline[0]) * I915_MAX_PIPES);
|
2024-09-04 16:06:33 +03:00
|
|
|
for_each_intel_crtc(display->drm, it__) {
|
2021-12-08 13:05:17 +02:00
|
|
|
__entry->frame[it__->pipe] = intel_crtc_get_vblank_counter(it__);
|
|
|
|
__entry->scanline[it__->pipe] = intel_get_crtc_scanline(it__);
|
|
|
|
}
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__entry->pipe_name = pipe_name(crtc->pipe);
|
2021-12-08 13:05:17 +02:00
|
|
|
),
|
|
|
|
|
2024-10-16 10:52:31 -03:00
|
|
|
TP_printk("dev %s, pipe %c disable, " _PIPES_FRAME_AND_SCANLINE_FMT,
|
|
|
|
__get_str(dev), __entry->pipe_name, _PIPES_FRAME_AND_SCANLINE_VALUES)
|
2021-12-08 13:05:17 +02:00
|
|
|
);
|
|
|
|
|
2024-06-11 16:33:36 +03:00
|
|
|
TRACE_EVENT(intel_crtc_flip_done,
|
|
|
|
TP_PROTO(struct intel_crtc *crtc),
|
|
|
|
TP_ARGS(crtc),
|
|
|
|
|
|
|
|
TP_STRUCT__entry(
|
|
|
|
__string(dev, __dev_name_kms(crtc))
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__field(char, pipe_name)
|
2024-06-11 16:33:36 +03:00
|
|
|
__field(u32, frame)
|
|
|
|
__field(u32, scanline)
|
|
|
|
),
|
|
|
|
|
|
|
|
TP_fast_assign(
|
|
|
|
__assign_str(dev);
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__entry->pipe_name = pipe_name(crtc->pipe);
|
2024-06-11 16:33:36 +03:00
|
|
|
__entry->frame = intel_crtc_get_vblank_counter(crtc);
|
|
|
|
__entry->scanline = intel_get_crtc_scanline(crtc);
|
|
|
|
),
|
|
|
|
|
|
|
|
TP_printk("dev %s, pipe %c, frame=%u, scanline=%u",
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__get_str(dev), __entry->pipe_name,
|
2024-06-11 16:33:36 +03:00
|
|
|
__entry->frame, __entry->scanline)
|
|
|
|
);
|
|
|
|
|
2021-12-08 13:05:17 +02:00
|
|
|
TRACE_EVENT(intel_pipe_crc,
|
|
|
|
TP_PROTO(struct intel_crtc *crtc, const u32 *crcs),
|
|
|
|
TP_ARGS(crtc, crcs),
|
|
|
|
|
|
|
|
TP_STRUCT__entry(
|
2022-11-11 14:31:20 +02:00
|
|
|
__string(dev, __dev_name_kms(crtc))
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__field(char, pipe_name)
|
2021-12-08 13:05:17 +02:00
|
|
|
__field(u32, frame)
|
|
|
|
__field(u32, scanline)
|
|
|
|
__array(u32, crcs, 5)
|
|
|
|
),
|
|
|
|
|
|
|
|
TP_fast_assign(
|
2024-05-16 13:34:54 -04:00
|
|
|
__assign_str(dev);
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__entry->pipe_name = pipe_name(crtc->pipe);
|
2021-12-08 13:05:17 +02:00
|
|
|
__entry->frame = intel_crtc_get_vblank_counter(crtc);
|
|
|
|
__entry->scanline = intel_get_crtc_scanline(crtc);
|
|
|
|
memcpy(__entry->crcs, crcs, sizeof(__entry->crcs));
|
|
|
|
),
|
|
|
|
|
2022-11-11 14:31:20 +02:00
|
|
|
TP_printk("dev %s, pipe %c, frame=%u, scanline=%u crc=%08x %08x %08x %08x %08x",
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__get_str(dev), __entry->pipe_name,
|
2022-11-11 14:31:20 +02:00
|
|
|
__entry->frame, __entry->scanline,
|
|
|
|
__entry->crcs[0], __entry->crcs[1],
|
|
|
|
__entry->crcs[2], __entry->crcs[3],
|
|
|
|
__entry->crcs[4])
|
2021-12-08 13:05:17 +02:00
|
|
|
);
|
|
|
|
|
|
|
|
TRACE_EVENT(intel_cpu_fifo_underrun,
|
2024-09-04 16:06:33 +03:00
|
|
|
TP_PROTO(struct intel_display *display, enum pipe pipe),
|
|
|
|
TP_ARGS(display, pipe),
|
2021-12-08 13:05:17 +02:00
|
|
|
|
|
|
|
TP_STRUCT__entry(
|
2024-09-04 16:06:33 +03:00
|
|
|
__string(dev, __dev_name_display(display))
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__field(char, pipe_name)
|
2021-12-08 13:05:17 +02:00
|
|
|
__field(u32, frame)
|
|
|
|
__field(u32, scanline)
|
|
|
|
),
|
|
|
|
|
|
|
|
TP_fast_assign(
|
2024-09-04 16:06:32 +03:00
|
|
|
struct intel_crtc *crtc = intel_crtc_for_pipe(display, pipe);
|
2024-05-16 13:34:54 -04:00
|
|
|
__assign_str(dev);
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__entry->pipe_name = pipe_name(pipe);
|
2021-12-08 13:05:17 +02:00
|
|
|
__entry->frame = intel_crtc_get_vblank_counter(crtc);
|
|
|
|
__entry->scanline = intel_get_crtc_scanline(crtc);
|
|
|
|
),
|
|
|
|
|
2022-11-11 14:31:20 +02:00
|
|
|
TP_printk("dev %s, pipe %c, frame=%u, scanline=%u",
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__get_str(dev), __entry->pipe_name,
|
2021-12-08 13:05:17 +02:00
|
|
|
__entry->frame, __entry->scanline)
|
|
|
|
);
|
|
|
|
|
|
|
|
TRACE_EVENT(intel_pch_fifo_underrun,
|
2024-09-04 16:06:33 +03:00
|
|
|
TP_PROTO(struct intel_display *display, enum pipe pch_transcoder),
|
|
|
|
TP_ARGS(display, pch_transcoder),
|
2021-12-08 13:05:17 +02:00
|
|
|
|
|
|
|
TP_STRUCT__entry(
|
2024-09-04 16:06:33 +03:00
|
|
|
__string(dev, __dev_name_display(display))
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__field(char, pipe_name)
|
2021-12-08 13:05:17 +02:00
|
|
|
__field(u32, frame)
|
|
|
|
__field(u32, scanline)
|
|
|
|
),
|
|
|
|
|
|
|
|
TP_fast_assign(
|
|
|
|
enum pipe pipe = pch_transcoder;
|
2024-09-04 16:06:32 +03:00
|
|
|
struct intel_crtc *crtc = intel_crtc_for_pipe(display, pipe);
|
2024-05-16 13:34:54 -04:00
|
|
|
__assign_str(dev);
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__entry->pipe_name = pipe_name(pipe);
|
2021-12-08 13:05:17 +02:00
|
|
|
__entry->frame = intel_crtc_get_vblank_counter(crtc);
|
|
|
|
__entry->scanline = intel_get_crtc_scanline(crtc);
|
|
|
|
),
|
|
|
|
|
2022-11-11 14:31:20 +02:00
|
|
|
TP_printk("dev %s, pch transcoder %c, frame=%u, scanline=%u",
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__get_str(dev), __entry->pipe_name,
|
2021-12-08 13:05:17 +02:00
|
|
|
__entry->frame, __entry->scanline)
|
|
|
|
);
|
|
|
|
|
|
|
|
TRACE_EVENT(intel_memory_cxsr,
|
2024-09-04 16:06:33 +03:00
|
|
|
TP_PROTO(struct intel_display *display, bool old, bool new),
|
|
|
|
TP_ARGS(display, old, new),
|
2021-12-08 13:05:17 +02:00
|
|
|
|
|
|
|
TP_STRUCT__entry(
|
2024-09-04 16:06:33 +03:00
|
|
|
__string(dev, __dev_name_display(display))
|
drm/i915/display: Fix out-of-bounds access in pipe-related tracepoints
Some display trace events use array members to store frame and scanline
counts for each pipe. However, those arrays are declared with 3 as the
hardcoded size, which cause out-of-bounds access when the trace event is
enabled on a platform that contains pipe D.
For example, when looking at the last 10 intel_pipe_enable events after
running IGT's testdisplay, we see the following on a MTL machine that
has pipe D available:
$ trace-cmd report -R -F intel_pipe_enable \
> | tail \
> | sed 's,\(frame=.*\) \(scanline=.*\),\n\t \1\n\t\2,'
testdisplay-6715 [002] 17591.063491: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[83, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [003] 17591.264742: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[89, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [003] 17591.464541: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[8f, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [001] 17591.695827: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[95, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [000] 17591.915841: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[9a, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [000] 17592.127114: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[a0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [002] 17592.358351: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[a8, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [002] 17592.580467: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[ae, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [000] 17592.950946: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[b8, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-6715 [004] 17593.079597: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[bf, 01, 00, 00, 01, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[00, 00, 00, 00, 3a, 04, 00, 00, 00, 00, 00, 00] pipe=1
Which shows zeros for pipe A's scanline counts. That happens because
pipe D's frame counts are overwriting them.
Let's fix that by making the arrays bring able to store info for all
possible pipes.
With the fix, we get the following:
$ trace-cmd report -R -F intel_pipe_enable \
> | tail \
> | sed 's,\(frame=.*\) \(scanline=.*\),\n\t \1\n\t\2,'
testdisplay-7040 [003] 18067.489565: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[8c, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[8e, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [002] 18067.699312: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[92, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[58, 02, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [002] 18067.908868: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[98, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[58, 02, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [002] 18068.122802: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[9d, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[58, 02, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [003] 18068.331019: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[a2, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [002] 18068.529067: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[a8, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [003] 18068.742033: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[ae, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [002] 18068.956229: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[b3, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[1f, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [002] 18069.295322: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[bb, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[7b, 08, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
testdisplay-7040 [010] 18069.423527: intel_pipe_enable: dev=0000:00:02.0
frame=ARRAY[c2, 01, 00, 00, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
scanline=ARRAY[d0, 05, 00, 00, 3a, 04, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=1
Which makes more sense now.
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-2-gustavo.sousa@intel.com
2024-10-16 10:52:27 -03:00
|
|
|
__array(u32, frame, I915_MAX_PIPES)
|
|
|
|
__array(u32, scanline, I915_MAX_PIPES)
|
2021-12-08 13:05:17 +02:00
|
|
|
__field(bool, old)
|
|
|
|
__field(bool, new)
|
|
|
|
),
|
|
|
|
|
|
|
|
TP_fast_assign(
|
|
|
|
struct intel_crtc *crtc;
|
2024-05-16 13:34:54 -04:00
|
|
|
__assign_str(dev);
|
2024-10-16 10:52:28 -03:00
|
|
|
memset(__entry->frame, 0,
|
|
|
|
sizeof(__entry->frame[0]) * I915_MAX_PIPES);
|
|
|
|
memset(__entry->scanline, 0,
|
|
|
|
sizeof(__entry->scanline[0]) * I915_MAX_PIPES);
|
2024-09-04 16:06:33 +03:00
|
|
|
for_each_intel_crtc(display->drm, crtc) {
|
2021-12-08 13:05:17 +02:00
|
|
|
__entry->frame[crtc->pipe] = intel_crtc_get_vblank_counter(crtc);
|
|
|
|
__entry->scanline[crtc->pipe] = intel_get_crtc_scanline(crtc);
|
|
|
|
}
|
|
|
|
__entry->old = old;
|
|
|
|
__entry->new = new;
|
|
|
|
),
|
|
|
|
|
2024-10-16 10:52:31 -03:00
|
|
|
TP_printk("dev %s, cxsr %s->%s, " _PIPES_FRAME_AND_SCANLINE_FMT,
|
2022-11-11 14:31:20 +02:00
|
|
|
__get_str(dev), str_on_off(__entry->old), str_on_off(__entry->new),
|
2024-10-16 10:52:31 -03:00
|
|
|
_PIPES_FRAME_AND_SCANLINE_VALUES)
|
2021-12-08 13:05:17 +02:00
|
|
|
);
|
|
|
|
|
|
|
|
TRACE_EVENT(g4x_wm,
|
|
|
|
TP_PROTO(struct intel_crtc *crtc, const struct g4x_wm_values *wm),
|
|
|
|
TP_ARGS(crtc, wm),
|
|
|
|
|
|
|
|
TP_STRUCT__entry(
|
2022-11-11 14:31:20 +02:00
|
|
|
__string(dev, __dev_name_kms(crtc))
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__field(char, pipe_name)
|
2021-12-08 13:05:17 +02:00
|
|
|
__field(u32, frame)
|
|
|
|
__field(u32, scanline)
|
|
|
|
__field(u16, primary)
|
|
|
|
__field(u16, sprite)
|
|
|
|
__field(u16, cursor)
|
|
|
|
__field(u16, sr_plane)
|
|
|
|
__field(u16, sr_cursor)
|
|
|
|
__field(u16, sr_fbc)
|
|
|
|
__field(u16, hpll_plane)
|
|
|
|
__field(u16, hpll_cursor)
|
|
|
|
__field(u16, hpll_fbc)
|
|
|
|
__field(bool, cxsr)
|
|
|
|
__field(bool, hpll)
|
|
|
|
__field(bool, fbc)
|
|
|
|
),
|
|
|
|
|
|
|
|
TP_fast_assign(
|
2024-05-16 13:34:54 -04:00
|
|
|
__assign_str(dev);
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__entry->pipe_name = pipe_name(crtc->pipe);
|
2021-12-08 13:05:17 +02:00
|
|
|
__entry->frame = intel_crtc_get_vblank_counter(crtc);
|
|
|
|
__entry->scanline = intel_get_crtc_scanline(crtc);
|
|
|
|
__entry->primary = wm->pipe[crtc->pipe].plane[PLANE_PRIMARY];
|
|
|
|
__entry->sprite = wm->pipe[crtc->pipe].plane[PLANE_SPRITE0];
|
|
|
|
__entry->cursor = wm->pipe[crtc->pipe].plane[PLANE_CURSOR];
|
|
|
|
__entry->sr_plane = wm->sr.plane;
|
|
|
|
__entry->sr_cursor = wm->sr.cursor;
|
|
|
|
__entry->sr_fbc = wm->sr.fbc;
|
|
|
|
__entry->hpll_plane = wm->hpll.plane;
|
|
|
|
__entry->hpll_cursor = wm->hpll.cursor;
|
|
|
|
__entry->hpll_fbc = wm->hpll.fbc;
|
|
|
|
__entry->cxsr = wm->cxsr;
|
|
|
|
__entry->hpll = wm->hpll_en;
|
|
|
|
__entry->fbc = wm->fbc_en;
|
|
|
|
),
|
|
|
|
|
2022-11-11 14:31:20 +02:00
|
|
|
TP_printk("dev %s, pipe %c, frame=%u, scanline=%u, wm %d/%d/%d, sr %s/%d/%d/%d, hpll %s/%d/%d/%d, fbc %s",
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__get_str(dev), __entry->pipe_name,
|
2022-11-11 14:31:20 +02:00
|
|
|
__entry->frame, __entry->scanline,
|
2021-12-08 13:05:17 +02:00
|
|
|
__entry->primary, __entry->sprite, __entry->cursor,
|
2022-02-25 15:46:28 -08:00
|
|
|
str_yes_no(__entry->cxsr), __entry->sr_plane, __entry->sr_cursor, __entry->sr_fbc,
|
|
|
|
str_yes_no(__entry->hpll), __entry->hpll_plane, __entry->hpll_cursor, __entry->hpll_fbc,
|
|
|
|
str_yes_no(__entry->fbc))
|
2021-12-08 13:05:17 +02:00
|
|
|
);
|
|
|
|
|
|
|
|
TRACE_EVENT(vlv_wm,
|
|
|
|
TP_PROTO(struct intel_crtc *crtc, const struct vlv_wm_values *wm),
|
|
|
|
TP_ARGS(crtc, wm),
|
|
|
|
|
|
|
|
TP_STRUCT__entry(
|
2022-11-11 14:31:20 +02:00
|
|
|
__string(dev, __dev_name_kms(crtc))
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__field(char, pipe_name)
|
2021-12-08 13:05:17 +02:00
|
|
|
__field(u32, frame)
|
|
|
|
__field(u32, scanline)
|
|
|
|
__field(u32, level)
|
|
|
|
__field(u32, cxsr)
|
|
|
|
__field(u32, primary)
|
|
|
|
__field(u32, sprite0)
|
|
|
|
__field(u32, sprite1)
|
|
|
|
__field(u32, cursor)
|
|
|
|
__field(u32, sr_plane)
|
|
|
|
__field(u32, sr_cursor)
|
|
|
|
),
|
|
|
|
|
|
|
|
TP_fast_assign(
|
2024-05-16 13:34:54 -04:00
|
|
|
__assign_str(dev);
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__entry->pipe_name = pipe_name(crtc->pipe);
|
2021-12-08 13:05:17 +02:00
|
|
|
__entry->frame = intel_crtc_get_vblank_counter(crtc);
|
|
|
|
__entry->scanline = intel_get_crtc_scanline(crtc);
|
|
|
|
__entry->level = wm->level;
|
|
|
|
__entry->cxsr = wm->cxsr;
|
|
|
|
__entry->primary = wm->pipe[crtc->pipe].plane[PLANE_PRIMARY];
|
|
|
|
__entry->sprite0 = wm->pipe[crtc->pipe].plane[PLANE_SPRITE0];
|
|
|
|
__entry->sprite1 = wm->pipe[crtc->pipe].plane[PLANE_SPRITE1];
|
|
|
|
__entry->cursor = wm->pipe[crtc->pipe].plane[PLANE_CURSOR];
|
|
|
|
__entry->sr_plane = wm->sr.plane;
|
|
|
|
__entry->sr_cursor = wm->sr.cursor;
|
|
|
|
),
|
|
|
|
|
2022-11-11 14:31:20 +02:00
|
|
|
TP_printk("dev %s, pipe %c, frame=%u, scanline=%u, level=%d, cxsr=%d, wm %d/%d/%d/%d, sr %d/%d",
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__get_str(dev), __entry->pipe_name,
|
2022-11-11 14:31:20 +02:00
|
|
|
__entry->frame, __entry->scanline,
|
|
|
|
__entry->level, __entry->cxsr,
|
2021-12-08 13:05:17 +02:00
|
|
|
__entry->primary, __entry->sprite0, __entry->sprite1, __entry->cursor,
|
|
|
|
__entry->sr_plane, __entry->sr_cursor)
|
|
|
|
);
|
|
|
|
|
|
|
|
TRACE_EVENT(vlv_fifo_size,
|
|
|
|
TP_PROTO(struct intel_crtc *crtc, u32 sprite0_start, u32 sprite1_start, u32 fifo_size),
|
|
|
|
TP_ARGS(crtc, sprite0_start, sprite1_start, fifo_size),
|
|
|
|
|
|
|
|
TP_STRUCT__entry(
|
2022-11-11 14:31:20 +02:00
|
|
|
__string(dev, __dev_name_kms(crtc))
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__field(char, pipe_name)
|
2021-12-08 13:05:17 +02:00
|
|
|
__field(u32, frame)
|
|
|
|
__field(u32, scanline)
|
|
|
|
__field(u32, sprite0_start)
|
|
|
|
__field(u32, sprite1_start)
|
|
|
|
__field(u32, fifo_size)
|
|
|
|
),
|
|
|
|
|
|
|
|
TP_fast_assign(
|
2024-05-16 13:34:54 -04:00
|
|
|
__assign_str(dev);
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__entry->pipe_name = pipe_name(crtc->pipe);
|
2021-12-08 13:05:17 +02:00
|
|
|
__entry->frame = intel_crtc_get_vblank_counter(crtc);
|
|
|
|
__entry->scanline = intel_get_crtc_scanline(crtc);
|
|
|
|
__entry->sprite0_start = sprite0_start;
|
|
|
|
__entry->sprite1_start = sprite1_start;
|
|
|
|
__entry->fifo_size = fifo_size;
|
|
|
|
),
|
|
|
|
|
2022-11-11 14:31:20 +02:00
|
|
|
TP_printk("dev %s, pipe %c, frame=%u, scanline=%u, %d/%d/%d",
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__get_str(dev), __entry->pipe_name,
|
2022-11-11 14:31:20 +02:00
|
|
|
__entry->frame, __entry->scanline,
|
|
|
|
__entry->sprite0_start, __entry->sprite1_start, __entry->fifo_size)
|
2021-12-08 13:05:17 +02:00
|
|
|
);
|
|
|
|
|
2024-06-11 16:33:35 +03:00
|
|
|
TRACE_EVENT(intel_plane_async_flip,
|
|
|
|
TP_PROTO(struct intel_plane *plane, struct intel_crtc *crtc, bool async_flip),
|
|
|
|
TP_ARGS(plane, crtc, async_flip),
|
|
|
|
|
|
|
|
TP_STRUCT__entry(
|
|
|
|
__string(dev, __dev_name_kms(plane))
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__field(char, pipe_name)
|
2024-06-11 16:33:35 +03:00
|
|
|
__field(u32, frame)
|
|
|
|
__field(u32, scanline)
|
|
|
|
__field(bool, async_flip)
|
|
|
|
__string(name, plane->base.name)
|
|
|
|
),
|
|
|
|
|
|
|
|
TP_fast_assign(
|
|
|
|
__assign_str(dev);
|
|
|
|
__assign_str(name);
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__entry->pipe_name = pipe_name(crtc->pipe);
|
2024-06-11 16:33:35 +03:00
|
|
|
__entry->frame = intel_crtc_get_vblank_counter(crtc);
|
|
|
|
__entry->scanline = intel_get_crtc_scanline(crtc);
|
|
|
|
__entry->async_flip = async_flip;
|
|
|
|
),
|
|
|
|
|
2024-12-18 19:36:48 +02:00
|
|
|
TP_printk("dev %s, pipe %c, %s, frame=%u, scanline=%u, async_flip=%s",
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__get_str(dev), __entry->pipe_name, __get_str(name),
|
2024-06-11 16:33:35 +03:00
|
|
|
__entry->frame, __entry->scanline, str_yes_no(__entry->async_flip))
|
|
|
|
);
|
|
|
|
|
2021-12-08 13:05:17 +02:00
|
|
|
TRACE_EVENT(intel_plane_update_noarm,
|
2024-12-18 19:36:49 +02:00
|
|
|
TP_PROTO(const struct intel_plane_state *plane_state, struct intel_crtc *crtc),
|
|
|
|
TP_ARGS(plane_state, crtc),
|
2021-12-08 13:05:17 +02:00
|
|
|
|
|
|
|
TP_STRUCT__entry(
|
2024-12-18 19:36:49 +02:00
|
|
|
__string(dev, __dev_name_drm(plane_state->uapi.plane))
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__field(char, pipe_name)
|
2021-12-08 13:05:17 +02:00
|
|
|
__field(u32, frame)
|
|
|
|
__field(u32, scanline)
|
2024-12-18 19:36:50 +02:00
|
|
|
__field(u32, format)
|
2021-12-08 13:05:17 +02:00
|
|
|
__array(int, src, 4)
|
|
|
|
__array(int, dst, 4)
|
2024-12-18 19:36:49 +02:00
|
|
|
__string(name, plane_state->uapi.plane->name)
|
2021-12-08 13:05:17 +02:00
|
|
|
),
|
|
|
|
|
|
|
|
TP_fast_assign(
|
2024-05-16 13:34:54 -04:00
|
|
|
__assign_str(dev);
|
|
|
|
__assign_str(name);
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__entry->pipe_name = pipe_name(crtc->pipe);
|
2021-12-08 13:05:17 +02:00
|
|
|
__entry->frame = intel_crtc_get_vblank_counter(crtc);
|
|
|
|
__entry->scanline = intel_get_crtc_scanline(crtc);
|
2024-12-18 19:36:50 +02:00
|
|
|
__entry->format = plane_state->hw.fb->format->format;
|
2024-12-18 19:36:49 +02:00
|
|
|
memcpy(__entry->src, &plane_state->uapi.src, sizeof(__entry->src));
|
|
|
|
memcpy(__entry->dst, &plane_state->uapi.dst, sizeof(__entry->dst));
|
2021-12-08 13:05:17 +02:00
|
|
|
),
|
|
|
|
|
2024-12-18 19:36:50 +02:00
|
|
|
TP_printk("dev %s, pipe %c, %s, frame=%u, scanline=%u, format=%p4cc, " DRM_RECT_FP_FMT " -> " DRM_RECT_FMT,
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__get_str(dev), __entry->pipe_name, __get_str(name),
|
2024-12-18 19:36:50 +02:00
|
|
|
__entry->frame, __entry->scanline, &__entry->format,
|
2021-12-08 13:05:17 +02:00
|
|
|
DRM_RECT_FP_ARG((const struct drm_rect *)__entry->src),
|
|
|
|
DRM_RECT_ARG((const struct drm_rect *)__entry->dst))
|
|
|
|
);
|
|
|
|
|
|
|
|
TRACE_EVENT(intel_plane_update_arm,
|
2024-12-18 19:36:49 +02:00
|
|
|
TP_PROTO(const struct intel_plane_state *plane_state, struct intel_crtc *crtc),
|
|
|
|
TP_ARGS(plane_state, crtc),
|
2021-12-08 13:05:17 +02:00
|
|
|
|
|
|
|
TP_STRUCT__entry(
|
2024-12-18 19:36:49 +02:00
|
|
|
__string(dev, __dev_name_drm(plane_state->uapi.plane))
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__field(char, pipe_name)
|
2021-12-08 13:05:17 +02:00
|
|
|
__field(u32, frame)
|
|
|
|
__field(u32, scanline)
|
2024-12-18 19:36:50 +02:00
|
|
|
__field(u32, format)
|
2021-12-08 13:05:17 +02:00
|
|
|
__array(int, src, 4)
|
|
|
|
__array(int, dst, 4)
|
2024-12-18 19:36:49 +02:00
|
|
|
__string(name, plane_state->uapi.plane->name)
|
2021-12-08 13:05:17 +02:00
|
|
|
),
|
|
|
|
|
|
|
|
TP_fast_assign(
|
2024-05-16 13:34:54 -04:00
|
|
|
__assign_str(dev);
|
|
|
|
__assign_str(name);
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__entry->pipe_name = pipe_name(crtc->pipe);
|
2021-12-08 13:05:17 +02:00
|
|
|
__entry->frame = intel_crtc_get_vblank_counter(crtc);
|
|
|
|
__entry->scanline = intel_get_crtc_scanline(crtc);
|
2024-12-18 19:36:50 +02:00
|
|
|
__entry->format = plane_state->hw.fb->format->format;
|
2024-12-18 19:36:49 +02:00
|
|
|
memcpy(__entry->src, &plane_state->uapi.src, sizeof(__entry->src));
|
|
|
|
memcpy(__entry->dst, &plane_state->uapi.dst, sizeof(__entry->dst));
|
2021-12-08 13:05:17 +02:00
|
|
|
),
|
|
|
|
|
2024-12-18 19:36:50 +02:00
|
|
|
TP_printk("dev %s, pipe %c, %s, frame=%u, scanline=%u, format=%p4cc, " DRM_RECT_FP_FMT " -> " DRM_RECT_FMT,
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__get_str(dev), __entry->pipe_name, __get_str(name),
|
2024-12-18 19:36:50 +02:00
|
|
|
__entry->frame, __entry->scanline, &__entry->format,
|
2021-12-08 13:05:17 +02:00
|
|
|
DRM_RECT_FP_ARG((const struct drm_rect *)__entry->src),
|
|
|
|
DRM_RECT_ARG((const struct drm_rect *)__entry->dst))
|
|
|
|
);
|
|
|
|
|
|
|
|
TRACE_EVENT(intel_plane_disable_arm,
|
2022-11-11 14:31:17 +02:00
|
|
|
TP_PROTO(struct intel_plane *plane, struct intel_crtc *crtc),
|
2021-12-08 13:05:17 +02:00
|
|
|
TP_ARGS(plane, crtc),
|
|
|
|
|
|
|
|
TP_STRUCT__entry(
|
2022-11-11 14:31:20 +02:00
|
|
|
__string(dev, __dev_name_kms(plane))
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__field(char, pipe_name)
|
2021-12-08 13:05:17 +02:00
|
|
|
__field(u32, frame)
|
|
|
|
__field(u32, scanline)
|
2022-11-11 14:31:17 +02:00
|
|
|
__string(name, plane->base.name)
|
2021-12-08 13:05:17 +02:00
|
|
|
),
|
|
|
|
|
|
|
|
TP_fast_assign(
|
2024-05-16 13:34:54 -04:00
|
|
|
__assign_str(dev);
|
|
|
|
__assign_str(name);
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__entry->pipe_name = pipe_name(crtc->pipe);
|
2021-12-08 13:05:17 +02:00
|
|
|
__entry->frame = intel_crtc_get_vblank_counter(crtc);
|
|
|
|
__entry->scanline = intel_get_crtc_scanline(crtc);
|
|
|
|
),
|
|
|
|
|
2024-12-18 19:36:48 +02:00
|
|
|
TP_printk("dev %s, pipe %c, %s, frame=%u, scanline=%u",
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__get_str(dev), __entry->pipe_name, __get_str(name),
|
2021-12-08 13:05:17 +02:00
|
|
|
__entry->frame, __entry->scanline)
|
|
|
|
);
|
|
|
|
|
2024-12-19 15:08:27 +02:00
|
|
|
TRACE_EVENT(intel_plane_scaler_update_arm,
|
|
|
|
TP_PROTO(struct intel_plane *plane,
|
|
|
|
int scaler_id, int x, int y, int w, int h),
|
|
|
|
TP_ARGS(plane, scaler_id, x, y, w, h),
|
|
|
|
|
|
|
|
TP_STRUCT__entry(
|
|
|
|
__string(dev, __dev_name_kms(plane))
|
|
|
|
__field(char, pipe_name)
|
|
|
|
__field(int, scaler_id)
|
|
|
|
__field(u32, frame)
|
|
|
|
__field(u32, scanline)
|
|
|
|
__field(int, x)
|
|
|
|
__field(int, y)
|
|
|
|
__field(int, w)
|
|
|
|
__field(int, h)
|
|
|
|
__string(name, plane->base.name)
|
|
|
|
),
|
|
|
|
|
|
|
|
TP_fast_assign(
|
|
|
|
struct intel_display *display = to_intel_display(plane);
|
|
|
|
struct intel_crtc *crtc = intel_crtc_for_pipe(display, plane->pipe);
|
|
|
|
__assign_str(dev);
|
|
|
|
__assign_str(name);
|
|
|
|
__entry->pipe_name = pipe_name(crtc->pipe);
|
|
|
|
__entry->scaler_id = scaler_id;
|
|
|
|
__entry->frame = intel_crtc_get_vblank_counter(crtc);
|
|
|
|
__entry->scanline = intel_get_crtc_scanline(crtc);
|
|
|
|
__entry->x = x;
|
|
|
|
__entry->y = y;
|
|
|
|
__entry->w = w;
|
|
|
|
__entry->h = h;
|
|
|
|
),
|
|
|
|
|
|
|
|
TP_printk("dev %s, pipe %c, scaler %d, plane %s, frame=%u, scanline=%u, " DRM_RECT_FMT,
|
|
|
|
__get_str(dev), __entry->pipe_name, __entry->scaler_id,
|
|
|
|
__get_str(name), __entry->frame, __entry->scanline,
|
|
|
|
__entry->w, __entry->h, __entry->x, __entry->y)
|
|
|
|
);
|
|
|
|
|
|
|
|
TRACE_EVENT(intel_pipe_scaler_update_arm,
|
|
|
|
TP_PROTO(struct intel_crtc *crtc, int scaler_id,
|
|
|
|
int x, int y, int w, int h),
|
|
|
|
TP_ARGS(crtc, scaler_id, x, y, w, h),
|
|
|
|
|
|
|
|
TP_STRUCT__entry(
|
|
|
|
__string(dev, __dev_name_kms(crtc))
|
|
|
|
__field(char, pipe_name)
|
|
|
|
__field(int, scaler_id)
|
|
|
|
__field(u32, frame)
|
|
|
|
__field(u32, scanline)
|
|
|
|
__field(int, x)
|
|
|
|
__field(int, y)
|
|
|
|
__field(int, w)
|
|
|
|
__field(int, h)
|
|
|
|
),
|
|
|
|
|
|
|
|
TP_fast_assign(
|
|
|
|
__assign_str(dev);
|
|
|
|
__entry->pipe_name = pipe_name(crtc->pipe);
|
|
|
|
__entry->scaler_id = scaler_id;
|
|
|
|
__entry->frame = intel_crtc_get_vblank_counter(crtc);
|
|
|
|
__entry->scanline = intel_get_crtc_scanline(crtc);
|
|
|
|
__entry->x = x;
|
|
|
|
__entry->y = y;
|
|
|
|
__entry->w = w;
|
|
|
|
__entry->h = h;
|
|
|
|
),
|
|
|
|
|
|
|
|
TP_printk("dev %s, pipe %c, scaler %d frame=%u, scanline=%u, " DRM_RECT_FMT,
|
|
|
|
__get_str(dev), __entry->pipe_name, __entry->scaler_id,
|
|
|
|
__entry->frame, __entry->scanline,
|
|
|
|
__entry->w, __entry->h, __entry->x, __entry->y)
|
|
|
|
);
|
|
|
|
|
|
|
|
TRACE_EVENT(intel_scaler_disable_arm,
|
|
|
|
TP_PROTO(struct intel_crtc *crtc, int scaler_id),
|
|
|
|
TP_ARGS(crtc, scaler_id),
|
|
|
|
|
|
|
|
TP_STRUCT__entry(
|
|
|
|
__string(dev, __dev_name_kms(crtc))
|
|
|
|
__field(char, pipe_name)
|
|
|
|
__field(int, scaler_id)
|
|
|
|
__field(u32, frame)
|
|
|
|
__field(u32, scanline)
|
|
|
|
),
|
|
|
|
|
|
|
|
TP_fast_assign(
|
|
|
|
__assign_str(dev);
|
|
|
|
__entry->pipe_name = pipe_name(crtc->pipe);
|
|
|
|
__entry->scaler_id = scaler_id;
|
|
|
|
__entry->frame = intel_crtc_get_vblank_counter(crtc);
|
|
|
|
__entry->scanline = intel_get_crtc_scanline(crtc);
|
|
|
|
),
|
|
|
|
|
|
|
|
TP_printk("dev %s, pipe %c, scaler %d, frame=%u, scanline=%u",
|
|
|
|
__get_str(dev), __entry->pipe_name, __entry->scaler_id,
|
|
|
|
__entry->frame, __entry->scanline)
|
|
|
|
);
|
|
|
|
|
2021-12-08 13:05:17 +02:00
|
|
|
TRACE_EVENT(intel_fbc_activate,
|
|
|
|
TP_PROTO(struct intel_plane *plane),
|
|
|
|
TP_ARGS(plane),
|
|
|
|
|
|
|
|
TP_STRUCT__entry(
|
2022-11-11 14:31:20 +02:00
|
|
|
__string(dev, __dev_name_kms(plane))
|
2022-11-11 14:31:18 +02:00
|
|
|
__string(name, plane->base.name)
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__field(char, pipe_name)
|
2021-12-08 13:05:17 +02:00
|
|
|
__field(u32, frame)
|
|
|
|
__field(u32, scanline)
|
|
|
|
),
|
|
|
|
|
|
|
|
TP_fast_assign(
|
2024-09-04 16:06:32 +03:00
|
|
|
struct intel_display *display = to_intel_display(plane->base.dev);
|
|
|
|
struct intel_crtc *crtc = intel_crtc_for_pipe(display,
|
2021-12-08 13:05:17 +02:00
|
|
|
plane->pipe);
|
2024-05-16 13:34:54 -04:00
|
|
|
__assign_str(dev);
|
|
|
|
__assign_str(name);
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__entry->pipe_name = pipe_name(crtc->pipe);
|
2021-12-08 13:05:17 +02:00
|
|
|
__entry->frame = intel_crtc_get_vblank_counter(crtc);
|
|
|
|
__entry->scanline = intel_get_crtc_scanline(crtc);
|
|
|
|
),
|
|
|
|
|
2024-12-18 19:36:48 +02:00
|
|
|
TP_printk("dev %s, pipe %c, %s, frame=%u, scanline=%u",
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__get_str(dev), __entry->pipe_name, __get_str(name),
|
2022-11-11 14:31:18 +02:00
|
|
|
__entry->frame, __entry->scanline)
|
2021-12-08 13:05:17 +02:00
|
|
|
);
|
|
|
|
|
|
|
|
TRACE_EVENT(intel_fbc_deactivate,
|
|
|
|
TP_PROTO(struct intel_plane *plane),
|
|
|
|
TP_ARGS(plane),
|
|
|
|
|
|
|
|
TP_STRUCT__entry(
|
2022-11-11 14:31:20 +02:00
|
|
|
__string(dev, __dev_name_kms(plane))
|
2022-11-11 14:31:18 +02:00
|
|
|
__string(name, plane->base.name)
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__field(char, pipe_name)
|
2021-12-08 13:05:17 +02:00
|
|
|
__field(u32, frame)
|
|
|
|
__field(u32, scanline)
|
|
|
|
),
|
|
|
|
|
|
|
|
TP_fast_assign(
|
2024-09-04 16:06:32 +03:00
|
|
|
struct intel_display *display = to_intel_display(plane->base.dev);
|
|
|
|
struct intel_crtc *crtc = intel_crtc_for_pipe(display,
|
2021-12-08 13:05:17 +02:00
|
|
|
plane->pipe);
|
2024-05-16 13:34:54 -04:00
|
|
|
__assign_str(dev);
|
|
|
|
__assign_str(name);
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__entry->pipe_name = pipe_name(crtc->pipe);
|
2021-12-08 13:05:17 +02:00
|
|
|
__entry->frame = intel_crtc_get_vblank_counter(crtc);
|
|
|
|
__entry->scanline = intel_get_crtc_scanline(crtc);
|
|
|
|
),
|
|
|
|
|
2024-12-18 19:36:48 +02:00
|
|
|
TP_printk("dev %s, pipe %c, %s, frame=%u, scanline=%u",
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__get_str(dev), __entry->pipe_name, __get_str(name),
|
2022-11-11 14:31:18 +02:00
|
|
|
__entry->frame, __entry->scanline)
|
2021-12-08 13:05:17 +02:00
|
|
|
);
|
|
|
|
|
|
|
|
TRACE_EVENT(intel_fbc_nuke,
|
|
|
|
TP_PROTO(struct intel_plane *plane),
|
|
|
|
TP_ARGS(plane),
|
|
|
|
|
|
|
|
TP_STRUCT__entry(
|
2022-11-11 14:31:20 +02:00
|
|
|
__string(dev, __dev_name_kms(plane))
|
2022-11-11 14:31:18 +02:00
|
|
|
__string(name, plane->base.name)
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__field(char, pipe_name)
|
2021-12-08 13:05:17 +02:00
|
|
|
__field(u32, frame)
|
|
|
|
__field(u32, scanline)
|
|
|
|
),
|
|
|
|
|
|
|
|
TP_fast_assign(
|
2024-09-04 16:06:32 +03:00
|
|
|
struct intel_display *display = to_intel_display(plane->base.dev);
|
|
|
|
struct intel_crtc *crtc = intel_crtc_for_pipe(display,
|
2021-12-08 13:05:17 +02:00
|
|
|
plane->pipe);
|
2024-05-16 13:34:54 -04:00
|
|
|
__assign_str(dev);
|
|
|
|
__assign_str(name);
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__entry->pipe_name = pipe_name(crtc->pipe);
|
2021-12-08 13:05:17 +02:00
|
|
|
__entry->frame = intel_crtc_get_vblank_counter(crtc);
|
|
|
|
__entry->scanline = intel_get_crtc_scanline(crtc);
|
|
|
|
),
|
|
|
|
|
2024-12-18 19:36:48 +02:00
|
|
|
TP_printk("dev %s, pipe %c, %s, frame=%u, scanline=%u",
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__get_str(dev), __entry->pipe_name, __get_str(name),
|
2022-11-11 14:31:18 +02:00
|
|
|
__entry->frame, __entry->scanline)
|
2021-12-08 13:05:17 +02:00
|
|
|
);
|
|
|
|
|
|
|
|
TRACE_EVENT(intel_crtc_vblank_work_start,
|
|
|
|
TP_PROTO(struct intel_crtc *crtc),
|
|
|
|
TP_ARGS(crtc),
|
|
|
|
|
|
|
|
TP_STRUCT__entry(
|
2022-11-11 14:31:20 +02:00
|
|
|
__string(dev, __dev_name_kms(crtc))
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__field(char, pipe_name)
|
2021-12-08 13:05:17 +02:00
|
|
|
__field(u32, frame)
|
|
|
|
__field(u32, scanline)
|
|
|
|
),
|
|
|
|
|
|
|
|
TP_fast_assign(
|
2024-05-16 13:34:54 -04:00
|
|
|
__assign_str(dev);
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__entry->pipe_name = pipe_name(crtc->pipe);
|
2021-12-08 13:05:17 +02:00
|
|
|
__entry->frame = intel_crtc_get_vblank_counter(crtc);
|
|
|
|
__entry->scanline = intel_get_crtc_scanline(crtc);
|
|
|
|
),
|
|
|
|
|
2022-11-11 14:31:20 +02:00
|
|
|
TP_printk("dev %s, pipe %c, frame=%u, scanline=%u",
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__get_str(dev), __entry->pipe_name,
|
2022-11-11 14:31:20 +02:00
|
|
|
__entry->frame, __entry->scanline)
|
2021-12-08 13:05:17 +02:00
|
|
|
);
|
|
|
|
|
|
|
|
TRACE_EVENT(intel_crtc_vblank_work_end,
|
|
|
|
TP_PROTO(struct intel_crtc *crtc),
|
|
|
|
TP_ARGS(crtc),
|
|
|
|
|
|
|
|
TP_STRUCT__entry(
|
2022-11-11 14:31:20 +02:00
|
|
|
__string(dev, __dev_name_kms(crtc))
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__field(char, pipe_name)
|
2021-12-08 13:05:17 +02:00
|
|
|
__field(u32, frame)
|
|
|
|
__field(u32, scanline)
|
|
|
|
),
|
|
|
|
|
|
|
|
TP_fast_assign(
|
2024-05-16 13:34:54 -04:00
|
|
|
__assign_str(dev);
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__entry->pipe_name = pipe_name(crtc->pipe);
|
2021-12-08 13:05:17 +02:00
|
|
|
__entry->frame = intel_crtc_get_vblank_counter(crtc);
|
|
|
|
__entry->scanline = intel_get_crtc_scanline(crtc);
|
|
|
|
),
|
|
|
|
|
2022-11-11 14:31:20 +02:00
|
|
|
TP_printk("dev %s, pipe %c, frame=%u, scanline=%u",
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__get_str(dev), __entry->pipe_name,
|
2022-11-11 14:31:20 +02:00
|
|
|
__entry->frame, __entry->scanline)
|
2021-12-08 13:05:17 +02:00
|
|
|
);
|
|
|
|
|
|
|
|
TRACE_EVENT(intel_pipe_update_start,
|
|
|
|
TP_PROTO(struct intel_crtc *crtc),
|
|
|
|
TP_ARGS(crtc),
|
|
|
|
|
|
|
|
TP_STRUCT__entry(
|
2022-11-11 14:31:20 +02:00
|
|
|
__string(dev, __dev_name_kms(crtc))
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__field(char, pipe_name)
|
2021-12-08 13:05:17 +02:00
|
|
|
__field(u32, frame)
|
|
|
|
__field(u32, scanline)
|
|
|
|
__field(u32, min)
|
|
|
|
__field(u32, max)
|
|
|
|
),
|
|
|
|
|
|
|
|
TP_fast_assign(
|
2024-05-16 13:34:54 -04:00
|
|
|
__assign_str(dev);
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__entry->pipe_name = pipe_name(crtc->pipe);
|
2021-12-08 13:05:17 +02:00
|
|
|
__entry->frame = intel_crtc_get_vblank_counter(crtc);
|
|
|
|
__entry->scanline = intel_get_crtc_scanline(crtc);
|
|
|
|
__entry->min = crtc->debug.min_vbl;
|
|
|
|
__entry->max = crtc->debug.max_vbl;
|
|
|
|
),
|
|
|
|
|
2022-11-11 14:31:20 +02:00
|
|
|
TP_printk("dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u",
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__get_str(dev), __entry->pipe_name,
|
2022-11-11 14:31:20 +02:00
|
|
|
__entry->frame, __entry->scanline,
|
|
|
|
__entry->min, __entry->max)
|
2021-12-08 13:05:17 +02:00
|
|
|
);
|
|
|
|
|
|
|
|
TRACE_EVENT(intel_pipe_update_vblank_evaded,
|
|
|
|
TP_PROTO(struct intel_crtc *crtc),
|
|
|
|
TP_ARGS(crtc),
|
|
|
|
|
|
|
|
TP_STRUCT__entry(
|
2022-11-11 14:31:20 +02:00
|
|
|
__string(dev, __dev_name_kms(crtc))
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__field(char, pipe_name)
|
2021-12-08 13:05:17 +02:00
|
|
|
__field(u32, frame)
|
|
|
|
__field(u32, scanline)
|
|
|
|
__field(u32, min)
|
|
|
|
__field(u32, max)
|
|
|
|
),
|
|
|
|
|
|
|
|
TP_fast_assign(
|
2024-05-16 13:34:54 -04:00
|
|
|
__assign_str(dev);
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__entry->pipe_name = pipe_name(crtc->pipe);
|
2021-12-08 13:05:17 +02:00
|
|
|
__entry->frame = crtc->debug.start_vbl_count;
|
|
|
|
__entry->scanline = crtc->debug.scanline_start;
|
|
|
|
__entry->min = crtc->debug.min_vbl;
|
|
|
|
__entry->max = crtc->debug.max_vbl;
|
|
|
|
),
|
|
|
|
|
2022-11-11 14:31:20 +02:00
|
|
|
TP_printk("dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u",
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__get_str(dev), __entry->pipe_name,
|
2022-11-11 14:31:20 +02:00
|
|
|
__entry->frame, __entry->scanline,
|
|
|
|
__entry->min, __entry->max)
|
2021-12-08 13:05:17 +02:00
|
|
|
);
|
|
|
|
|
|
|
|
TRACE_EVENT(intel_pipe_update_end,
|
|
|
|
TP_PROTO(struct intel_crtc *crtc, u32 frame, int scanline_end),
|
|
|
|
TP_ARGS(crtc, frame, scanline_end),
|
|
|
|
|
|
|
|
TP_STRUCT__entry(
|
2022-11-11 14:31:20 +02:00
|
|
|
__string(dev, __dev_name_kms(crtc))
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__field(char, pipe_name)
|
2021-12-08 13:05:17 +02:00
|
|
|
__field(u32, frame)
|
|
|
|
__field(u32, scanline)
|
|
|
|
),
|
|
|
|
|
|
|
|
TP_fast_assign(
|
2024-05-16 13:34:54 -04:00
|
|
|
__assign_str(dev);
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__entry->pipe_name = pipe_name(crtc->pipe);
|
2021-12-08 13:05:17 +02:00
|
|
|
__entry->frame = frame;
|
|
|
|
__entry->scanline = scanline_end;
|
|
|
|
),
|
|
|
|
|
2022-11-11 14:31:20 +02:00
|
|
|
TP_printk("dev %s, pipe %c, frame=%u, scanline=%u",
|
drm/i915/display: Store pipe name in trace events
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
tracepoints."
It seems this is what we ended up doing when using pipe_name() in
TP_printk().
For example, the format for the intel_pipe_update_start event is as
follows:
# cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
name: intel_pipe_update_start
ID: 1136
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] dev; offset:8; size:4; signed:0;
field:enum pipe pipe; offset:12; size:4; signed:1;
field:u32 frame; offset:16; size:4; signed:0;
field:u32 scanline; offset:20; size:4; signed:0;
field:u32 min; offset:24; size:4; signed:0;
field:u32 max; offset:28; size:4; signed:0;
print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max
The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.
Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.
While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | uniq -c
34 pipe ^A
, where ^A is a non-printable character.
As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:
s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/
After these changes, using the same example, we have the following:
$ trace-cmd report \
> | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
> | cat -v | sort | uniq -c
396 pipe A
34 pipe B
[1] https://lwn.net/Articles/379903/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-16 10:52:29 -03:00
|
|
|
__get_str(dev), __entry->pipe_name,
|
2022-11-11 14:31:20 +02:00
|
|
|
__entry->frame, __entry->scanline)
|
2021-12-08 13:05:17 +02:00
|
|
|
);
|
|
|
|
|
|
|
|
TRACE_EVENT(intel_frontbuffer_invalidate,
|
2024-09-04 16:06:33 +03:00
|
|
|
TP_PROTO(struct intel_display *display,
|
2022-11-11 14:31:19 +02:00
|
|
|
unsigned int frontbuffer_bits, unsigned int origin),
|
2024-09-04 16:06:33 +03:00
|
|
|
TP_ARGS(display, frontbuffer_bits, origin),
|
2021-12-08 13:05:17 +02:00
|
|
|
|
|
|
|
TP_STRUCT__entry(
|
2024-09-04 16:06:33 +03:00
|
|
|
__string(dev, __dev_name_display(display))
|
2021-12-08 13:05:17 +02:00
|
|
|
__field(unsigned int, frontbuffer_bits)
|
|
|
|
__field(unsigned int, origin)
|
|
|
|
),
|
|
|
|
|
|
|
|
TP_fast_assign(
|
2024-05-16 13:34:54 -04:00
|
|
|
__assign_str(dev);
|
2021-12-08 13:05:17 +02:00
|
|
|
__entry->frontbuffer_bits = frontbuffer_bits;
|
|
|
|
__entry->origin = origin;
|
|
|
|
),
|
|
|
|
|
2022-11-11 14:31:20 +02:00
|
|
|
TP_printk("dev %s, frontbuffer_bits=0x%08x, origin=%u",
|
|
|
|
__get_str(dev), __entry->frontbuffer_bits, __entry->origin)
|
2021-12-08 13:05:17 +02:00
|
|
|
);
|
|
|
|
|
|
|
|
TRACE_EVENT(intel_frontbuffer_flush,
|
2024-09-04 16:06:33 +03:00
|
|
|
TP_PROTO(struct intel_display *display,
|
2022-11-11 14:31:19 +02:00
|
|
|
unsigned int frontbuffer_bits, unsigned int origin),
|
2024-09-04 16:06:33 +03:00
|
|
|
TP_ARGS(display, frontbuffer_bits, origin),
|
2021-12-08 13:05:17 +02:00
|
|
|
|
|
|
|
TP_STRUCT__entry(
|
2024-09-04 16:06:33 +03:00
|
|
|
__string(dev, __dev_name_display(display))
|
2021-12-08 13:05:17 +02:00
|
|
|
__field(unsigned int, frontbuffer_bits)
|
|
|
|
__field(unsigned int, origin)
|
|
|
|
),
|
|
|
|
|
|
|
|
TP_fast_assign(
|
2024-05-16 13:34:54 -04:00
|
|
|
__assign_str(dev);
|
2021-12-08 13:05:17 +02:00
|
|
|
__entry->frontbuffer_bits = frontbuffer_bits;
|
|
|
|
__entry->origin = origin;
|
|
|
|
),
|
|
|
|
|
2022-11-11 14:31:20 +02:00
|
|
|
TP_printk("dev %s, frontbuffer_bits=0x%08x, origin=%u",
|
|
|
|
__get_str(dev), __entry->frontbuffer_bits, __entry->origin)
|
2021-12-08 13:05:17 +02:00
|
|
|
);
|
|
|
|
|
|
|
|
#endif /* __INTEL_DISPLAY_TRACE_H__ */
|
|
|
|
|
|
|
|
/* This part must be outside protection */
|
|
|
|
#undef TRACE_INCLUDE_PATH
|
|
|
|
#undef TRACE_INCLUDE_FILE
|
|
|
|
#define TRACE_INCLUDE_PATH ../../drivers/gpu/drm/i915/display
|
|
|
|
#define TRACE_INCLUDE_FILE intel_display_trace
|
|
|
|
#include <trace/define_trace.h>
|