Re: [PATCH v2 13/14] drm/msm/a8xx: Switch to generated protect regs

[Rob Clark <rob.clark@oss.qualcomm.com>]

On Thu, Oct 22, 2026 at 1:27 AM Konrad Dybcio
<konrad.dybcio@oss.qualcomm.com> wrote:
>
> On 10/21/26 10:41 PM, Rob Clark wrote:
> > These also fix some perfcntr SEL regs which were mistakenly blocked
> > since we previously just copied the protect tables from downstream kgsl
> > (and only sometimes remembered to fix these).
> >
> > Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
> > ---
>
> LLM summary in case anyone is interested:
>
> - Almost nothing carries over unchanged. Only 22–34 entries per GPU match exactly, out of 47–64 in each table.
> - The generated tables use finer-grained ranges. For example, NORDWR 0x8600, 0x1ff becomes several smaller ranges (0x8600/0xf, 0x8700/0xf, 0x8740/0xbf, and so on).

Most of the change comes from exposing perfcntr SEL regs, which was a
bug that we hadn't noticed yet.  (Kgsl blocks these and requires ioctl
to configure counter... but upstream the kernel just reserves counters
and UMD configures them.. so we can use the same counter to measure
different things per subpass in vk)

That in turn required some optimizations, since otherwise we run out
of protect spans.  For example skipping a UMDRO range if it is only
protecting regs that are already RO at hw level.

> - Several ranges that were RDONLY before are now NORDWR, or the other way round, and some change length. Some ranges appear only in the new tables, such as 0xd200/0x3ff and 0x20000–0x27810 on maili.
> - The generated tables don't reproduce some old ranges exactly. 0xfc00/0x1fff and 0x3cc6/0x1fff, for example, are not in the new tables. I didn't check whether the new tables still protect that address space.
> - count_max goes from 15 to 64 for x285, a840 and a850. The old 15 was already below the 47–57 entries those tables held. Patch 13 also adds BUILD_BUG_ON checks for all six protect tables. Before, only a810 and a830 were checked, so the old mismatch went unnoticed.

yeah, 15 was a bug

> Also one robo-worry:
>
> Unexpected: on hawi, GRAS_PERFCTR_TSEFE_SEL at 0x8610 is still
> blocked, because the new NORDWR 0x8600, 0x10f entry covers it.

-ETOOFEWREGS but, since mesa isn't using these counters I had to skip
exposing them specifically on Hawi.  I have an idea to use
CP_PROTECT_PIPE to give us a few more ranges, but that would require
some more changes, so skipped for now

BR,
-R