From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id CF1C4D6CFBA for ; Fri, 23 Jan 2026 04:02:25 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id C3DE310E00A; Fri, 23 Jan 2026 04:02:24 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="A8fAVajn"; dkim-atps=neutral Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by gabe.freedesktop.org (Postfix) with ESMTPS id 7216810E00A for ; Fri, 23 Jan 2026 04:02:23 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id DBCA4416A6; Fri, 23 Jan 2026 04:02:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8987AC4CEF1; Fri, 23 Jan 2026 04:02:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769140942; bh=TMYM5m6tGo28iUrjDUIioNIuoRZ0IBLsfkBfGo+hI/A=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=A8fAVajn8xx+yw78n5luW+wQ0gVPWi09I8gQJoeotJwUNgQ3ivif3/raj6NXL1t4n 5wgqMnhkNW9+uMmkdKvLjRFMzR3CLb+JDDSSqD5zTNkjHD0GmUUuKihAHpBekKP6io /2BRorhb8YKSZjnrZddEbmiz+WtglKND4CP5Z7XxjwzD0NyqWBkjxXC+2QSoCjrA2R X+FXWlI1PVNAL4nxnhI05CxgXymDXCRRSzqeV0Al+wikKNozfIeJDibRGqIoqSpJrw C20pe/ez7ip+F1Fxdq/6LnxNHGUETc5e7Ccgp6c0Ctrg7SynNcmw0ueFf81/TcV2sz Nt68QZIQ1o7Rg== Date: Thu, 22 Jan 2026 23:02:21 -0500 From: Sasha Levin To: Nicolas Frattaroli Cc: Boris Brezillon , Steven Price , Liviu Dudau , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Chia-I Wu , Karunika Choo , kernel@collabora.com, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org Subject: Re: [PATCH v10 3/4] drm/panthor: Add tracepoint for hardware utilisation changes Message-ID: References: <20260116-panthor-tracepoints-v10-0-d925986e3d1b@collabora.com> <20260116-panthor-tracepoints-v10-3-d925986e3d1b@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20260116-panthor-tracepoints-v10-3-d925986e3d1b@collabora.com> X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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 >--- > 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. -- Thanks, Sasha