[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <3154579.irdbgypaU6@workhorse>
Date: Fri, 23 Jan 2026 13:52:19 +0100
From: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
To: Sasha Levin <sashal@...nel.org>
Cc: Boris Brezillon <boris.brezillon@...labora.com>,
Steven Price <steven.price@....com>, Liviu Dudau <liviu.dudau@....com>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
Chia-I Wu <olvaffe@...il.com>, Karunika Choo <karunika.choo@....com>,
kernel@...labora.com, linux-kernel@...r.kernel.org,
dri-devel@...ts.freedesktop.org
Subject:
Re: [PATCH v10 3/4] drm/panthor: Add tracepoint for hardware utilisation
changes
On Friday, 23 January 2026 05:02:21 Central European Standard Time Sasha Levin wrote:
> Hi Nicolas,
>
> On Fri, Jan 16, 2026 at 01:57:32PM +0100, Nicolas Frattaroli wrote:
> >Mali GPUs have three registers that indicate which parts of the hardware
> >are powered at any moment. These take the form of bitmaps. In the case
> >of SHADER_READY for example, a high bit indicates that the shader core
> >corresponding to that bit index is powered on. These bitmaps aren't
> >solely contiguous bits, as it's common to have holes in the sequence of
> >shader core indices, and the actual set of which cores are present is
> >defined by the "shader present" register.
> >
> >When the GPU finishes a power state transition, it fires a
> >GPU_IRQ_POWER_CHANGED_ALL interrupt. After such an interrupt is
> >received, the _READY registers will contain new interesting data. During
> >power transitions, the GPU_IRQ_POWER_CHANGED interrupt will fire, and
> >the registers will likewise contain potentially changed data.
> >
> >This is not to be confused with the PWR_IRQ_POWER_CHANGED_ALL interrupt,
> >which is something related to Mali v14+'s power control logic. The
> >_READY registers and corresponding interrupts are already available in
> >v9 and onwards.
> >
> >Expose the data as a tracepoint to userspace. This allows users to debug
> >various scenarios and gather interesting information, such as: knowing
> >how much hardware is lit up at any given time, correlating graphics
> >corruption with a specific powered shader core, measuring when hardware
> >is allowed to go to a powered off state again, and so on.
> >
> >The registration/unregistration functions for the tracepoint go through
> >a wrapper in panthor_hw.c, so that v14+ can implement the same
> >tracepoint by adding its hardware specific IRQ on/off callbacks to the
> >panthor_hw.ops member.
> >
> >Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
> >---
> > drivers/gpu/drm/panthor/panthor_gpu.c | 28 +++++++++++++++
> > drivers/gpu/drm/panthor/panthor_gpu.h | 2 ++
> > drivers/gpu/drm/panthor/panthor_hw.c | 62 +++++++++++++++++++++++++++++++++
> > drivers/gpu/drm/panthor/panthor_hw.h | 8 +++++
> > drivers/gpu/drm/panthor/panthor_trace.h | 58 ++++++++++++++++++++++++++++++
> > 5 files changed, 158 insertions(+)
> >
> >diff --git a/drivers/gpu/drm/panthor/panthor_gpu.c b/drivers/gpu/drm/panthor/panthor_gpu.c
> >index 9304469a711a..2ab444ee8c71 100644
> >--- a/drivers/gpu/drm/panthor/panthor_gpu.c
> >+++ b/drivers/gpu/drm/panthor/panthor_gpu.c
> >@@ -22,6 +22,9 @@
> > #include "panthor_hw.h"
> > #include "panthor_regs.h"
> >
> >+#define CREATE_TRACE_POINTS
> >+#include "panthor_trace.h"
>
> With this commit, I'm seeing:
>
> In file included from drivers/gpu/drm/panthor/panthor_trace.h:86,
> from drivers/gpu/drm/panthor/panthor_gpu.c:26:
> ./include/trace/define_trace.h:118:42: fatal error: ./panthor_trace.h: No such file or directory
> 118 | #include TRACE_INCLUDE(TRACE_INCLUDE_FILE)
>
> I think we need to add in 'CFLAGS_panthor_gpu.o := -I$(src)' to the Makefile
> too, but I haven't tested that yet.
>
>
Huh, puzzling that I never ran into this build failure.
Doing another build right now, I still can't reproduce it even on a clean
build without ccache. Your fix looks appropriate though judging by the LWM[1]
series on event tracepoints.
I'll submit a fix for this.
Link: https://lwn.net/Articles/383362/ [1]
Powered by blists - more mailing lists