On Mon, 29 Dec 2025 12:52:13 +0100 Ulf Hansson <[email protected]> wrote:
> On Sat, 20 Dec 2025 at 19:50, Nicolas Frattaroli > <[email protected]> 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 <[email protected]> > > 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
