drm/panthor: initial mt8196 support

MediaTek MT8196 has Mali-G925-Immortalis, which can be supported by panthor.

Quoted 2 lines · Chia-I Wu

MediaTek MT8196 has Mali-G925-Immortalis, which can be supported by panthor.

What is panthor? Please describe here hardware or provide some explanations of not-that-known hardware names (if panthos is that).

Best regards,
Krzysztof

Quoted 8 lines · On Wed, 3 Sep 2025 15:55:04 -0700 Chia-I Wu <[email protected]> wrote:

drivers/gpu/drm/panthor/Makefile +0 -0

index 02db21748c125..75e92c461304b 100644
@@ -12,4 +12,6 @@ panthor-y := \
      panthor_mmu.o \
      panthor_sched.o
 

drivers/gpu/drm/panthor/Makefile panthor-y := \ · line 15

Quoted 1 line

drivers/gpu/drm/panthor/Makefile +1 -0

+panthor-$(CONFIG_DRM_PANTHOR_SOC_MT8196) += panthor_soc_mt8196.o

Based on the stuff you describe (ASN hash, core mask read from an nvmem cell, extra clks/regulators?), I don't think we need per-soc source files and per-soc config options. If it becomes too HW specific (no abstraction to make it SoC-agnostic), we can reconsider the per-SoC file approach, but I believe it can all live in panthor_drv.c for now.

Quoted 12 lines · Boris Brezillon

Quoted 8 lines · On Wed, 3 Sep 2025 15:55:04 -0700 Chia-I Wu <[email protected]> wrote:

drivers/gpu/drm/panthor/Makefile +0 -0

index 02db21748c125..75e92c461304b 100644
@@ -12,4 +12,6 @@ panthor-y := \
      panthor_mmu.o \
      panthor_sched.o
 

Quoted 7 lines

drivers/gpu/drm/panthor/Makefile panthor-y := \ · line 15

Quoted 1 line

drivers/gpu/drm/panthor/Makefile +1 -0

+panthor-$(CONFIG_DRM_PANTHOR_SOC_MT8196) += panthor_soc_mt8196.o

Based on the stuff you describe (ASN hash, core mask read from an nvmem cell, extra clks/regulators?), I don't think we need per-soc source files and per-soc config options. If it becomes too HW specific (no abstraction to make it SoC-agnostic), we can reconsider the per-SoC file approach, but I believe it can all live in panthor_drv.c for now.

That's about right except no extra clk/regulator is needed.

gpueb on mt8196 is yet another mcu running on its own fw. It can provide clk/regulator to panthor and no change is needed from panthor. But it can also do dvfs autonomously, in which case panthor needs to be modified to make clk/regulator/devfreq optional. I think the latter is where Nicolas Frattaroli is going and requires more invasive integration.

The clk/regulator provider on MT8196 is GPUEB, whose driver[1] needs to be cleaned up and upstreamed separately.

Quoted 21 lines · Chia-I Wu

Quoted 12 lines · Boris Brezillon

Quoted 8 lines · On Wed, 3 Sep 2025 15:55:04 -0700 Chia-I Wu <[email protected]> wrote:

drivers/gpu/drm/panthor/Makefile +0 -0

index 02db21748c125..75e92c461304b 100644
@@ -12,4 +12,6 @@ panthor-y := \
      panthor_mmu.o \
      panthor_sched.o
 

Quoted 7 lines

drivers/gpu/drm/panthor/Makefile panthor-y := \ · line 15

Quoted 1 line

drivers/gpu/drm/panthor/Makefile +1 -0

+panthor-$(CONFIG_DRM_PANTHOR_SOC_MT8196) += panthor_soc_mt8196.o

Based on the stuff you describe (ASN hash, core mask read from an nvmem cell, extra clks/regulators?), I don't think we need per-soc source files and per-soc config options. If it becomes too HW specific (no abstraction to make it SoC-agnostic), we can reconsider the per-SoC file approach, but I believe it can all live in panthor_drv.c for now.

Quoted 8 lines

That's about right except no extra clk/regulator is needed.

gpueb on mt8196 is yet another mcu running on its own fw. It can provide clk/regulator to panthor and no change is needed from panthor. But it can also do dvfs autonomously, in which case panthor needs to be modified to make clk/regulator/devfreq optional. I think the latter is where Nicolas Frattaroli is going and requires more invasive integration.

Hi Chia-I Wu,

I beleive the changes your are proposing need to be treated as 3 different features:

1. Handling of ASN hash
2. clk/regulator registration
3. Core Mask control in Panthor

* For 1. since it is a GPU HW property, have you considered handling it in the DTB as HW quirk?

Pass the value of the register from the DTB, then Panthor driver applies a mask to filter the bits and then configre the HW regs

Quoted 3 lines

The clk/regulator provider on MT8196 is GPUEB, whose driver[1] needs to be cleaned up and upstreamed separately.

* For 2. Have you considered making the GPUEB MTK driver act as a clock/regulator supplier?

