summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/mem-phys-addr.py
diff options
context:
space:
mode:
authorVille Syrjälä <ville.syrjala@linux.intel.com>2019-02-05 00:16:44 +0300
committerVille Syrjälä <ville.syrjala@linux.intel.com>2019-02-05 21:44:43 +0300
commit39806c3f11e206d03e76521c808a96aedfcc58d9 (patch)
tree1faa0fefb947c5f2eeae8601e802338d3fe73fed /tools/perf/scripts/python/mem-phys-addr.py
parentab1ab0eb0cb64d1c225bdf42bee067f81c87e2a4 (diff)
downloadlinux-39806c3f11e206d03e76521c808a96aedfcc58d9.tar.xz
drm/i915: Include register polling in reg_rw traces
We generally omit register polling from the i915_reg_rw tracepoint. Understandable since polling could generate a lot of noise in the trace. The downside is that the trace is incomplete. As a compromise let's trace the final register value observed while polling. That should be generally sufficient to observe what the code should be doing next. I suppose in some cases it might make sense to also trace the initial register value, and maybe the number of times we polled. But that would require a separate tracepoint so let's leave it for the future. The other users of _NOTRACE() are i915_pmu and i2c bitbanging, which I decided to leave alone. Next we should do something to claw back the tracepoints for planes and whatnot which were switched to _FW() a while back. I guess just new macros for raw_rw+trace. The question is what to call it? Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190204211644.21967-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Diffstat (limited to 'tools/perf/scripts/python/mem-phys-addr.py')
0 files changed, 0 insertions, 0 deletions