Re: [PATCH 01/13] drm/msm: Remove obsolete perf infrastructure

[Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>]

On Tue, Apr 21, 2026 at 01:48:40PM -0700, Rob Clark wrote:
> On Tue, Apr 21, 2026 at 8:39 AM Dmitry Baryshkov
> <dmitry.baryshkov@oss.qualcomm.com> wrote:
> >
> > On Tue, Apr 21, 2026 at 06:07:20AM -0700, Rob Clark wrote:
> > > On Mon, Apr 20, 2026 at 4:49 PM Dmitry Baryshkov
> > > <dmitry.baryshkov@oss.qualcomm.com> wrote:
> > > >
> > > > On Mon, Apr 20, 2026 at 03:25:23PM -0700, Rob Clark wrote:
> > > > > Outside of a3xx, this was never really used.  And it low-key gets in the
> > > > > way of the new perfcntr support (or at least it is confusing to have two
> > > > > things called "perf").  So lets remove it.
> > > > >
> > > > > This drops the "perf" debugfs file.  But these days, nvtop is a better
> > > > > option.  (Plus perfetto for newer gens.)
> > > >
> > > > Would it be possible to resurrect "perf" later? It was really useful.
> > >
> > > Nothing is impossible.. but I was having trouble naming things with
> > > both old and new perf stuff in parallel.
> >
> > That why I wrote about resurrecting it later, once the new stuff is in.
> >
> > BTW: do you plan to get perf counters for a3xx-a5xx back? I remember
> > that there was some issue with a2xx ABI.
> 
> So current state on userspace side is that only a3xx/a4xx are missing
> perfcntr support..  although it looks like we know the countable
> enums, so probably not hard[*]
> 
> In all cases, the existing userspace-only support will continue to
> work.  The main reasons I omitted a2xx/a5xx on the kernel side are:
> 
> a) Not really sure how to do the Makefile bits.. since they wouldn't
> be using a6xx.xml.  In meson I can use a table (2d-array):
>     https://gitlab.freedesktop.org/robclark/mesa/-/blob/fd/generate-perfcntrs/src/freedreno/registers/adreno/meson.build?ref_type=heads#L20

I saw the comment in the commit. I'll take a quick look.

> b) No good setup to test

We probably need to figure this out...

> c) They don't have IFPC
> 
> They could ofc be added later.  The main urgency is a8xx, since I
> don't want to add mesa perfcntr support without PERFCNTR_CONFIG (so
> that we don't have an older-userspace, new-kernel permutation on
> a8xx+).

Sure.

> 
> I don't remember about a2xx ABI issue.. but a2xx perfcntr stuff was
> added after I was already busy with later gens.

I might be completely mistaken, but I think the issue was that the
kernel didn't reserve one of the counters for its own usage.

> 
> BR,
> -R
> 
> [*] there are some counter groups that had some slightly different
> config programming, like separate clear/enable regs.. which I haven't
> dealt with yet.  For a6xx+ this only matters for some counter groups
> (VBIF/GBIF, maybe GMU?) that userspace doesn't care as much about.
> Idk if that was true for the earlier gens.  Eventually I'll add a6xx+
> support for these counters, but there are a few other things to deal
> with first.
> 
> > > Is it really adding value
> > > over nvtop?

And I skipped this question. Yes, there is a value, when developing /
performing early testing. Running tail is much easier than having an
extra tool in the initramfs (we don't have nvtop recipe in the OE, maybe
that should be changed).

-- 
With best wishes
Dmitry