linux-kernel - Re: [PATCH 1/2] drm/panthor: Add tracepoint for hardware utilisation changes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAPaKu7SQP9jYmq5UCA98_YmO50st6ChBjYNjYNON7-YAWozzaQ@mail.gmail.com>
Date: Fri, 5 Dec 2025 13:16:44 -0800
From: Chia-I Wu <olvaffe@...il.com>
To: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
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>, kernel@...labora.com, 
	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH 1/2] drm/panthor: Add tracepoint for hardware utilisation changes

On Fri, Dec 5, 2025 at 2:48 AM Nicolas Frattaroli
<nicolas.frattaroli@...labora.com> wrote:
>
> On Thursday, 4 December 2025 21:21:08 Central European Standard Time Chia-I Wu wrote:
> > On Wed, Dec 3, 2025 at 6:04 AM Nicolas Frattaroli
> > <nicolas.frattaroli@...labora.com> wrote:
> > >
> > > Mali GPUs have three registers that indicate which parts of the hardware
> > > are powered and active at any moment. These take the form of bitmaps. In
> > > the case of SHADER_PWRACTIVE for example, a high bit indicates that the
> > > shader core corresponding to that bit index is active. 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 PWRACTIVE registers will likely contain interesting new
> > > information.
> > I am seeing
> >
> >    irq/342-panthor-412     [000] .....   934.526754: gpu_power_active:
> > shader_bitmap=0x0 tiler_bitmap=0x0 l2_bitmap=0x0
> >    irq/342-panthor-412     [000] .....   936.640356: gpu_power_active:
> > shader_bitmap=0x0 tiler_bitmap=0x0 l2_bitmap=0x0
> >
> > on a gpu-bound test. It does not look like collecting samples on
> > GPU_IRQ_POWER_CHANGED_ALL gives too much info.
>
> On what GPU and SoC is that? If it's MT8196 then I wouldn't be
> surprised if it just broke that hardware register, considering
> what it did to the SHADER_PRESENT register.
Indeed I was on mt8196.
>
> On RK3588 (v10), GPU_IRQ_POWER_CHANGED_ALL reliably fires when
> there is new information available in those registers. I haven't
> tried on MT8196 (v13) yet because that still doesn't boot with
> mainline so testing anything is a pain.
>
> I don't have any v12 or v11 hardware to test with. From what I
> understand, there's no open enough platform to do v11 testing on,
> just the Pixel 8 and Pixel 9. I could look into the Cix SoC for v12
> though some day, but I don't own one at the moment.
>
> >
> > I think they are more useful to be collected periodically, such that
> > we know that in the past X seconds, Y out of a total of Z samples
> > indicates activities. That's best done in userspace, and panthor's
> > role should be to provide an uapi such as
> > https://lore.kernel.org/all/cover.1743517880.git.lukas.zapolskas@arm.com/.
>
> This wouldn't give you information on the time a power transition has
> completed, which is one of the motivations. A periodically collected
> PWRACTIVE would just be roughly correlated to how busy the GPU is,
> which isn't very useful additional information as the performance
> counters themselves are likely a better source of that kind of info.
{SHADER,TILER,L2}_READY might be more appropriate if you want to trace
power transitions?

>
> What I need to do is restrict this to <= v13 in the next revision
> however, because v14 reworks this stuff.
>
> Kind regards,
> Nicolas Frattaroli
>
>