Without a clocks, the driver won't be able to support instrumenation.

And without a regulator or clock, how will system/runtime PM suspend/resume be handled in the driver?

* For 3. I think this is a more complex topic and other vendors may have different needs.

At first glance, panthor_soc_data does not seem to be sufficient to cope with other vendors.

What would be the protocole used to communicate wth MCU? Can the MCU update the core mask on its own? Will the core mask change at runtime?

If the core mask is static, what about adding a DTB entry?

Kind regards,
Florent

MediaTek MT8196 has Mali-G925-Immortalis, for which panthor gained support recently. But the soc also requires custom ASN hash to be enabled. This series introduces panthor_soc_data for per-soc data and uses it to enable custom ASN hash on MT8196.

The clk/regulator provider on MT8196 is GPUEB, whose driver[1] needs to be cleaned up and upstreamed separately.

This initial support also lacks support for some hw configs. On some configs, panthor is expected to query a mask from efuse to mask out unavailable shader cores from ptdev->gpu_info.shader_present. This requires extending panthor_soc_data with a callback to read the mask.

This is an RFC because the dependent drivers are not ready yet. But I would like to gather opinions on having panthor_soc_data for soc-specific data and having CONFIG_DRM_PANTHOR_SOC_MT8196 for soc-specific code.

[1] https://gitlab.freedesktop.org/olv/kernel/-/commit/170d5fc90f817dc90bde54b32872c59cf5c77779

Chia-I Wu (2):
dt-bindings: gpu: mali-valhall-csf: add MediaTek MT8196 compatible drm/panthor: add initial mt8196 support

 .../bindings/gpu/arm,mali-valhall-csf.yaml    |  1 +
 drivers/gpu/drm/panthor/Kconfig               |  6 +++++
 drivers/gpu/drm/panthor/Makefile              |  2 ++
 drivers/gpu/drm/panthor/panthor_device.c      |  2 ++
 drivers/gpu/drm/panthor/panthor_device.h      |  4 +++
 drivers/gpu/drm/panthor/panthor_drv.c         |  4 +++
 drivers/gpu/drm/panthor/panthor_gpu.c         | 26 ++++++++++++++++++-
 drivers/gpu/drm/panthor/panthor_regs.h        |  4 +++
 drivers/gpu/drm/panthor/panthor_soc.h         | 26 +++++++++++++++++++
 drivers/gpu/drm/panthor/panthor_soc_mt8196.c  |  9 +++++++
 10 files changed, 83 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/panthor/panthor_soc.h
 create mode 100644 drivers/gpu/drm/panthor/panthor_soc_mt8196.c

Hi,

Quoted 7 lines · On Thursday, 4 September 2025 00:55:02 Central European Summer Time Chia-I Wu…

MediaTek MT8196 has Mali-G925-Immortalis, for which panthor gained support recently. But the soc also requires custom ASN hash to be enabled. This series introduces panthor_soc_data for per-soc data and uses it to enable custom ASN hash on MT8196.

The clk/regulator provider on MT8196 is GPUEB, whose driver[1] needs to be cleaned up and upstreamed separately.

I'm currently working on this, I'm at a functional 800 LoC driver vs the more than 30k LoC of the downstream... thing. I intend to send it in as an RFC once the clock stuff lands, and I get some responses wrt to figuring out what's still missing from linux-next aside from the DT to get basic boot working so that I don't send in something that I accidentally shredded during a rebase without noticing.

Cleaning up the downstream driver is a fool's errand, it's like 6? separate drivers, with lots of global state (and no locking), without using the common clock framework, and relying on abusing -supply DT properties to force a certain probe order to make all the race conditions it would otherwise have turn out fine. A lot of it is code that seems dead, or wrappers wrapping wrappers that have nothing to do with how the hardware actually works.

My solution adds a small mailbox driver for the GPUEB, and also adds a new module that lives in the panthor tree and registers itself with panthor's devfreq stuff to be a "devfreq provider". The motivation for making it devfreq instead of a clock+regulator provider is that the GPUEB seems to have several quite devfreq-like parts to it that I am not yet using, namely setting a job completion target time and several methods of limiting performance.

As it stands it can set the OPP, but boosting above 1.43 GHz does not seem to stick. The boosting stuff may be done by the four or five other ways it has to set some frequency target.

I'm hoping I can send this in maybe next week or the week after. If things remain blocked by then it'll be compile-tested in its current form only and lack some clock stuff.

Kind regards,
Nicolas Frattaroli

Quoted 32 lines

This initial support also lacks support for some hw configs. On some configs, panthor is expected to query a mask from efuse to mask out unavailable shader cores from ptdev->gpu_info.shader_present. This requires extending panthor_soc_data with a callback to read the mask.

This is an RFC because the dependent drivers are not ready yet. But I would like to gather opinions on having panthor_soc_data for soc-specific data and having CONFIG_DRM_PANTHOR_SOC_MT8196 for soc-specific code.

