[RFC PATCH 0/2] drm/panthor: initial mt8196 support

[RFC PATCH 0/2] drm/panthor: initial mt8196 support

[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.

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

-- 
2.51.0.338.gd7d06c2dae-goog

[RFC PATCH 1/2] dt-bindings: gpu: mali-valhall-csf: add MediaTek MT8196 compatible

[Chia-I Wu]

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

Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
---
 Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
index a5b4e00217587..7ad5a3ffc5f5c 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
@@ -18,6 +18,7 @@ properties:
     oneOf:
       - items:
           - enum:
+              - mediatek,mt8196-mali
               - rockchip,rk3588-mali
           - const: arm,mali-valhall-csf   # Mali Valhall GPU model/revision is fully discoverable
 
-- 
2.51.0.338.gd7d06c2dae-goog

[RFC PATCH 2/2] drm/panthor: add initial mt8196 support

[Chia-I Wu]

Add panthor_soc_data to control custom ASN_HASH. Add compatible string
for "mediatek,mt8196-mali" and enable custom ASN_HASH for the soc.

Without custom ASN_HASH, FW fails to boot

  panthor 48000000.gpu: [drm] *ERROR* Unhandled Page fault in AS0 at VA 0x0000000000000000
  panthor 48000000.gpu: [drm] *ERROR* Failed to boot MCU (status=fatal)
  panthor 48000000.gpu: probe with driver panthor failed with error -110

With custom ASN_HASH, panthor probes fine and userspace boots to ui just
fine as well

  panthor 48000000.gpu: [drm] clock rate = 0
  panthor 48000000.gpu: EM: created perf domain
  panthor 48000000.gpu: [drm] Mali-G925-Immortalis id 0xd830 major 0x0 minor 0x1 status 0x5
  panthor 48000000.gpu: [drm] Features: L2:0x8130306 Tiler:0x809 Mem:0x301 MMU:0x2830 AS:0xff
  panthor 48000000.gpu: [drm] shader_present=0xee0077 l2_present=0x1 tiler_present=0x1
  panthor 48000000.gpu: [drm] Firmware protected mode entry not be supported, ignoring
  panthor 48000000.gpu: [drm] Firmware git sha: 27713280172c742d467a4b7d11180930094092ec
  panthor 48000000.gpu: [drm] CSF FW using interface v3.13.0, Features 0x10 Instrumentation features 0x71
  [drm] Initialized panthor 1.5.0 for 48000000.gpu on minor 1

Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
---
 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 +++++++
 9 files changed, 82 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/panthor/panthor_soc.h
 create mode 100644 drivers/gpu/drm/panthor/panthor_soc_mt8196.c

diff --git a/drivers/gpu/drm/panthor/Kconfig b/drivers/gpu/drm/panthor/Kconfig
index 55b40ad07f3b0..a207962cb518d 100644
--- a/drivers/gpu/drm/panthor/Kconfig
+++ b/drivers/gpu/drm/panthor/Kconfig
@@ -21,3 +21,9 @@ config DRM_PANTHOR
 
 	  Note that the Mali-G68 and Mali-G78, while Valhall architecture, will
 	  be supported with the panfrost driver as they are not CSF GPUs.
+
+config DRM_PANTHOR_SOC_MT8196
+	bool "Enable MediaTek MT8196 support"
+	depends on DRM_PANTHOR
+	help
+	  Enable SoC-specific code for MediaTek MT8196.
diff --git a/drivers/gpu/drm/panthor/Makefile b/drivers/gpu/drm/panthor/Makefile
index 02db21748c125..75e92c461304b 100644
--- a/drivers/gpu/drm/panthor/Makefile
+++ b/drivers/gpu/drm/panthor/Makefile
@@ -12,4 +12,6 @@ panthor-y := \
 	panthor_mmu.o \
 	panthor_sched.o
 
+panthor-$(CONFIG_DRM_PANTHOR_SOC_MT8196) += panthor_soc_mt8196.o
+
 obj-$(CONFIG_DRM_PANTHOR) += panthor.o
diff --git a/drivers/gpu/drm/panthor/panthor_device.c b/drivers/gpu/drm/panthor/panthor_device.c
index 81df49880bd87..c7033d82cef55 100644
--- a/drivers/gpu/drm/panthor/panthor_device.c
+++ b/drivers/gpu/drm/panthor/panthor_device.c
@@ -172,6 +172,8 @@ int panthor_device_init(struct panthor_device *ptdev)
 	struct page *p;
 	int ret;
 
+	ptdev->soc_data = of_device_get_match_data(ptdev->base.dev);
+
 	init_completion(&ptdev->unplug.done);
 	ret = drmm_mutex_init(&ptdev->base, &ptdev->unplug.lock);
 	if (ret)
diff --git a/drivers/gpu/drm/panthor/panthor_device.h b/drivers/gpu/drm/panthor/panthor_device.h
index 4fc7cf2aeed57..160977834e017 100644
--- a/drivers/gpu/drm/panthor/panthor_device.h
+++ b/drivers/gpu/drm/panthor/panthor_device.h
@@ -28,6 +28,7 @@ struct panthor_job;
 struct panthor_mmu;
 struct panthor_fw;
 struct panthor_perfcnt;
+struct panthor_soc_data;
 struct panthor_vm;
 struct panthor_vm_pool;
 
@@ -93,6 +94,9 @@ struct panthor_device {
 	/** @base: Base drm_device. */
 	struct drm_device base;
 
+	/** @soc_data: Optional SoC data. */
+	const struct panthor_soc_data *soc_data;
+
 	/** @phys_addr: Physical address of the iomem region. */
 	phys_addr_t phys_addr;
 
diff --git a/drivers/gpu/drm/panthor/panthor_drv.c b/drivers/gpu/drm/panthor/panthor_drv.c
index 9256806eb6623..061ba38dd1bad 100644
--- a/drivers/gpu/drm/panthor/panthor_drv.c
+++ b/drivers/gpu/drm/panthor/panthor_drv.c
@@ -33,6 +33,7 @@
 #include "panthor_mmu.h"
 #include "panthor_regs.h"
 #include "panthor_sched.h"
+#include "panthor_soc.h"
 
 /**
  * DOC: user <-> kernel object copy helpers.
@@ -1683,6 +1684,9 @@ static struct attribute *panthor_attrs[] = {
 ATTRIBUTE_GROUPS(panthor);
 
 static const struct of_device_id dt_match[] = {
+#ifdef CONFIG_DRM_PANTHOR_SOC_MT8196
+	{ .compatible = "mediatek,mt8196-mali", .data = &panthor_soc_data_mediatek_mt8196, },
+#endif
 	{ .compatible = "rockchip,rk3588-mali" },
 	{ .compatible = "arm,mali-valhall-csf" },
 	{}
diff --git a/drivers/gpu/drm/panthor/panthor_gpu.c b/drivers/gpu/drm/panthor/panthor_gpu.c
index db69449a5be09..e68001a330790 100644
--- a/drivers/gpu/drm/panthor/panthor_gpu.c
+++ b/drivers/gpu/drm/panthor/panthor_gpu.c
@@ -19,6 +19,7 @@
 #include "panthor_device.h"
 #include "panthor_gpu.h"
 #include "panthor_regs.h"
+#include "panthor_soc.h"
 
 /**
  * struct panthor_gpu - GPU block management data.
@@ -52,6 +53,28 @@ static void panthor_gpu_coherency_set(struct panthor_device *ptdev)
 		ptdev->coherent ? GPU_COHERENCY_PROT_BIT(ACE_LITE) : GPU_COHERENCY_NONE);
 }
 
+static void panthor_gpu_l2_config_set(struct panthor_device *ptdev)
+{
+	const struct panthor_soc_data *data = ptdev->soc_data;
+	u32 l2_config;
+	u32 i;
+
+	if (!data || !data->asn_hash_enable)
+		return;
+
+	if (GPU_ARCH_MAJOR(ptdev->gpu_info.gpu_id) < 11) {
+		drm_err(&ptdev->base, "Custom ASN hash not supported by the device");
+		return;
+	}
+
+	for (i = 0; i < ARRAY_SIZE(data->asn_hash); i++)
+		gpu_write(ptdev, GPU_ASN_HASH(i), data->asn_hash[i]);
+
+	l2_config = gpu_read(ptdev, GPU_L2_CONFIG);
+	l2_config |= GPU_L2_CONFIG_ASN_HASH_ENABLE;
+	gpu_write(ptdev, GPU_L2_CONFIG, l2_config);
+}
+
 static void panthor_gpu_irq_handler(struct panthor_device *ptdev, u32 status)
 {
 	gpu_write(ptdev, GPU_INT_CLEAR, status);
@@ -241,8 +264,9 @@ int panthor_gpu_l2_power_on(struct panthor_device *ptdev)
 			      hweight64(ptdev->gpu_info.shader_present));
 	}
 
-	/* Set the desired coherency mode before the power up of L2 */
+	/* Set the desired coherency mode and L2 config before the power up of L2 */
 	panthor_gpu_coherency_set(ptdev);
+	panthor_gpu_l2_config_set(ptdev);
 
 	return panthor_gpu_power_on(ptdev, L2, 1, 20000);
 }
diff --git a/drivers/gpu/drm/panthor/panthor_regs.h b/drivers/gpu/drm/panthor/panthor_regs.h
index 8bee76d01bf83..8fa69f33e911e 100644
--- a/drivers/gpu/drm/panthor/panthor_regs.h
+++ b/drivers/gpu/drm/panthor/panthor_regs.h
@@ -64,6 +64,8 @@
 
 #define GPU_FAULT_STATUS				0x3C
 #define GPU_FAULT_ADDR					0x40
+#define GPU_L2_CONFIG					0x48
+#define   GPU_L2_CONFIG_ASN_HASH_ENABLE			BIT(24)
 
 #define GPU_PWR_KEY					0x50
 #define  GPU_PWR_KEY_UNLOCK				0x2968A819
@@ -110,6 +112,8 @@
 
 #define GPU_REVID					0x280
 
+#define GPU_ASN_HASH(n)					(0x2C0 + ((n) * 4))
+
 #define GPU_COHERENCY_FEATURES				0x300
 #define GPU_COHERENCY_PROT_BIT(name)			BIT(GPU_COHERENCY_  ## name)
 
diff --git a/drivers/gpu/drm/panthor/panthor_soc.h b/drivers/gpu/drm/panthor/panthor_soc.h
new file mode 100644
index 0000000000000..784f4f359f0bb
--- /dev/null
+++ b/drivers/gpu/drm/panthor/panthor_soc.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0 or MIT */
+/* Copyright 2025 Google LLC */
+
+#ifndef __PANTHOR_SOC_H__
+#define __PANTHOR_SOC_H__
+
+#include <linux/types.h>
+
+struct panthor_device;
+
+/**
+ * struct panthor_soc_data - Panthor SoC Data
+ */
+struct panthor_soc_data {
+	/** @asn_hash_enable: True if GPU_L2_CONFIG_ASN_HASH_ENABLE must be set. */
+	bool asn_hash_enable;
+
+	/** @asn_hash: ASN_HASH values when asn_hash_enable is true. */
+	u32 asn_hash[3];
+};
+
+#ifdef CONFIG_DRM_PANTHOR_SOC_MT8196
+extern const struct panthor_soc_data panthor_soc_data_mediatek_mt8196;
+#endif
+
+#endif /* __PANTHOR_SOC_H__ */
diff --git a/drivers/gpu/drm/panthor/panthor_soc_mt8196.c b/drivers/gpu/drm/panthor/panthor_soc_mt8196.c
new file mode 100644
index 0000000000000..d85b2168c158c
--- /dev/null
+++ b/drivers/gpu/drm/panthor/panthor_soc_mt8196.c
@@ -0,0 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0 or MIT
+/* Copyright 2025 Google LLC */
+
+#include "panthor_soc.h"
+
+const struct panthor_soc_data panthor_soc_data_mediatek_mt8196 = {
+	.asn_hash_enable = true,
+	.asn_hash = { 0xb, 0xe, 0x0, },
+};
-- 
2.51.0.338.gd7d06c2dae-goog

Re: [RFC PATCH 2/2] drm/panthor: add initial mt8196 support

[Boris Brezillon]

On Wed,  3 Sep 2025 15:55:04 -0700
Chia-I Wu <olvaffe@gmail.com> wrote:

> diff --git a/drivers/gpu/drm/panthor/Makefile b/drivers/gpu/drm/panthor/Makefile
> index 02db21748c125..75e92c461304b 100644
> --- a/drivers/gpu/drm/panthor/Makefile
> +++ b/drivers/gpu/drm/panthor/Makefile
> @@ -12,4 +12,6 @@ panthor-y := \
>  	panthor_mmu.o \
>  	panthor_sched.o
>  
> +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.

Re: [RFC PATCH 1/2] dt-bindings: gpu: mali-valhall-csf: add MediaTek MT8196 compatible

[Krzysztof Kozlowski]

On Wed, Sep 03, 2025 at 03:55:03PM -0700, Chia-I Wu wrote:
> 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

Re: [RFC PATCH 0/2] drm/panthor: initial mt8196 support

[Nicolas Frattaroli]

Hi,

On Thursday, 4 September 2025 00:55:02 Central European Summer Time Chia-I Wu wrote:
> 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

> 
> 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
> 
> 

Re: [RFC PATCH 1/2] dt-bindings: gpu: mali-valhall-csf: add MediaTek MT8196 compatible

[Chia-I Wu]

On Thu, Sep 4, 2025 at 2:30 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Wed, Sep 03, 2025 at 03:55:03PM -0700, Chia-I Wu wrote:
> > 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).
Panthor is the DRM panthor driver (drivers/gpu/drm/panthor).  It
gained support for Mali-G925-Immortalis a few weeks ago.

>
> Best regards,
> Krzysztof
>

Re: [RFC PATCH 2/2] drm/panthor: add initial mt8196 support

[Chia-I Wu]

On Wed, Sep 3, 2025 at 11:02 PM Boris Brezillon
<boris.brezillon@collabora.com> wrote:
>
> On Wed,  3 Sep 2025 15:55:04 -0700
> Chia-I Wu <olvaffe@gmail.com> wrote:
>
> > diff --git a/drivers/gpu/drm/panthor/Makefile b/drivers/gpu/drm/panthor/Makefile
> > index 02db21748c125..75e92c461304b 100644
> > --- a/drivers/gpu/drm/panthor/Makefile
> > +++ b/drivers/gpu/drm/panthor/Makefile
> > @@ -12,4 +12,6 @@ panthor-y := \
> >       panthor_mmu.o \
> >       panthor_sched.o
> >
> > +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.

Re: [RFC PATCH 0/2] drm/panthor: initial mt8196 support

[Chia-I Wu]

On Thu, Sep 4, 2025 at 4:20 AM Nicolas Frattaroli
<nicolas.frattaroli@collabora.com> wrote:
>
> Hi,
>
> On Thursday, 4 September 2025 00:55:02 Central European Summer Time Chia-I Wu wrote:
> > 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.
That's very true :)

