kernel/linux.git/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h, branch v6.19.11

drm/amdgpu: update trace format to match gpu_scheduler_trace

2025-05-28T14:16:20+00:00

Log fences using the same format for coherency. Signed-off-by: Pierre-Eric Pelloux-Prayer Reviewed-by: Christian König Reviewed-by: Arvind Yadav Signed-off-by: Philipp Stanner Link: https://lore.kernel.org/r/20250526125505.2360-11-pierre-eric.pelloux-prayer@amd.com

drm: Get rid of drm_sched_job.id

2025-05-28T14:16:15+00:00

Its only purpose was for trace events, but jobs can already be uniquely identified using their fence. The downside of using the fence is that it's only available after 'drm_sched_job_arm' was called which is true for all trace events that used job.id so they can safely switch to using it. Suggested-by: Tvrtko Ursulin Signed-off-by: Pierre-Eric Pelloux-Prayer Reviewed-by: Christian König Reviewed-by: Arvind Yadav Signed-off-by: Philipp Stanner Link: https://lore.kernel.org/r/20250526125505.2360-9-pierre-eric.pelloux-prayer@amd.com

drm/amdgpu: add cleaner shader trace point

2025-03-21T16:16:34+00:00

Note when the cleaner shader is executed. Signed-off-by: Christian König Acked-by: Srinivasan Shanmugam Signed-off-by: Alex Deucher

drm/amdgpu: add isolation trace point

2025-03-21T16:16:34+00:00

Note when we switch from one isolation owner to another. Signed-off-by: Christian König Acked-by: Srinivasan Shanmugam Signed-off-by: Alex Deucher

drm/amdgpu: revert "take runtime pm reference when we attach a buffer" v2

2024-06-19T18:17:25+00:00

This reverts commit b8c415e3bf98 ("drm/amdgpu: take runtime pm reference when we attach a buffer") and commit 425285d39afd ("drm/amdgpu: add amdgpu runpm usage trace for separate funcs"). Taking a runtime pm reference for DMA-buf is actually completely unnecessary and even dangerous. The problem is that calling pm_runtime_get_sync() from the DMA-buf callbacks is illegal because we have the reservation locked here which is also taken during resume. So this would deadlock. When the buffer is in GTT it is still accessible even when the GPU is powered down and when it is in VRAM the buffer gets migrated to GTT before powering down. The only use case which would make it mandatory to keep the runtime pm reference would be if we pin the buffer into VRAM, and that's not something we currently do. v2: improve the commit message Signed-off-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher CC: stable@vger.kernel.org

tracing/treewide: Remove second parameter of __assign_str()

2024-05-23T00:14:47+00:00

With the rework of how the __string() handles dynamic strings where it saves off the source string in field in the helper structure[1], the assignment of that value to the trace event field is stored in the helper value and does not need to be passed in again. This means that with: __string(field, mystring) Which use to be assigned with __assign_str(field, mystring), no longer needs the second parameter and it is unused. With this, __assign_str() will now only get a single parameter. There's over 700 users of __assign_str() and because coccinelle does not handle the TRACE_EVENT() macro I ended up using the following sed script: git grep -l __assign_str | while read a ; do sed -e 's/$__assign_str([^,]*[^ ,]$ *,[^;]*/\1)/' $a > /tmp/test-file; mv /tmp/test-file $a; done I then searched for __assign_str() that did not end with ';' as those were multi line assignments that the sed script above would fail to catch. Note, the same updates will need to be done for: __assign_str_len() __assign_rel_str() __assign_rel_str_len() I tested this with both an allmodconfig and an allyesconfig (build only for both). [1] https://lore.kernel.org/linux-trace-kernel/20240222211442.634192653@goodmis.org/ Link: https://lore.kernel.org/linux-trace-kernel/20240516133454.681ba6a0@rorschach.local.home Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Linus Torvalds Cc: Julia Lawall Signed-off-by: Steven Rostedt (Google) Acked-by: Jani Nikula Acked-by: Christian König for the amdgpu parts. Acked-by: Thomas Hellström #for Acked-by: Rafael J. Wysocki # for thermal Acked-by: Takashi Iwai Acked-by: Darrick J. Wong # xfs Tested-by: Guenter Roeck

drm/amdgpu: add amdgpu runpm usage trace for separate funcs

2023-11-17T14:30:51+00:00

Add trace for amdgpu runpm separate funcs usage and this will help debugging on the case of runpm usage missed to dereference. In the normal case the runpm usage count referred by one kind of functionality pairwise and usage should be changed from 1 to 0, otherwise there will be an issue in the amdgpu runpm usage dereference. Signed-off-by: Prike Liang Acked-by: Alex Deucher Signed-off-by: Alex Deucher

drm/amdgpu: Clean up errors in amdgpu_trace.h

2023-08-09T13:43:43+00:00

Fix the following errors reported by checkpatch: ERROR: space required after that ',' (ctx:VxV) ERROR: "foo* bar" should be "foo *bar" Signed-off-by: Ran Sun Signed-off-by: Alex Deucher

drm/amdgpu: move vmhub out of amdgpu_ring_funcs (v4)

2023-04-14T17:47:49+00:00

It looks better to place this field in ring structure. Also drop the repeated ring funcs definitions if there's no difference except for vmhub field. v2: rename the field to vm_hub like others (Le) v3: apply the changes to new ip blocks (Hawking) v4: fix vcn sw ring (Alex) Signed-off-by: Le Ma Reviewed-by: Christian König Reviewed-by: Hawking Zhang Signed-off-by: Hawking Zhang Signed-off-by: Alex Deucher

drm/amdgpu: Use the sched from entity for amdgpu_cs trace

2023-01-17T21:11:52+00:00

The problem is that base sched hasn't been assigned yet at this moment, causing something like "ring=0" all the time from trace. mpv:cs0-3473 [002] ..... 129.047431: amdgpu_cs: ring=0, dw=48, fences=0 mpv:cs0-3473 [002] ..... 129.089125: amdgpu_cs: ring=0, dw=48, fences=0 mpv:cs0-3473 [002] ..... 129.130987: amdgpu_cs: ring=0, dw=48, fences=0 mpv:cs0-3473 [002] ..... 129.172478: amdgpu_cs: ring=0, dw=48, fences=0 Fixes: 4624459c84d7 ("drm/amdgpu: add gang submit frontend v6") Signed-off-by: Leo Liu Reviewed-by: Christian König Signed-off-by: Alex Deucher