[1] https://gitlab.freedesktop.org/olv/kernel/-/commit/170d5fc90f817dc90bde54b32872c59cf5c77779

Chia-I Wu (2):
dt-bindings: gpu: mali-valhall-csf: add MediaTek MT8196 compatible drm/panthor: add initial mt8196 support

 .../bindings/gpu/arm,mali-valhall-csf.yaml    |  1 +
 drivers/gpu/drm/panthor/Kconfig               |  6 +++++
 drivers/gpu/drm/panthor/Makefile              |  2 ++
 drivers/gpu/drm/panthor/panthor_device.c      |  2 ++
 drivers/gpu/drm/panthor/panthor_device.h      |  4 +++
 drivers/gpu/drm/panthor/panthor_drv.c         |  4 +++
 drivers/gpu/drm/panthor/panthor_gpu.c         | 26 ++++++++++++++++++-
 drivers/gpu/drm/panthor/panthor_regs.h        |  4 +++
 drivers/gpu/drm/panthor/panthor_soc.h         | 26 +++++++++++++++++++
 drivers/gpu/drm/panthor/panthor_soc_mt8196.c  |  9 +++++++
 10 files changed, 83 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/panthor/panthor_soc.h
 create mode 100644 drivers/gpu/drm/panthor/panthor_soc_mt8196.c

Hi,

Quoted 7 lines · On Thursday, 4 September 2025 00:55:02 Central European Summer Time Chia-I Wu…

MediaTek MT8196 has Mali-G925-Immortalis, for which panthor gained support recently. But the soc also requires custom ASN hash to be enabled. This series introduces panthor_soc_data for per-soc data and uses it to enable custom ASN hash on MT8196.

The clk/regulator provider on MT8196 is GPUEB, whose driver[1] needs to be cleaned up and upstreamed separately.

I'm currently working on this, I'm at a functional 800 LoC driver vs the more than 30k LoC of the downstream... thing. I intend to send it in as an RFC once the clock stuff lands, and I get some responses wrt to figuring out what's still missing from linux-next aside from the DT to get basic boot working so that I don't send in something that I accidentally shredded during a rebase without noticing.

Cleaning up the downstream driver is a fool's errand, it's like 6? separate drivers, with lots of global state (and no locking), without using the common clock framework, and relying on abusing -supply DT properties to force a certain probe order to make all the race conditions it would otherwise have turn out fine. A lot of it is code that seems dead, or wrappers wrapping wrappers that have nothing to do with how the hardware actually works.

My solution adds a small mailbox driver for the GPUEB, and also adds a new module that lives in the panthor tree and registers itself with panthor's devfreq stuff to be a "devfreq provider". The motivation for making it devfreq instead of a clock+regulator provider is that the GPUEB seems to have several quite devfreq-like parts to it that I am not yet using, namely setting a job completion target time and several methods of limiting performance.

As it stands it can set the OPP, but boosting above 1.43 GHz does not seem to stick. The boosting stuff may be done by the four or five other ways it has to set some frequency target.

I'm hoping I can send this in maybe next week or the week after. If things remain blocked by then it'll be compile-tested in its current form only and lack some clock stuff.

Kind regards,
Nicolas Frattaroli

Quoted 32 lines

This initial support also lacks support for some hw configs. On some configs, panthor is expected to query a mask from efuse to mask out unavailable shader cores from ptdev->gpu_info.shader_present. This requires extending panthor_soc_data with a callback to read the mask.

This is an RFC because the dependent drivers are not ready yet. But I would like to gather opinions on having panthor_soc_data for soc-specific data and having CONFIG_DRM_PANTHOR_SOC_MT8196 for soc-specific code.

[1] https://gitlab.freedesktop.org/olv/kernel/-/commit/170d5fc90f817dc90bde54b32872c59cf5c77779

Chia-I Wu (2):
dt-bindings: gpu: mali-valhall-csf: add MediaTek MT8196 compatible drm/panthor: add initial mt8196 support

 .../bindings/gpu/arm,mali-valhall-csf.yaml    |  1 +
 drivers/gpu/drm/panthor/Kconfig               |  6 +++++
 drivers/gpu/drm/panthor/Makefile              |  2 ++
 drivers/gpu/drm/panthor/panthor_device.c      |  2 ++
 drivers/gpu/drm/panthor/panthor_device.h      |  4 +++
 drivers/gpu/drm/panthor/panthor_drv.c         |  4 +++
 drivers/gpu/drm/panthor/panthor_gpu.c         | 26 ++++++++++++++++++-
 drivers/gpu/drm/panthor/panthor_regs.h        |  4 +++
 drivers/gpu/drm/panthor/panthor_soc.h         | 26 +++++++++++++++++++
 drivers/gpu/drm/panthor/panthor_soc_mt8196.c  |  9 +++++++
 10 files changed, 83 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/panthor/panthor_soc.h
 create mode 100644 drivers/gpu/drm/panthor/panthor_soc_mt8196.c