summaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorNicolas Frattaroli <nicolas.frattaroli@collabora.com>2026-01-16 15:57:33 +0300
committerBoris Brezillon <boris.brezillon@collabora.com>2026-01-22 17:15:35 +0300
commit15bd2f5d52de890f745ac0c60a44cd27d095bb0d (patch)
tree92e4b520ae8e6fc34c359b8a9101e93e9fadeeac /include
parent52ebfd8d2feb1f37bc75c6b662b620323de676ea (diff)
downloadlinux-15bd2f5d52de890f745ac0c60a44cd27d095bb0d.tar.xz
drm/panthor: Add gpu_job_irq tracepoint
Mali's CSF firmware triggers the job IRQ whenever there's new firmware events for processing. While this can be a global event (BIT(31) of the status register), it's usually an event relating to a command stream group (the other bit indices). Panthor throws these events onto a workqueue for processing outside the IRQ handler. It's therefore useful to have an instrumented tracepoint that goes beyond the generic IRQ tracepoint for this specific case, as it can be augmented with additional data, namely the events bit mask. This can then be used to debug problems relating to GPU jobs events not being processed quickly enough. The duration_ns field can be used to work backwards from when the tracepoint fires (at the end of the IRQ handler) to figure out when the interrupt itself landed, providing not just information on how long the work queueing took, but also when the actual interrupt itself arrived. With this information in hand, the IRQ handler itself being slow can be excluded as a possible source of problems, and attention can be directed to the workqueue processing instead. Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patch.msgid.link/20260116-panthor-tracepoints-v10-4-d925986e3d1b@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions