From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 21CEB262808 for ; Fri, 23 Jan 2026 04:02:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769140945; cv=none; b=CAiMbuIwTLbPvMyrwc8cmZbyVCsVbu01BVytJRzAXpXNJ8OmB7NT5TcDW/s9yOz8YPDwvv9IVVNWmeQ3SZeGz0PwIwtcUu+PTqIvXS3XQAUZwHrIEBISVDElx4a09n+UingH9/VbLYwEWLwLAYnO2F5mjLrlCFVvdMWxNkjJ2U0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769140945; c=relaxed/simple; bh=TMYM5m6tGo28iUrjDUIioNIuoRZ0IBLsfkBfGo+hI/A=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=eXHWobzPFdVr+/h5e2YHXo6ODnreUmqJZgpiRJJ4LPLvYdNaf5p/3qIaH8pAuRnyx8hJksrV5ZWvg+03gfW4TDtO1ey2Z8mNG3loI4UTBTIcdkUHBE+EUXdUYiFBbKfsr/i90fvgpuJjyncGZr5SCh4KQ7gJzrwommBoCj9ZSBg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=A8fAVajn; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="A8fAVajn" 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> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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> 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