>
> 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.
Yeah, gpueb can do dvfs autonomously which is more similar to how
desktop gpus handle dvfs.  We have yet to verify that on our devices.
I also tend to trust devfreq more, but that might be partly because it
is very hard to navigate through the downstream drivers.

Look forward to seeing what you got!

>
> 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
>
> >
> > 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
> >
> >
>
>
>
>

Re: [RFC PATCH 0/2] drm/panthor: initial mt8196 support

[Chen-Yu Tsai]

On Thu, Sep 4, 2025 at 7:20 PM Nicolas Frattaroli
<nicolas.frattaroli@collabora.com> wrote:
>
> Hi,
>
> On Thursday, 4 September 2025 00:55:02 Central European Summer Time Chia-I Wu wrote:
> > 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.

I suggest posting them when you think they are ready, and not wait for
the clk patches to land. The review is going a bit slower than I expected
and Stephen usually just picks up the patches towards the end of the
cycles anyway.

ChenYu

> Kind regards,
> Nicolas Frattaroli
>
> >
> > 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
> >
> >
>
>
>
>

Re: [RFC PATCH 2/2] drm/panthor: add initial mt8196 support

[Florent Tomasin]

On 05/09/2025 00:06, Chia-I Wu wrote:
> On Wed, Sep 3, 2025 at 11:02 PM Boris Brezillon
> <boris.brezillon@collabora.com> wrote:
>>
>> On Wed,  3 Sep 2025 15:55:04 -0700
>> Chia-I Wu <olvaffe@gmail.com> wrote:
>>
>>> diff --git a/drivers/gpu/drm/panthor/Makefile b/drivers/gpu/drm/panthor/Makefile
>>> index 02db21748c125..75e92c461304b 100644
>>> --- a/drivers/gpu/drm/panthor/Makefile
>>> +++ b/drivers/gpu/drm/panthor/Makefile
>>> @@ -12,4 +12,6 @@ panthor-y := \
>>>       panthor_mmu.o \
>>>       panthor_sched.o
>>>
>>> +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.

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

