Message-ID: <20260113170803.6e5ebedb@fedora>
Date: Tue, 13 Jan 2026 17:08:03 +0100
From: Boris Brezillon <boris.brezillon@...labora.com>
To: Ulf Hansson <ulf.hansson@...aro.org>
Cc: Nicolas Frattaroli <nicolas.frattaroli@...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>, Rob Herring
 <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Matthias Brugger <matthias.bgg@...il.com>,
 AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
 Chen-Yu Tsai <wenst@...omium.org>, Chia-I Wu <olvaffe@...il.com>,
 kernel@...labora.com, dri-devel@...ts.freedesktop.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-mediatek@...ts.infradead.org,
 linux-pm@...r.kernel.org
Subject: Re: [PATCH v2 0/4] Make MT8196 get its Mali GPU shader_present from
 nvmem

On Mon, 29 Dec 2025 12:52:13 +0100
Ulf Hansson <ulf.hansson@...aro.org> wrote:

> On Sat, 20 Dec 2025 at 19:50, Nicolas Frattaroli
> <nicolas.frattaroli@...labora.com> wrote:
> >
> > The MediaTek MT8196 SoC's Mali SHADER_PRESENT register does not list
> > only functional shader cores, but also those that are fused off to
> > improve yield.
> >
> > The SHADER_PRESENT bitmask with the one fused off core omitted is to be
> > found in an efuse. However, the efuse address is considered
> > confidential, and is not public knowledge.
> >
> > The MT8196 GPUEB MCU, which does the power management for the Mali GPU
> > on this SoC, knows and reads the efuse however, and exposes it in the
> > shared memory intended to communicate state to the application
> > processor. Reading the bitmask from this shared memory area is the
> > vendor's intended solution.
> >
> > This series models this in the binding and implements it in the
> > corresponding Linux drivers:
> > - the mali-valhall-csf binding gets an nvmem-cells/nvmem-cell-names
> >   property to declare that shader-present is in a different castle
> > - the mt8196-gpufreq binding requires nodes to expose the shader-present
> >   cell
> > - panthor checks for the presence of the shader-present cell and uses it
> >   as the shader-present value if it's found, instead of the Mali GPU
> >   register contents
> > - mtk-mfg-pmdomain becomes an nvmem provider and will happily serve
> >   queries for the shader-present cell
> >
> > While it would be preferable if we could read the efuse directly, it's
> > not possible as things stand, and insisting on it will just keep this
> > hardware from working in mainline. Running a GPU workload with a
> > SHADER_PRESENT bitmask that includes a faulty core results in corrupt
> > GPU rendering output.
> >
> > Modelling the mt8196-gpufreq device as a nvmem-cell provider however is
> > not lying about the hardware's capabilities, as it truly does provide
> > access to the nvmem-cell, even if it acts as a proxy.
> >
> > From a bindings and panthor perspective, this is also generic enough to
> > where hypothetical other vendors doing the same thing (even with direct
> > efuse access) can rely on the same cell name and implementation.
> >
> > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>  
> 
> I have applied the pmdomain changes in patch2 and patch 4 for next, thanks!
> 
> I assume the gpu changes will be funneled via another tree, but let me
> know if there is a reason to keep these changes together.

Yep, I just queued the remaining two patches to drm-misc-next.

Thanks,

Boris

Powered by blists - more mailing lists