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. Kind regards Uffe > --- > Changes in v2: > - panthor: move to nvmem_cell_read_variable_le_u64 > - mtk-mfg-pmdomain: put of_node in error path > - mtk-mfg-pmdomain: remove leftover stray of_node_put on NULL > - Link to v1: > https://lore.kernel.org/r/[email protected] > > --- > Nicolas Frattaroli (4): > dt-bindings: gpu: mali-valhall-csf: Add shader-present nvmem cell > dt-bindings: power: mt8196-gpufreq: Describe nvmem provider ability > drm/panthor: Implement reading shader_present from nvmem > pmdomain: mediatek: mtk-mfg: Expose shader_present as nvmem cell > > .../bindings/gpu/arm,mali-valhall-csf.yaml | 14 +++++ > .../bindings/power/mediatek,mt8196-gpufreq.yaml | 13 +++++ > drivers/gpu/drm/panthor/panthor_hw.c | 36 ++++++++++--- > drivers/pmdomain/mediatek/mtk-mfg-pmdomain.c | 59 > ++++++++++++++++++++++ > 4 files changed, 116 insertions(+), 6 deletions(-) > --- > base-commit: 638148c6ffa31d2e4958d51708ff3675221e2da7 > change-id: 20251217-mt8196-shader-present-e2dc3f97fc74 > > Best regards, > -- > Nicolas Frattaroli <[email protected]> >