> 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

Re: [RFC PATCH 2/2] drm/panthor: add initial mt8196 support

[Chia-I Wu]

On Fri, Sep 5, 2025 at 2:18 AM Florent Tomasin <florent.tomasin@arm.com> wrote:
>
>
>
> On 05/09/2025 00:06, Chia-I Wu wrote:
> > On Wed, Sep 3, 2025 at 11:02 PM Boris Brezillon
> > <boris.brezillon@collabora.com> wrote:
> >>
> >> On Wed,  3 Sep 2025 15:55:04 -0700
> >> Chia-I Wu <olvaffe@gmail.com> wrote:
> >>
> >>> diff --git a/drivers/gpu/drm/panthor/Makefile b/drivers/gpu/drm/panthor/Makefile
> >>> index 02db21748c125..75e92c461304b 100644
> >>> --- a/drivers/gpu/drm/panthor/Makefile
> >>> +++ b/drivers/gpu/drm/panthor/Makefile
> >>> @@ -12,4 +12,6 @@ panthor-y := \
> >>>       panthor_mmu.o \
> >>>       panthor_sched.o
> >>>
> >>> +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.
>
> 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
It is a soc-specific quirk and was suggested to be dealt with using
compatible string

  https://lore.kernel.org/lkml/ac4838eb-7613-4642-a007-577a9f665984@arm.com/

>
> > 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?
That's what the linked commit does

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

>
> 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?
AFAICT, gpueb reads the shader core mask from efuse and writes it to
an memory address (together with other info) specified by the gpueb
driver.  How the gpueb driver makes the mask available to panthor is
tbd, but it should be a very small change to panthor (unless we want
the gpueb driver to be a part of pantor).

I was told by the vendor that the shader core mask does not change
after boot, but can vary in unspecified ways.


>
> Kind regards,
> Florent