[PATCH v4 0/5] powervr: MT8173 GPU support

[PATCH v4 0/5] powervr: MT8173 GPU support

[Chen-Yu Tsai]

Hi everyone,

This is v4 of my MT8173 PowerVR GPU support series.

This time around Mesa was ready for basic testing, using both vulkanmark
and glmark2-es2-drm (with Zink). Details below.

Changes since v3 (all in the clk driver patch):
- Changed pm_runtime_put() to pm_runtime_put_sync()
- Added missing of_node_put() in remove function

Changes since v2 (all in the clk driver patch):
- Made COMMON_CLK_MT8173_MFGTOP depend on PM
  - Needed since the driver implements PM domains using the generic PM
    domain library, which also depends on PM
  - Fixes build breakage (kernel test robot)
- Fixed "RST_DELAY_CNT" name (Brian)
- Dropped unused mfg_desc (Brian)
- Added check of clk_prepare_enable()'s return value in
  clk_mt8173_mfgtop_power_on() (Brian)
- Saved error value for return in IS_ERR(data->clk_26m) branch
  (Dan Carpenter / kernel test robot w/ smatch)

Changes since v1:
- Adapted to changed DT bindings
- Dropped driver change
- Use same power domain for "a" and "b" GPU power domains


This series enables the PowerVR GPU found in the MT8173 SoC, found in
some Chromebooks.

This version is different from the initial powervr driver submission [1]
in that it splits out the GPU glue layer support out of the powervr
driver and into a separate clock and power domain driver. The glue code
is otherwise the same, and also the same as found in the ChromeOS
kernels, with some extra comments and macro names added where possible.

Patch 1 adds a binding for the glue layer, called mfgtop. The glue layer
contains clock and power controls for the GPU.

Patch 2 adds a driver for the glue layer, implemented as a clock driver
that also provides power domains.

Patch 3 adds an entry for the MT8173 GPU and 6XT series to the PowerVR
binding.

Patch 4 corrects the clock for the GPU (called MFG) power domain.

Patch 5 adds device nodes for the GPU and glue layer to the MT8173 dtsi
file.

The kernel driver successfully probes the hardware and loads the
"rogue_4.40.2.51_v1.fw" firmware provided by Imagination Technologies [2].
The "exp_hw_support" module parameter needs to be set for the driver to
probe successfully.

This was tested with Mesa 26.1.5 from Debian Forky. With this version
vkmark and glmark2-es2 (over Zink) both run fine. Mesa spits out a bunch
of warnings since the GX6250 core is not officially supported.

    # PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 vkmark
    WARNING: powervr is not a conformant Vulkan implementation, testing use only.
    WARNING: powervr is not a conformant Vulkan implementation, testing use only.
    MESA: warning: ../src/imagination/vulkan/pvr_arch_job_context.c:73: FINISHME: Missing reset support for brn51764
    MESA: warning: ../src/imagination/vulkan/pvr_arch_job_context.c:76: FINISHME: Missing reset support for brn58839
    MESA: warning: ../src/imagination/vulkan/pvr_arch_job_context.c:523: FINISHME: Missing support for brn62269
    MESA: warning: ../src/imagination/vulkan/pvr_arch_border.c:244: FINISHME: Devices without tpu_border_colour_enhanced require entries for compressed formats to be stored in the table pre-compressed.
    WARNING: powervr is not a conformant Vulkan implementation, testing use only.
    =======================================================
	vkmark 2025.01
    =======================================================
	Vendor ID:      0x1010
	Device ID:      0x6250
	Device Name:    PowerVR Rogue GX6250
	Driver Version: 109056005
	Device UUID:    d04cd6f3a25fd4900f89c151bccfdfcf
    =======================================================
    [vertex] device-local=true: FPS: 251 FrameTime: 3.984 ms
    [vertex] device-local=false: FPS: 220 FrameTime: 4.545 ms
    [texture] anisotropy=0:^C FPS: 223 FrameTime: 4.484 ms
    =======================================================
				       vkmark Score: 231
    =======================================================

    # PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 glmark2-es2-drm
    WARNING: powervr is not a conformant Vulkan implementation, testing use only.
    MESA: warning: ../src/imagination/vulkan/pvr_arch_job_context.c:73: FINISHME: Missing reset support for brn51764
    MESA: warning: ../src/imagination/vulkan/pvr_arch_job_context.c:76: FINISHME: Missing reset support for brn58839
    MESA: warning: ../src/imagination/vulkan/pvr_arch_job_context.c:523: FINISHME: Missing support for brn62269
    MESA: warning: ../src/imagination/vulkan/pvr_arch_border.c:244: FINISHME: Devices without tpu_border_colour_enhanced require entries for compressed formats to be stored in the table pre-compressed.
    Warning: DRM_CAP_ASYNC_PAGE_FLIP not supported, falling back to 'mailbox' mode for SwapInterval(0).
    =======================================================
	glmark2 2023.01
    =======================================================
	OpenGL Information
	GL_VENDOR:      Mesa
	GL_RENDERER:    zink Vulkan 1.2(PowerVR Rogue GX6250 (IMAGINATION_OPEN_SOURCE_MESA))
	GL_VERSION:     OpenGL ES 2.0 Mesa 26.1.5-1
	Surface Config: buf=32 r=8 g=8 b=8 a=8 depth=24 stencil=0 samples=0
	Surface Size:   1366x768 fullscreen
    =======================================================
    [build] use-vbo=false: FPS: 49 FrameTime: 20.473 ms
    [build] use-vbo=true: FPS: 45 FrameTime: 22.660 ms
    [texture] texture-filter=nearest: FPS: 45 FrameTime: 22.642 ms
    [texture] texture-filter=linear:^C FPS: 50 FrameTime: 20.172 ms
    =======================================================
				      glmark2 Score: 46
    =======================================================


Please have a look.

Thanks
ChenYu

[1] https://lore.kernel.org/dri-devel/20220815165156.118212-2-sarah.walker@imgtec.com/
[2] https://gitlab.freedesktop.org/imagination/linux-firmware/-/tree/powervr

Chen-Yu Tsai (5):
  dt-bindings: clock: mediatek: Add mt8173 mfgtop
  clk: mediatek: Add mt8173-mfgtop driver
  dt-bindings: gpu: powervr-rogue: Add MediaTek MT8173 GPU
  arm64: dts: mediatek: mt8173: Fix MFG_ASYNC power domain clock
  arm64: dts: mediatek: mt8173: Add GPU device nodes

 .../clock/mediatek,mt8173-mfgtop.yaml         |  70 +++++
 .../bindings/gpu/img,powervr-rogue.yaml       |   1 +
 arch/arm64/boot/dts/mediatek/mt8173.dtsi      |  33 ++-
 drivers/clk/mediatek/Kconfig                  |  10 +
 drivers/clk/mediatek/Makefile                 |   1 +
 drivers/clk/mediatek/clk-mt8173-mfgtop.c      | 242 ++++++++++++++++++
 include/dt-bindings/clock/mt8173-clk.h        |   7 +
 7 files changed, 363 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/clock/mediatek,mt8173-mfgtop.yaml
 create mode 100644 drivers/clk/mediatek/clk-mt8173-mfgtop.c

-- 
2.55.0.229.g6434b31f56-goog

[PATCH v4 1/5] dt-bindings: clock: mediatek: Add mt8173 mfgtop

[Chen-Yu Tsai]

The MFG (GPU) block on the MT8173 has a small glue layer, named MFG_TOP
in the datasheet, that contains clock gates, some power sequence signal
delays, and other unknown registers that get toggled when the GPU is
powered on.

The clock gates are exposed as clocks provided by a clock controller,
while the power sequencing bits are exposed as one singular power domain.

Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
 .../clock/mediatek,mt8173-mfgtop.yaml         | 70 +++++++++++++++++++
 include/dt-bindings/clock/mt8173-clk.h        |  7 ++
 2 files changed, 77 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/mediatek,mt8173-mfgtop.yaml

diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt8173-mfgtop.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8173-mfgtop.yaml
new file mode 100644
index 000000000000..03db1ee9e594
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt8173-mfgtop.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+
+$id: http://devicetree.org/schemas/clock/mediatek,mt8173-mfgtop.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT8173 MFG TOP controller
+
+maintainers:
+  - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+
+description:
+  The MFG TOP glue layer controls various signals going to the MFG (GPU)
+  block on the MT8173.
+
+properties:
+  compatible:
+    const: mediatek,mt8173-mfgtop
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    maxItems: 4
+
+  clock-names:
+    items:
+      - const: sys
+      - const: mem
+      - const: core
+      - const: clk26m
+
+  power-domains:
+    maxItems: 1
+
+  '#clock-cells':
+    const: 1
+
+  '#power-domain-cells':
+    const: 0
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - power-domains
+  - '#clock-cells'
+  - '#power-domain-cells'
+
+additionalProperties: false
+
+examples:
+  - |
+        #include <dt-bindings/clock/mt8173-clk.h>
+        #include <dt-bindings/power/mt8173-power.h>
+
+        clock-controller@13fff000 {
+            compatible = "mediatek,mt8173-mfgtop";
+            reg = <0x13fff000 0x1000>;
+            clocks = <&topckgen CLK_TOP_AXI_MFG_IN_SEL>,
+                     <&topckgen CLK_TOP_MEM_MFG_IN_SEL>,
+                     <&topckgen CLK_TOP_MFG_SEL>,
+                     <&clk26m>;
+            clock-names = "sys", "mem", "core", "clk26m";
+            power-domains = <&spm MT8173_POWER_DOMAIN_MFG>;
+            #clock-cells = <1>;
+            #power-domain-cells = <0>;
+        };
diff --git a/include/dt-bindings/clock/mt8173-clk.h b/include/dt-bindings/clock/mt8173-clk.h
index 3d00c98b9654..89e982f771db 100644
--- a/include/dt-bindings/clock/mt8173-clk.h
+++ b/include/dt-bindings/clock/mt8173-clk.h
@@ -243,6 +243,13 @@
 #define CLK_IMG_FD			7
 #define CLK_IMG_NR_CLK			8
 
+/* MFG_SYS */
+
+#define CLK_MFG_AXI			0
+#define CLK_MFG_MEM			1
+#define CLK_MFG_G3D			2
+#define CLK_MFG_26M			3
+
 /* MM_SYS */
 
 #define CLK_MM_SMI_COMMON		1
-- 
2.55.0.229.g6434b31f56-goog

[PATCH v4 2/5] clk: mediatek: Add mt8173-mfgtop driver

[Chen-Yu Tsai]

The MFG (GPU) block on the MT8173 has a small glue layer, named MFG_TOP
in the datasheet, that contains clock gates, some power sequence signal
delays, and other unknown registers that get toggled when the GPU is
powered on.

The clock gates are exposed as clocks provided by a clock controller,
while the power sequencing bits are exposed as one singular power domain.

Tested-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Changes since v3:
- Changed pm_runtime_put() to pm_runtime_put_sync()
- Added missing of_node_put() in remove function

Changes since v2:
- Made COMMON_CLK_MT8173_MFGTOP depend on PM
  - Needed since the driver implements PM domains using the generic PM
    domain library, which also depends on PM
  - Fixes build breakage (kernel test robot)
- Fixed "RST_DELAY_CNT" name (Brian)
- Dropped unused mfg_desc (Brian)
- Added check of clk_prepare_enable()'s return value in
  clk_mt8173_mfgtop_power_on() (Brian)
- Saved error value for return in IS_ERR(data->clk_26m) branch
  (Dan Carpenter / kernel test robot w/ smatch)
---
 drivers/clk/mediatek/Kconfig             |  10 +
 drivers/clk/mediatek/Makefile            |   1 +
 drivers/clk/mediatek/clk-mt8173-mfgtop.c | 242 +++++++++++++++++++++++
 3 files changed, 253 insertions(+)
 create mode 100644 drivers/clk/mediatek/clk-mt8173-mfgtop.c

diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
index 2c09fd729bab..8eea3766a910 100644
--- a/drivers/clk/mediatek/Kconfig
+++ b/drivers/clk/mediatek/Kconfig
@@ -537,6 +537,16 @@ config COMMON_CLK_MT8173_IMGSYS
 	help
 	  This driver supports MediaTek MT8173 imgsys clocks.
 
+config COMMON_CLK_MT8173_MFGTOP
+	tristate "Clock and power driver for MediaTek MT8173 mfgtop"
+	depends on COMMON_CLK_MT8173
+	depends on PM
+	default COMMON_CLK_MT8173
+	select PM_GENERIC_DOMAINS
+	select PM_GENERIC_DOMAINS_OF
+	help
+	  This driver supports MediaTek MT8173 mfgtop clocks and power domain.
+
 config COMMON_CLK_MT8173_MMSYS
        tristate "Clock driver for MediaTek MT8173 mmsys"
        depends on COMMON_CLK_MT8173
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index d8736a060dbd..892a54eeb281 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -82,6 +82,7 @@ obj-$(CONFIG_COMMON_CLK_MT8167_VDECSYS) += clk-mt8167-vdec.o
 obj-$(CONFIG_COMMON_CLK_MT8173) += clk-mt8173-apmixedsys.o clk-mt8173-infracfg.o \
 				   clk-mt8173-pericfg.o clk-mt8173-topckgen.o
 obj-$(CONFIG_COMMON_CLK_MT8173_IMGSYS) += clk-mt8173-img.o
+obj-$(CONFIG_COMMON_CLK_MT8173_MFGTOP) += clk-mt8173-mfgtop.o
 obj-$(CONFIG_COMMON_CLK_MT8173_MMSYS) += clk-mt8173-mm.o
 obj-$(CONFIG_COMMON_CLK_MT8173_VDECSYS) += clk-mt8173-vdecsys.o
 obj-$(CONFIG_COMMON_CLK_MT8173_VENCSYS) += clk-mt8173-vencsys.o
diff --git a/drivers/clk/mediatek/clk-mt8173-mfgtop.c b/drivers/clk/mediatek/clk-mt8173-mfgtop.c
new file mode 100644
index 000000000000..5669ca9954dc
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt8173-mfgtop.c
@@ -0,0 +1,242 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2024 Google LLC
+ * Author: Chen-Yu Tsai <wenst@chromium.org>
+ *
+ * Based on driver in downstream ChromeOS v5.15 kernel.
+ *
+ * Copyright (c) 2014 MediaTek Inc.
+ * Author: Chiawen Lee <chiawen.lee@mediatek.com>
+ */
+
+#include <dt-bindings/clock/mt8173-clk.h>
+
+#include <linux/bitfield.h>
+#include <linux/clk.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+#include <linux/pm_runtime.h>
+#include <linux/regmap.h>
+
+#include "clk-gate.h"
+#include "clk-mtk.h"
+
+static const struct mtk_gate_regs mfg_cg_regs = {
+	.sta_ofs = 0x0000,
+	.clr_ofs = 0x0008,
+	.set_ofs = 0x0004,
+};
+
+#define GATE_MFG(_id, _name, _parent, _shift, _flags)	\
+	GATE_MTK_FLAGS(_id, _name, _parent, &mfg_cg_regs, _shift, &mtk_clk_gate_ops_setclr, _flags)
+
+/* TODO: The block actually has dividers for the core and mem clocks. */
+static const struct mtk_gate mfg_clks[] = {
+	GATE_MFG(CLK_MFG_AXI, "mfg_axi", "axi_mfg_in_sel", 0, CLK_SET_RATE_PARENT),
+	GATE_MFG(CLK_MFG_MEM, "mfg_mem", "mem_mfg_in_sel", 1, CLK_SET_RATE_PARENT),
+	GATE_MFG(CLK_MFG_G3D, "mfg_g3d", "mfg_sel", 2, CLK_SET_RATE_PARENT),
+	GATE_MFG(CLK_MFG_26M, "mfg_26m", "clk26m", 3, 0),
+};
+
+struct mt8173_mfgtop_data {
+	struct clk_hw_onecell_data *clk_data;
+	struct regmap *regmap;
+	struct generic_pm_domain genpd;
+	struct of_phandle_args parent_pd, child_pd;
+	struct clk *clk_26m;
+};
+
+/* Delay count in clock cycles */
+#define MFG_ACTIVE_POWER_CON0	0x24
+ #define RST_B_DELAY_CNT	GENMASK(7, 0)	/* pwr_rst_b de-assert delay during power-up */
+ #define CLK_EN_DELAY_CNT	GENMASK(15, 8)	/* CLK_DIS deassert delay during power-up */
+ #define CLK_DIS_DELAY_CNT	GENMASK(23, 16)	/* CLK_DIS assert delay during power-down */
+ #define FORCE_ABORT		BIT(30)		/* write 1 to force abort a power event */
+ #define ACTIVE_PWRCTL_EN	BIT(31)		/* enable ACTIVE_POWER */
+
+#define MFG_ACTIVE_POWER_CON1	0x28
+ #define PWR_ON_S_DELAY_CNT	GENMASK(7, 0)	/* pwr_on_s assert delay during power-up */
+ #define ISO_DELAY_CNT		GENMASK(15, 8)	/* ISO assert delay during power-down */
+ #define ISOOFF_DELAY_CNT	GENMASK(23, 16)	/* ISO de-assert delay during power-up */
+ #define RST_DELAY_CNT		GENMASK(31, 24) /* pwr_rsb_b assert delay during power-down */
+
+static int clk_mt8173_mfgtop_power_on(struct generic_pm_domain *domain)
+{
+	struct mt8173_mfgtop_data *data = container_of(domain, struct mt8173_mfgtop_data, genpd);
+	int ret;
+
+	/* drives internal power management */
+	ret = clk_prepare_enable(data->clk_26m);
+	if (ret)
+		return ret;
+
+	/* Power on/off delays for various signals */
+	regmap_write(data->regmap, MFG_ACTIVE_POWER_CON0,
+		     FIELD_PREP(RST_B_DELAY_CNT, 77) |
+		     FIELD_PREP(CLK_EN_DELAY_CNT, 61) |
+		     FIELD_PREP(CLK_DIS_DELAY_CNT, 60) |
+		     FIELD_PREP(ACTIVE_PWRCTL_EN, 0));
+	regmap_write(data->regmap, MFG_ACTIVE_POWER_CON1,
+		     FIELD_PREP(PWR_ON_S_DELAY_CNT, 11) |
+		     FIELD_PREP(ISO_DELAY_CNT, 68) |
+		     FIELD_PREP(ISOOFF_DELAY_CNT, 69) |
+		     FIELD_PREP(RST_DELAY_CNT, 77));
+
+	/* Magic numbers related to core switch sequence and delays */
+	regmap_write(data->regmap, 0xe0, 0x7a710184);
+	regmap_write(data->regmap, 0xe4, 0x835f6856);
+	regmap_write(data->regmap, 0xe8, 0x002b0234);
+	regmap_write(data->regmap, 0xec, 0x80000000);
+	regmap_write(data->regmap, 0xa0, 0x08000000);
+
+	return 0;
+}
+
+static int clk_mt8173_mfgtop_power_off(struct generic_pm_domain *domain)
+{
+	struct mt8173_mfgtop_data *data = container_of(domain, struct mt8173_mfgtop_data, genpd);
+
+	/* Magic numbers related to core switch sequence and delays */
+	regmap_write(data->regmap, 0xec, 0);
+
+	/* drives internal power management */
+	clk_disable_unprepare(data->clk_26m);
+
+	return 0;
+}
+
+static int clk_mt8173_mfgtop_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *node = dev->of_node;
+	struct mt8173_mfgtop_data *data;
+	int ret;
+
+	data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	platform_set_drvdata(pdev, data);
+
+	data->clk_data = mtk_devm_alloc_clk_data(dev, ARRAY_SIZE(mfg_clks));
+	if (!data->clk_data)
+		return -ENOMEM;
+
+	/* MTK clock gates also uses regmap */
+	data->regmap = device_node_to_regmap(node);
+	if (IS_ERR(data->regmap))
+		return dev_err_probe(dev, PTR_ERR(data->regmap), "Failed to get regmap\n");
+
+	data->child_pd.np = node;
+	data->child_pd.args_count = 0;
+	ret = of_parse_phandle_with_args(node, "power-domains", "#power-domain-cells", 0,
+					 &data->parent_pd);
+	if (ret)
+		return dev_err_probe(dev, ret, "Failed to parse power domain\n");
+
+	devm_pm_runtime_enable(dev);
+	/*
+	 * Do a pm_runtime_resume_and_get() to workaround a possible
+	 * deadlock between clk_register() and the genpd framework.
+	 */
+	ret = pm_runtime_resume_and_get(dev);
+	if (ret) {
+		dev_err_probe(dev, ret, "Failed to runtime resume device\n");
+		goto put_of_node;
+	}
+
+	ret = mtk_clk_register_gates(dev, node, mfg_clks, ARRAY_SIZE(mfg_clks),
+				     data->clk_data);
+	if (ret) {
+		dev_err_probe(dev, ret, "Failed to register clock gates\n");
+		goto put_pm_runtime;
+	}
+
+	data->clk_26m = clk_hw_get_clk(data->clk_data->hws[CLK_MFG_26M], "26m");
+	if (IS_ERR(data->clk_26m)) {
+		ret = dev_err_probe(dev, PTR_ERR(data->clk_26m), "Failed to get 26 MHz clock\n");
+		goto unregister_clks;
+	}
+
+	ret = of_clk_add_hw_provider(node, of_clk_hw_onecell_get, data->clk_data);
+	if (ret) {
+		dev_err_probe(dev, ret, "Failed to add clk OF provider\n");
+		goto put_26m_clk;
+	}
+
+	data->genpd.name = "mfg-top";
+	data->genpd.power_on = clk_mt8173_mfgtop_power_on;
+	data->genpd.power_off = clk_mt8173_mfgtop_power_off;
+	ret = pm_genpd_init(&data->genpd, NULL, true);
+	if (ret) {
+		dev_err_probe(dev, ret, "Failed to add power domain\n");
+		goto del_clk_provider;
+	}
+
+	ret = of_genpd_add_provider_simple(node, &data->genpd);
+	if (ret) {
+		dev_err_probe(dev, ret, "Failed to add power domain OF provider\n");
+		goto remove_pd;
+	}
+
+	ret = of_genpd_add_subdomain(&data->parent_pd, &data->child_pd);
+	if (ret) {
+		dev_err_probe(dev, ret, "Failed to link PM domains\n");
+		goto del_pd_provider;
+	}
+
+	pm_runtime_put(dev);
+	return 0;
+
+del_pd_provider:
+	of_genpd_del_provider(node);
+remove_pd:
+	pm_genpd_remove(&data->genpd);
+del_clk_provider:
+	of_clk_del_provider(node);
+put_26m_clk:
+	clk_put(data->clk_26m);
+unregister_clks:
+	mtk_clk_unregister_gates(mfg_clks, ARRAY_SIZE(mfg_clks), data->clk_data);
+put_pm_runtime:
+	pm_runtime_put_sync(dev);
+put_of_node:
+	of_node_put(data->parent_pd.np);
+	return ret;
+}
+
+static void clk_mt8173_mfgtop_remove(struct platform_device *pdev)
+{
+	struct mt8173_mfgtop_data *data = platform_get_drvdata(pdev);
+	struct device_node *node = pdev->dev.of_node;
+
+	of_genpd_remove_subdomain(&data->parent_pd, &data->child_pd);
+	of_genpd_del_provider(node);
+	pm_genpd_remove(&data->genpd);
+	of_clk_del_provider(node);
+	clk_put(data->clk_26m);
+	mtk_clk_unregister_gates(mfg_clks, ARRAY_SIZE(mfg_clks), data->clk_data);
+	of_node_put(data->parent_pd.np);
+}
+
+static const struct of_device_id of_match_clk_mt8173_mfgtop[] = {
+	{ .compatible = "mediatek,mt8173-mfgtop" },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, of_match_clk_mt8173_mfgtop);
+
+static struct platform_driver clk_mt8173_mfgtop_drv = {
+	.probe = clk_mt8173_mfgtop_probe,
+	.remove = clk_mt8173_mfgtop_remove,
+	.driver = {
+		.name = "clk-mt8173-mfgtop",
+		.of_match_table = of_match_clk_mt8173_mfgtop,
+	},
+};
+module_platform_driver(clk_mt8173_mfgtop_drv);
+
+MODULE_DESCRIPTION("MediaTek MT8173 mfgtop clock driver");
+MODULE_LICENSE("GPL");
-- 
2.55.0.229.g6434b31f56-goog

[PATCH v4 3/5] dt-bindings: gpu: powervr-rogue: Add MediaTek MT8173 GPU

[Chen-Yu Tsai]

The MediaTek MT8173 comes with a PowerVR Rogue GX6250, which is one
of the Series6XT GPUs, another sub-family of the Rogue family.

This was part of the very first few versions of the PowerVR submission,
but was later dropped.

[1] https://lore.kernel.org/dri-devel/6eeccb26e09aad67fb30ffcd523c793a43c79c2a.camel@imgtec.com/

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
 Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
index a6bccb600a57..e9218e0f363d 100644
--- a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
+++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
@@ -16,6 +16,7 @@ properties:
     oneOf:
       - items:
           - enum:
+              - mediatek,mt8173-gpu
               - renesas,r8a7796-gpu
               - renesas,r8a77961-gpu
           - const: img,img-gx6250
-- 
2.55.0.229.g6434b31f56-goog

[PATCH v4 4/5] arm64: dts: mediatek: mt8173: Fix MFG_ASYNC power domain clock

[Chen-Yu Tsai]

The MFG_ASYNC domain, which is likely associated to the whole MFG block,
currently specifies clk26m as its domain clock. This is bogus, since the
clock is an external crystal with no controls. Also, the MFG block has
a independent CLK_TOP_AXI_MFG_IN_SEL clock, which according to the block
diagram, gates access to the hardware registers. Having this one as the
domain clock makes much more sense. This also fixes access to the MFGTOP
registers.

Change the MFG_ASYNC domain clock to CLK_TOP_AXI_MFG_IN_SEL.

Fixes: 8b6562644df9 ("arm64: dts: mediatek: Add mt8173 power domain controller")
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Tested-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 78c2ccd5be13..556e806b7787 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -505,7 +505,7 @@ power-domain@MT8173_POWER_DOMAIN_USB {
 				};
 				mfg_async: power-domain@MT8173_POWER_DOMAIN_MFG_ASYNC {
 					reg = <MT8173_POWER_DOMAIN_MFG_ASYNC>;
-					clocks = <&clk26m>;
+					clocks = <&topckgen CLK_TOP_AXI_MFG_IN_SEL>;
 					clock-names = "mfg";
 					#address-cells = <1>;
 					#size-cells = <0>;
-- 
2.55.0.229.g6434b31f56-goog

[PATCH v4 5/5] arm64: dts: mediatek: mt8173: Add GPU device nodes

[Chen-Yu Tsai]

The MediaTek MT8173 comes with a PowerVR Rogue GX6250, which is part
of the Series6XT, another variation of the Rogue family of GPUs.

On top of the GPU is a glue layer that handles some clock and power
signals.

Add device nodes for both. While there is supposed to be two different
power domains to the GPU, MediaTek does not have any information on how
this is integrated internally. Assign the same GPU power domain to both.

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Tested-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 31 ++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 556e806b7787..169ba4fd183e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -1002,6 +1002,37 @@ u2port1: usb-phy@11291000 {
 			};
 		};
 
+		gpu: gpu@13000000 {
+			compatible = "mediatek,mt8173-gpu", "img,img-gx6250",
+				     "img,img-rogue";
+			reg = <0 0x13000000 0 0x10000>;
+			interrupts = <GIC_SPI 217 IRQ_TYPE_LEVEL_LOW>;
+			clocks = <&mfgtop CLK_MFG_G3D>,
+				 <&mfgtop CLK_MFG_MEM>,
+				 <&mfgtop CLK_MFG_AXI>;
+			clock-names = "core", "mem", "sys";
+			/*
+			 * Binding and GPU core HW have two power domain
+			 * inputs, but MediaTek does not have information
+			 * on how this is done internally.
+			 */
+			power-domains = <&mfgtop>, <&mfgtop>;
+			power-domain-names = "a", "b";
+		};
+
+		mfgtop: clock-controller@13fff000 {
+			compatible = "mediatek,mt8173-mfgtop";
+			reg = <0 0x13fff000 0 0x1000>;
+			clocks = <&topckgen CLK_TOP_AXI_MFG_IN_SEL>,
+				 <&topckgen CLK_TOP_MEM_MFG_IN_SEL>,
+				 <&topckgen CLK_TOP_MFG_SEL>,
+				 <&clk26m>;
+			clock-names = "sys", "mem", "core", "clk26m";
+			power-domains = <&spm MT8173_POWER_DOMAIN_MFG>;
+			#clock-cells = <1>;
+			#power-domain-cells = <0>;
+		};
+
 		mmsys: syscon@14000000 {
 			compatible = "mediatek,mt8173-mmsys", "syscon";
 			reg = <0 0x14000000 0 0x1000>;
-- 
2.55.0.229.g6434b31f56-goog

Re: [PATCH v4 0/5] powervr: MT8173 GPU support

[Brian Masney]

Hi Chen-Yu,

On Tue, Jul 28, 2026 at 05:17:58PM +0800, Chen-Yu Tsai wrote:
> Hi everyone,
> 
> This is v4 of my MT8173 PowerVR GPU support series.
> 
> This time around Mesa was ready for basic testing, using both vulkanmark
> and glmark2-es2-drm (with Zink). Details below.
> 
> Changes since v3 (all in the clk driver patch):
> - Changed pm_runtime_put() to pm_runtime_put_sync()
> - Added missing of_node_put() in remove function
> 
> Changes since v2 (all in the clk driver patch):
> - Made COMMON_CLK_MT8173_MFGTOP depend on PM
>   - Needed since the driver implements PM domains using the generic PM
>     domain library, which also depends on PM
>   - Fixes build breakage (kernel test robot)
> - Fixed "RST_DELAY_CNT" name (Brian)
> - Dropped unused mfg_desc (Brian)
> - Added check of clk_prepare_enable()'s return value in
>   clk_mt8173_mfgtop_power_on() (Brian)
> - Saved error value for return in IS_ERR(data->clk_26m) branch
>   (Dan Carpenter / kernel test robot w/ smatch)
> 
> Changes since v1:
> - Adapted to changed DT bindings
> - Dropped driver change
> - Use same power domain for "a" and "b" GPU power domains
> 
> 
> This series enables the PowerVR GPU found in the MT8173 SoC, found in
> some Chromebooks.

I'm making a pull for Stephen for the clk changes. Should patches 1,2,4
go through the clk tree? Patches 3,5 go through the DRM tree?

Brian

Re: [PATCH v4 0/5] powervr: MT8173 GPU support

[Chen-Yu Tsai]

On Tue, Jul 28, 2026 at 9:10 PM Brian Masney <bmasney@redhat.com> wrote:
>
> Hi Chen-Yu,
>
> On Tue, Jul 28, 2026 at 05:17:58PM +0800, Chen-Yu Tsai wrote:
> > Hi everyone,
> >
> > This is v4 of my MT8173 PowerVR GPU support series.
> >
> > This time around Mesa was ready for basic testing, using both vulkanmark
> > and glmark2-es2-drm (with Zink). Details below.
> >
> > Changes since v3 (all in the clk driver patch):
> > - Changed pm_runtime_put() to pm_runtime_put_sync()
> > - Added missing of_node_put() in remove function
> >
> > Changes since v2 (all in the clk driver patch):
> > - Made COMMON_CLK_MT8173_MFGTOP depend on PM
> >   - Needed since the driver implements PM domains using the generic PM
> >     domain library, which also depends on PM
> >   - Fixes build breakage (kernel test robot)
> > - Fixed "RST_DELAY_CNT" name (Brian)
> > - Dropped unused mfg_desc (Brian)
> > - Added check of clk_prepare_enable()'s return value in
> >   clk_mt8173_mfgtop_power_on() (Brian)
> > - Saved error value for return in IS_ERR(data->clk_26m) branch
> >   (Dan Carpenter / kernel test robot w/ smatch)
> >
> > Changes since v1:
> > - Adapted to changed DT bindings
> > - Dropped driver change
> > - Use same power domain for "a" and "b" GPU power domains
> >
> >
> > This series enables the PowerVR GPU found in the MT8173 SoC, found in
> > some Chromebooks.
>
> I'm making a pull for Stephen for the clk changes. Should patches 1,2,4
> go through the clk tree? Patches 3,5 go through the DRM tree?

Only patches 1 and 2 should go through the clock tree.

Patch 3, 4, 5 can all go through the soc tree if Angelo wants to pick up
DT binding patches. Otherwise I can push patch 3 through drm-misc.


Thanks
ChenYu

Re: [PATCH v4 0/5] powervr: MT8173 GPU support

[AngeloGioacchino Del Regno]

On 7/28/26 15:13, Chen-Yu Tsai wrote:
> On Tue, Jul 28, 2026 at 9:10 PM Brian Masney <bmasney@redhat.com> wrote:
>>
>> Hi Chen-Yu,
>>
>> On Tue, Jul 28, 2026 at 05:17:58PM +0800, Chen-Yu Tsai wrote:
>>> Hi everyone,
>>>
>>> This is v4 of my MT8173 PowerVR GPU support series.
>>>
>>> This time around Mesa was ready for basic testing, using both vulkanmark
>>> and glmark2-es2-drm (with Zink). Details below.
>>>
>>> Changes since v3 (all in the clk driver patch):
>>> - Changed pm_runtime_put() to pm_runtime_put_sync()
>>> - Added missing of_node_put() in remove function
>>>
>>> Changes since v2 (all in the clk driver patch):
>>> - Made COMMON_CLK_MT8173_MFGTOP depend on PM
>>>    - Needed since the driver implements PM domains using the generic PM
>>>      domain library, which also depends on PM
>>>    - Fixes build breakage (kernel test robot)
>>> - Fixed "RST_DELAY_CNT" name (Brian)
>>> - Dropped unused mfg_desc (Brian)
>>> - Added check of clk_prepare_enable()'s return value in
>>>    clk_mt8173_mfgtop_power_on() (Brian)
>>> - Saved error value for return in IS_ERR(data->clk_26m) branch
>>>    (Dan Carpenter / kernel test robot w/ smatch)
>>>
>>> Changes since v1:
>>> - Adapted to changed DT bindings
>>> - Dropped driver change
>>> - Use same power domain for "a" and "b" GPU power domains
>>>
>>>
>>> This series enables the PowerVR GPU found in the MT8173 SoC, found in
>>> some Chromebooks.
>>
>> I'm making a pull for Stephen for the clk changes. Should patches 1,2,4
>> go through the clk tree? Patches 3,5 go through the DRM tree?
> 
> Only patches 1 and 2 should go through the clock tree.
> 
> Patch 3, 4, 5 can all go through the soc tree if Angelo wants to pick up
> DT binding patches. Otherwise I can push patch 3 through drm-misc.
> 

Not sure if I can really take the DRM bindings patch through soc.

I will take the devicetree ones exactly right now, even though it's going to
give warnings.

I trust that you'll make the binding get into linux-next before it's too late.

Cheers,
Angelo

Re: (subset) [PATCH v4 0/5] powervr: MT8173 GPU support

[AngeloGioacchino Del Regno]

On Tue, 28 Jul 2026 17:17:58 +0800, Chen-Yu Tsai wrote:
> This is v4 of my MT8173 PowerVR GPU support series.
> 
> This time around Mesa was ready for basic testing, using both vulkanmark
> and glmark2-es2-drm (with Zink). Details below.
> 
> Changes since v3 (all in the clk driver patch):
> - Changed pm_runtime_put() to pm_runtime_put_sync()
> - Added missing of_node_put() in remove function
> 
> [...]

Applied to v7.2-next/dts64, thanks!

[4/5] arm64: dts: mediatek: mt8173: Fix MFG_ASYNC power domain clock
      commit: 3549c85d4c0e942d3ac9972a6b35ce0078bd3550
[5/5] arm64: dts: mediatek: mt8173: Add GPU device nodes
      commit: 75bfd9e7cdae0ae04dbaaf8dfc487adb67b7680e

Cheers,
Angelo

Re: [PATCH v4 3/5] dt-bindings: gpu: powervr-rogue: Add MediaTek MT8173 GPU

[Rob Herring (Arm)]

On Tue, 28 Jul 2026 17:18:01 +0800, Chen-Yu Tsai wrote:
> The MediaTek MT8173 comes with a PowerVR Rogue GX6250, which is one
> of the Series6XT GPUs, another sub-family of the Rogue family.
> 
> This was part of the very first few versions of the PowerVR submission,
> but was later dropped.
> 
> [1] https://lore.kernel.org/dri-devel/6eeccb26e09aad67fb30ffcd523c793a43c79c2a.camel@imgtec.com/
> 
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
> ---
>  Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Applied, thanks!

Re: [PATCH v4 0/5] powervr: MT8173 GPU support

[Chen-Yu Tsai]

On Tue, Jul 28, 2026 at 10:33 PM AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com> wrote:
>
> On 7/28/26 15:13, Chen-Yu Tsai wrote:
> > On Tue, Jul 28, 2026 at 9:10 PM Brian Masney <bmasney@redhat.com> wrote:
> >>
> >> Hi Chen-Yu,
> >>
> >> On Tue, Jul 28, 2026 at 05:17:58PM +0800, Chen-Yu Tsai wrote:
> >>> Hi everyone,
> >>>
> >>> This is v4 of my MT8173 PowerVR GPU support series.
> >>>
> >>> This time around Mesa was ready for basic testing, using both vulkanmark
> >>> and glmark2-es2-drm (with Zink). Details below.
> >>>
> >>> Changes since v3 (all in the clk driver patch):
> >>> - Changed pm_runtime_put() to pm_runtime_put_sync()
> >>> - Added missing of_node_put() in remove function
> >>>
> >>> Changes since v2 (all in the clk driver patch):
> >>> - Made COMMON_CLK_MT8173_MFGTOP depend on PM
> >>>    - Needed since the driver implements PM domains using the generic PM
> >>>      domain library, which also depends on PM
> >>>    - Fixes build breakage (kernel test robot)
> >>> - Fixed "RST_DELAY_CNT" name (Brian)
> >>> - Dropped unused mfg_desc (Brian)
> >>> - Added check of clk_prepare_enable()'s return value in
> >>>    clk_mt8173_mfgtop_power_on() (Brian)
> >>> - Saved error value for return in IS_ERR(data->clk_26m) branch
> >>>    (Dan Carpenter / kernel test robot w/ smatch)
> >>>
> >>> Changes since v1:
> >>> - Adapted to changed DT bindings
> >>> - Dropped driver change
> >>> - Use same power domain for "a" and "b" GPU power domains
> >>>
> >>>
> >>> This series enables the PowerVR GPU found in the MT8173 SoC, found in
> >>> some Chromebooks.
> >>
> >> I'm making a pull for Stephen for the clk changes. Should patches 1,2,4
> >> go through the clk tree? Patches 3,5 go through the DRM tree?
> >
> > Only patches 1 and 2 should go through the clock tree.
> >
> > Patch 3, 4, 5 can all go through the soc tree if Angelo wants to pick up
> > DT binding patches. Otherwise I can push patch 3 through drm-misc.
> >
>
> Not sure if I can really take the DRM bindings patch through soc.
>
> I will take the devicetree ones exactly right now, even though it's going to
> give warnings.
>
> I trust that you'll make the binding get into linux-next before it's too late.

Rob beat me to it. :D

Re: [PATCH v4 0/5] powervr: MT8173 GPU support

[AngeloGioacchino Del Regno]

On 7/28/26 16:44, Chen-Yu Tsai wrote:
> On Tue, Jul 28, 2026 at 10:33 PM AngeloGioacchino Del Regno
> <angelogioacchino.delregno@collabora.com> wrote:
>>
>> On 7/28/26 15:13, Chen-Yu Tsai wrote:
>>> On Tue, Jul 28, 2026 at 9:10 PM Brian Masney <bmasney@redhat.com> wrote:
>>>>
>>>> Hi Chen-Yu,
>>>>
>>>> On Tue, Jul 28, 2026 at 05:17:58PM +0800, Chen-Yu Tsai wrote:
>>>>> Hi everyone,
>>>>>
>>>>> This is v4 of my MT8173 PowerVR GPU support series.
>>>>>
>>>>> This time around Mesa was ready for basic testing, using both vulkanmark
>>>>> and glmark2-es2-drm (with Zink). Details below.
>>>>>
>>>>> Changes since v3 (all in the clk driver patch):
>>>>> - Changed pm_runtime_put() to pm_runtime_put_sync()
>>>>> - Added missing of_node_put() in remove function
>>>>>
>>>>> Changes since v2 (all in the clk driver patch):
>>>>> - Made COMMON_CLK_MT8173_MFGTOP depend on PM
>>>>>     - Needed since the driver implements PM domains using the generic PM
>>>>>       domain library, which also depends on PM
>>>>>     - Fixes build breakage (kernel test robot)
>>>>> - Fixed "RST_DELAY_CNT" name (Brian)
>>>>> - Dropped unused mfg_desc (Brian)
>>>>> - Added check of clk_prepare_enable()'s return value in
>>>>>     clk_mt8173_mfgtop_power_on() (Brian)
>>>>> - Saved error value for return in IS_ERR(data->clk_26m) branch
>>>>>     (Dan Carpenter / kernel test robot w/ smatch)
>>>>>
>>>>> Changes since v1:
>>>>> - Adapted to changed DT bindings
>>>>> - Dropped driver change
>>>>> - Use same power domain for "a" and "b" GPU power domains
>>>>>
>>>>>
>>>>> This series enables the PowerVR GPU found in the MT8173 SoC, found in
>>>>> some Chromebooks.
>>>>
>>>> I'm making a pull for Stephen for the clk changes. Should patches 1,2,4
>>>> go through the clk tree? Patches 3,5 go through the DRM tree?
>>>
>>> Only patches 1 and 2 should go through the clock tree.
>>>
>>> Patch 3, 4, 5 can all go through the soc tree if Angelo wants to pick up
>>> DT binding patches. Otherwise I can push patch 3 through drm-misc.
>>>
>>
>> Not sure if I can really take the DRM bindings patch through soc.
>>
>> I will take the devicetree ones exactly right now, even though it's going to
>> give warnings.
>>
>> I trust that you'll make the binding get into linux-next before it's too late.
> 
> Rob beat me to it. :D

Love it!

Thanks Rob :-D

Cheers,
Angelo

Re: [PATCH v4 0/5] powervr: MT8173 GPU support

[YoungJoon Lee]

Hi Chen-Yu,

Thank you for posting the v4 series.

I tested the complete v4 series on my MT8173 Chromebook, but I am
seeing a GPU device loss as soon as Mesa initializes the Vulkan device.

My current setup is:

  Board: Google Elm / Acer Chromebook R13 (CB5-312T)
  Kernel:
    linux-next next-20260727
    commit: 33d6e5134c70446eddafbb3fd5ad088e848a7ad6
    (next-20260727-5-g33d6e5134c70)

  Kernel release: 7.2.0-rc5-next-20260727-stb-cbm-next-pvr-v4+

  Mesa: 26.1.5
  vulkan-powervr: 26.1.5
  Firmware:
    rogue_4.40.2.51_v1.fw
    SHA256:
    f44b7056992fb4057c987dcd7073468bec628aa56cb9815b1162f1cb7c1d73f2

All five patches applied cleanly. The PowerVR driver probes, loads the
firmware, and creates the DRM render node successfully.

However, when I run the following from an SSH session without GDM or
another graphical session running:

  PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 vulkaninfo --summary

Mesa prints the expected GX6250 warnings:

  Missing reset support for brn51764
  Missing reset support for brn58839
  Missing support for brn62269

The command then hangs, and the kernel reports:

  powervr 13000000.gpu: [drm] *ERROR* GPU device lost

There are no additional timeout, MMU fault, firmware, clock, or runtime
PM messages immediately before the device-lost message.

I originally also observed the same failure when GDM started GNOME
Shell, but reproducing it with vulkaninfo from a non-graphical SSH
session indicates that this is not specific to Mutter or GNOME.

Since your cover letter reports that vkmark and glmark2-es2-drm work
with Mesa 26.1.5, I suspect that there may be a difference in the
kernel configuration or another part of the test environment.

Could you please share the following details from your working setup?

  1. The exact Chromebook board/model used for testing
  2. The exact kernel base commit
  3. The kernel configuration, or at least the relevant DRM, PM,
     generic power-domain, IOMMU, and MediaTek clock options
  4. Whether CONFIG_DRM_POWERVR was built-in or built as a module
  5. The firmware SHA256
  6. The kernel command line and bootloader used
  7. Whether `vulkaninfo --summary` also completes successfully

My current relevant configuration includes:

CONFIG_PM_SLEEP=y
CONFIG_PM=y
CONFIG_PM_GENERIC_DOMAINS=y
CONFIG_MODULES=y
CONFIG_DMA_SHARED_BUFFER=y
CONFIG_DRM_POWERVR=m
CONFIG_DRM_MEDIATEK=y
CONFIG_SYNC_FILE=y
CONFIG_COMMON_CLK_MT8173_MFGTOP=y
CONFIG_IOMMU_SUPPORT=y
CONFIG_ARM_SMMU=y
CONFIG_MTK_IOMMU=y

I would be happy to test additional patches or provide any further
logs, kernel configuration, or debugging information if that would
help.

Thanks,
YoungJoon Lee

2026年7月29日(水) 0:28 AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>:
>
> On 7/28/26 16:44, Chen-Yu Tsai wrote:
> > On Tue, Jul 28, 2026 at 10:33 PM AngeloGioacchino Del Regno
> > <angelogioacchino.delregno@collabora.com> wrote:
> >>
> >> On 7/28/26 15:13, Chen-Yu Tsai wrote:
> >>> On Tue, Jul 28, 2026 at 9:10 PM Brian Masney <bmasney@redhat.com> wrote:
> >>>>
> >>>> Hi Chen-Yu,
> >>>>
> >>>> On Tue, Jul 28, 2026 at 05:17:58PM +0800, Chen-Yu Tsai wrote:
> >>>>> Hi everyone,
> >>>>>
> >>>>> This is v4 of my MT8173 PowerVR GPU support series.
> >>>>>
> >>>>> This time around Mesa was ready for basic testing, using both vulkanmark
> >>>>> and glmark2-es2-drm (with Zink). Details below.
> >>>>>
> >>>>> Changes since v3 (all in the clk driver patch):
> >>>>> - Changed pm_runtime_put() to pm_runtime_put_sync()
> >>>>> - Added missing of_node_put() in remove function
> >>>>>
> >>>>> Changes since v2 (all in the clk driver patch):
> >>>>> - Made COMMON_CLK_MT8173_MFGTOP depend on PM
> >>>>>     - Needed since the driver implements PM domains using the generic PM
> >>>>>       domain library, which also depends on PM
> >>>>>     - Fixes build breakage (kernel test robot)
> >>>>> - Fixed "RST_DELAY_CNT" name (Brian)
> >>>>> - Dropped unused mfg_desc (Brian)
> >>>>> - Added check of clk_prepare_enable()'s return value in
> >>>>>     clk_mt8173_mfgtop_power_on() (Brian)
> >>>>> - Saved error value for return in IS_ERR(data->clk_26m) branch
> >>>>>     (Dan Carpenter / kernel test robot w/ smatch)
> >>>>>
> >>>>> Changes since v1:
> >>>>> - Adapted to changed DT bindings
> >>>>> - Dropped driver change
> >>>>> - Use same power domain for "a" and "b" GPU power domains
> >>>>>
> >>>>>
> >>>>> This series enables the PowerVR GPU found in the MT8173 SoC, found in
> >>>>> some Chromebooks.
> >>>>
> >>>> I'm making a pull for Stephen for the clk changes. Should patches 1,2,4
> >>>> go through the clk tree? Patches 3,5 go through the DRM tree?
> >>>
> >>> Only patches 1 and 2 should go through the clock tree.
> >>>
> >>> Patch 3, 4, 5 can all go through the soc tree if Angelo wants to pick up
> >>> DT binding patches. Otherwise I can push patch 3 through drm-misc.
> >>>
> >>
> >> Not sure if I can really take the DRM bindings patch through soc.
> >>
> >> I will take the devicetree ones exactly right now, even though it's going to
> >> give warnings.
> >>
> >> I trust that you'll make the binding get into linux-next before it's too late.
> >
> > Rob beat me to it. :D
>
> Love it!
>
> Thanks Rob :-D
>
> Cheers,
> Angelo

Re: [PATCH v4 0/5] powervr: MT8173 GPU support

[Chen-Yu Tsai]

On Wed, Jul 29, 2026 at 8:08 AM YoungJoon Lee <getfeus@gmail.com> wrote:
>
> Hi Chen-Yu,
>
> Thank you for posting the v4 series.
>
> I tested the complete v4 series on my MT8173 Chromebook, but I am
> seeing a GPU device loss as soon as Mesa initializes the Vulkan device.
>
> My current setup is:
>
>   Board: Google Elm / Acer Chromebook R13 (CB5-312T)
>   Kernel:
>     linux-next next-20260727
>     commit: 33d6e5134c70446eddafbb3fd5ad088e848a7ad6
>     (next-20260727-5-g33d6e5134c70)
>
>   Kernel release: 7.2.0-rc5-next-20260727-stb-cbm-next-pvr-v4+
>
>   Mesa: 26.1.5
>   vulkan-powervr: 26.1.5
>   Firmware:
>     rogue_4.40.2.51_v1.fw
>     SHA256:
>     f44b7056992fb4057c987dcd7073468bec628aa56cb9815b1162f1cb7c1d73f2

My firmware blob is different from yours:

powervr 13000000.gpu: [drm] loaded firmware powervr/rogue_4.40.2.51_v1.fw
powervr 13000000.gpu: [drm] FW version v1.0 (build 6503725 OS)

SHA256: 1456504351bd041f0bf96667403ad32460fc7b807c09858df1f083e207323e4a

Funny thing is neither of ours match the official firmware blobs released
by Imagination [1].

The latest version is "FW version v1.1 (build 6976702 OS)" with
SHA256: e6bf10aaf442798fd81df9b9122e7e85900aafe77fcbec34b426af435c2b1c44

This version also works for me.

The "initial version" is "FW version v1.0 (build 6734358 OS)" with
SHA256: baa227de4f297b7c0928c6535d15affd80aa9c5f528d2d5dc4b764ad050d22f2

And this version also works.

It seems your firmware build is even older than mine. I suggest you
update it and try again?

[1] https://gitlab.freedesktop.org/imagination/linux-firmware/-/blob/powervr/powervr/rogue_4.40.2.51_v1.fw


> All five patches applied cleanly. The PowerVR driver probes, loads the
> firmware, and creates the DRM render node successfully.
>
> However, when I run the following from an SSH session without GDM or
> another graphical session running:
>
>   PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 vulkaninfo --summary
>
> Mesa prints the expected GX6250 warnings:
>
>   Missing reset support for brn51764
>   Missing reset support for brn58839
>   Missing support for brn62269
>
> The command then hangs, and the kernel reports:
>
>   powervr 13000000.gpu: [drm] *ERROR* GPU device lost
>
> There are no additional timeout, MMU fault, firmware, clock, or runtime
> PM messages immediately before the device-lost message.
>
> I originally also observed the same failure when GDM started GNOME
> Shell, but reproducing it with vulkaninfo from a non-graphical SSH
> session indicates that this is not specific to Mutter or GNOME.
>
> Since your cover letter reports that vkmark and glmark2-es2-drm work
> with Mesa 26.1.5, I suspect that there may be a difference in the
> kernel configuration or another part of the test environment.
>
> Could you please share the following details from your working setup?
>
>   1. The exact Chromebook board/model used for testing

The codename is "telesu", which is basically a hana in a different case.

>   2. The exact kernel base commit

I have a whole bunch of patches on top of next-20260727, but none
that should affect this.

>   3. The kernel configuration, or at least the relevant DRM, PM,
>      generic power-domain, IOMMU, and MediaTek clock options

All relevant options are built-in.

>   4. Whether CONFIG_DRM_POWERVR was built-in or built as a module

Module.

>   5. The firmware SHA256

See above.

>   6. The kernel command line and bootloader used

Chromebook's builtin bootloader.

cmdline:

    cros_secure root=PARTUUID=824526A4-24EE-344D-85A2-20630C42D31A
    console=tty0 console=ttyS0,115200n8 earlycon ro text drm.debug=0x106
    panic=30 rootwait log_buf_len=1M no_console_suspend

AFAICT nothing special.

>   7. Whether `vulkaninfo --summary` also completes successfully
>
> My current relevant configuration includes:
>
> CONFIG_PM_SLEEP=y
> CONFIG_PM=y
> CONFIG_PM_GENERIC_DOMAINS=y
> CONFIG_MODULES=y
> CONFIG_DMA_SHARED_BUFFER=y
> CONFIG_DRM_POWERVR=m
> CONFIG_DRM_MEDIATEK=y
> CONFIG_SYNC_FILE=y
> CONFIG_COMMON_CLK_MT8173_MFGTOP=y
> CONFIG_IOMMU_SUPPORT=y
> CONFIG_ARM_SMMU=y
> CONFIG_MTK_IOMMU=y
>
> I would be happy to test additional patches or provide any further
> logs, kernel configuration, or debugging information if that would
> help.

As mentioned above, please try updating your firmware blob. Your
version is even older than mine, and neither of ours is the "official"
release.


Thanks
ChenYu


> Thanks,
> YoungJoon Lee
>
> 2026年7月29日(水) 0:28 AngeloGioacchino Del Regno
> <angelogioacchino.delregno@collabora.com>:
> >
> > On 7/28/26 16:44, Chen-Yu Tsai wrote:
> > > On Tue, Jul 28, 2026 at 10:33 PM AngeloGioacchino Del Regno
> > > <angelogioacchino.delregno@collabora.com> wrote:
> > >>
> > >> On 7/28/26 15:13, Chen-Yu Tsai wrote:
> > >>> On Tue, Jul 28, 2026 at 9:10 PM Brian Masney <bmasney@redhat.com> wrote:
> > >>>>
> > >>>> Hi Chen-Yu,
> > >>>>
> > >>>> On Tue, Jul 28, 2026 at 05:17:58PM +0800, Chen-Yu Tsai wrote:
> > >>>>> Hi everyone,
> > >>>>>
> > >>>>> This is v4 of my MT8173 PowerVR GPU support series.
> > >>>>>
> > >>>>> This time around Mesa was ready for basic testing, using both vulkanmark
> > >>>>> and glmark2-es2-drm (with Zink). Details below.
> > >>>>>
> > >>>>> Changes since v3 (all in the clk driver patch):
> > >>>>> - Changed pm_runtime_put() to pm_runtime_put_sync()
> > >>>>> - Added missing of_node_put() in remove function
> > >>>>>
> > >>>>> Changes since v2 (all in the clk driver patch):
> > >>>>> - Made COMMON_CLK_MT8173_MFGTOP depend on PM
> > >>>>>     - Needed since the driver implements PM domains using the generic PM
> > >>>>>       domain library, which also depends on PM
> > >>>>>     - Fixes build breakage (kernel test robot)
> > >>>>> - Fixed "RST_DELAY_CNT" name (Brian)
> > >>>>> - Dropped unused mfg_desc (Brian)
> > >>>>> - Added check of clk_prepare_enable()'s return value in
> > >>>>>     clk_mt8173_mfgtop_power_on() (Brian)
> > >>>>> - Saved error value for return in IS_ERR(data->clk_26m) branch
> > >>>>>     (Dan Carpenter / kernel test robot w/ smatch)
> > >>>>>
> > >>>>> Changes since v1:
> > >>>>> - Adapted to changed DT bindings
> > >>>>> - Dropped driver change
> > >>>>> - Use same power domain for "a" and "b" GPU power domains
> > >>>>>
> > >>>>>
> > >>>>> This series enables the PowerVR GPU found in the MT8173 SoC, found in
> > >>>>> some Chromebooks.
> > >>>>
> > >>>> I'm making a pull for Stephen for the clk changes. Should patches 1,2,4
> > >>>> go through the clk tree? Patches 3,5 go through the DRM tree?
> > >>>
> > >>> Only patches 1 and 2 should go through the clock tree.
> > >>>
> > >>> Patch 3, 4, 5 can all go through the soc tree if Angelo wants to pick up
> > >>> DT binding patches. Otherwise I can push patch 3 through drm-misc.
> > >>>
> > >>
> > >> Not sure if I can really take the DRM bindings patch through soc.
> > >>
> > >> I will take the devicetree ones exactly right now, even though it's going to
> > >> give warnings.
> > >>
> > >> I trust that you'll make the binding get into linux-next before it's too late.
> > >
> > > Rob beat me to it. :D
> >
> > Love it!
> >
> > Thanks Rob :-D
> >
> > Cheers,
> > Angelo

Re: [PATCH v4 0/5] powervr: MT8173 GPU support

[YoungJoon Lee]

Hi Chen-Yu,

Thank you. Updating the firmware fixed the issue.

I replaced my previous firmware blob with the official v1.1 firmware:

  FW version v1.1 (build 6976702 OS)

  SHA256:
  e6bf10aaf442798fd81df9b9122e7e85900aafe77fcbec34b426af435c2b1c44

After rebooting, the driver loaded the new firmware successfully:

  powervr 13000000.gpu: [drm] loaded firmware
  powervr/rogue_4.40.2.51_v1.fw
  powervr 13000000.gpu: [drm] FW version v1.1
  (build 6976702 OS)

I then ran:

  PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 vulkaninfo --summary

This now completes successfully and detects the PowerVR Rogue GX6250.
The previous "GPU device lost" error no longer occurs.

So the issue was caused by the older, non-official firmware blob I was
using, rather than the v4 kernel series or my kernel configuration.

Thank you for pointing this out, and sorry for the noise.

Tested-by: YoungJoon Lee <getfeus@gmail.com>

Best regards,
YoungJoon

2026年7月29日(水) 12:32 Chen-Yu Tsai <wenst@chromium.org>:
>
> On Wed, Jul 29, 2026 at 8:08 AM YoungJoon Lee <getfeus@gmail.com> wrote:
> >
> > Hi Chen-Yu,
> >
> > Thank you for posting the v4 series.
> >
> > I tested the complete v4 series on my MT8173 Chromebook, but I am
> > seeing a GPU device loss as soon as Mesa initializes the Vulkan device.
> >
> > My current setup is:
> >
> >   Board: Google Elm / Acer Chromebook R13 (CB5-312T)
> >   Kernel:
> >     linux-next next-20260727
> >     commit: 33d6e5134c70446eddafbb3fd5ad088e848a7ad6
> >     (next-20260727-5-g33d6e5134c70)
> >
> >   Kernel release: 7.2.0-rc5-next-20260727-stb-cbm-next-pvr-v4+
> >
> >   Mesa: 26.1.5
> >   vulkan-powervr: 26.1.5
> >   Firmware:
> >     rogue_4.40.2.51_v1.fw
> >     SHA256:
> >     f44b7056992fb4057c987dcd7073468bec628aa56cb9815b1162f1cb7c1d73f2
>
> My firmware blob is different from yours:
>
> powervr 13000000.gpu: [drm] loaded firmware powervr/rogue_4.40.2.51_v1.fw
> powervr 13000000.gpu: [drm] FW version v1.0 (build 6503725 OS)
>
> SHA256: 1456504351bd041f0bf96667403ad32460fc7b807c09858df1f083e207323e4a
>
> Funny thing is neither of ours match the official firmware blobs released
> by Imagination [1].
>
> The latest version is "FW version v1.1 (build 6976702 OS)" with
> SHA256: e6bf10aaf442798fd81df9b9122e7e85900aafe77fcbec34b426af435c2b1c44
>
> This version also works for me.
>
> The "initial version" is "FW version v1.0 (build 6734358 OS)" with
> SHA256: baa227de4f297b7c0928c6535d15affd80aa9c5f528d2d5dc4b764ad050d22f2
>
> And this version also works.
>
> It seems your firmware build is even older than mine. I suggest you
> update it and try again?
>
> [1] https://gitlab.freedesktop.org/imagination/linux-firmware/-/blob/powervr/powervr/rogue_4.40.2.51_v1.fw
>
>
> > All five patches applied cleanly. The PowerVR driver probes, loads the
> > firmware, and creates the DRM render node successfully.
> >
> > However, when I run the following from an SSH session without GDM or
> > another graphical session running:
> >
> >   PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 vulkaninfo --summary
> >
> > Mesa prints the expected GX6250 warnings:
> >
> >   Missing reset support for brn51764
> >   Missing reset support for brn58839
> >   Missing support for brn62269
> >
> > The command then hangs, and the kernel reports:
> >
> >   powervr 13000000.gpu: [drm] *ERROR* GPU device lost
> >
> > There are no additional timeout, MMU fault, firmware, clock, or runtime
> > PM messages immediately before the device-lost message.
> >
> > I originally also observed the same failure when GDM started GNOME
> > Shell, but reproducing it with vulkaninfo from a non-graphical SSH
> > session indicates that this is not specific to Mutter or GNOME.
> >
> > Since your cover letter reports that vkmark and glmark2-es2-drm work
> > with Mesa 26.1.5, I suspect that there may be a difference in the
> > kernel configuration or another part of the test environment.
> >
> > Could you please share the following details from your working setup?
> >
> >   1. The exact Chromebook board/model used for testing
>
> The codename is "telesu", which is basically a hana in a different case.
>
> >   2. The exact kernel base commit
>
> I have a whole bunch of patches on top of next-20260727, but none
> that should affect this.
>
> >   3. The kernel configuration, or at least the relevant DRM, PM,
> >      generic power-domain, IOMMU, and MediaTek clock options
>
> All relevant options are built-in.
>
> >   4. Whether CONFIG_DRM_POWERVR was built-in or built as a module
>
> Module.
>
> >   5. The firmware SHA256
>
> See above.
>
> >   6. The kernel command line and bootloader used
>
> Chromebook's builtin bootloader.
>
> cmdline:
>
>     cros_secure root=PARTUUID=824526A4-24EE-344D-85A2-20630C42D31A
>     console=tty0 console=ttyS0,115200n8 earlycon ro text drm.debug=0x106
>     panic=30 rootwait log_buf_len=1M no_console_suspend
>
> AFAICT nothing special.
>
> >   7. Whether `vulkaninfo --summary` also completes successfully
> >
> > My current relevant configuration includes:
> >
> > CONFIG_PM_SLEEP=y
> > CONFIG_PM=y
> > CONFIG_PM_GENERIC_DOMAINS=y
> > CONFIG_MODULES=y
> > CONFIG_DMA_SHARED_BUFFER=y
> > CONFIG_DRM_POWERVR=m
> > CONFIG_DRM_MEDIATEK=y
> > CONFIG_SYNC_FILE=y
> > CONFIG_COMMON_CLK_MT8173_MFGTOP=y
> > CONFIG_IOMMU_SUPPORT=y
> > CONFIG_ARM_SMMU=y
> > CONFIG_MTK_IOMMU=y
> >
> > I would be happy to test additional patches or provide any further
> > logs, kernel configuration, or debugging information if that would
> > help.
>
> As mentioned above, please try updating your firmware blob. Your
> version is even older than mine, and neither of ours is the "official"
> release.
>
>
> Thanks
> ChenYu
>
>
> > Thanks,
> > YoungJoon Lee
> >
> > 2026年7月29日(水) 0:28 AngeloGioacchino Del Regno
> > <angelogioacchino.delregno@collabora.com>:
> > >
> > > On 7/28/26 16:44, Chen-Yu Tsai wrote:
> > > > On Tue, Jul 28, 2026 at 10:33 PM AngeloGioacchino Del Regno
> > > > <angelogioacchino.delregno@collabora.com> wrote:
> > > >>
> > > >> On 7/28/26 15:13, Chen-Yu Tsai wrote:
> > > >>> On Tue, Jul 28, 2026 at 9:10 PM Brian Masney <bmasney@redhat.com> wrote:
> > > >>>>
> > > >>>> Hi Chen-Yu,
> > > >>>>
> > > >>>> On Tue, Jul 28, 2026 at 05:17:58PM +0800, Chen-Yu Tsai wrote:
> > > >>>>> Hi everyone,
> > > >>>>>
> > > >>>>> This is v4 of my MT8173 PowerVR GPU support series.
> > > >>>>>
> > > >>>>> This time around Mesa was ready for basic testing, using both vulkanmark
> > > >>>>> and glmark2-es2-drm (with Zink). Details below.
> > > >>>>>
> > > >>>>> Changes since v3 (all in the clk driver patch):
> > > >>>>> - Changed pm_runtime_put() to pm_runtime_put_sync()
> > > >>>>> - Added missing of_node_put() in remove function
> > > >>>>>
> > > >>>>> Changes since v2 (all in the clk driver patch):
> > > >>>>> - Made COMMON_CLK_MT8173_MFGTOP depend on PM
> > > >>>>>     - Needed since the driver implements PM domains using the generic PM
> > > >>>>>       domain library, which also depends on PM
> > > >>>>>     - Fixes build breakage (kernel test robot)
> > > >>>>> - Fixed "RST_DELAY_CNT" name (Brian)
> > > >>>>> - Dropped unused mfg_desc (Brian)
> > > >>>>> - Added check of clk_prepare_enable()'s return value in
> > > >>>>>     clk_mt8173_mfgtop_power_on() (Brian)
> > > >>>>> - Saved error value for return in IS_ERR(data->clk_26m) branch
> > > >>>>>     (Dan Carpenter / kernel test robot w/ smatch)
> > > >>>>>
> > > >>>>> Changes since v1:
> > > >>>>> - Adapted to changed DT bindings
> > > >>>>> - Dropped driver change
> > > >>>>> - Use same power domain for "a" and "b" GPU power domains
> > > >>>>>
> > > >>>>>
> > > >>>>> This series enables the PowerVR GPU found in the MT8173 SoC, found in
> > > >>>>> some Chromebooks.
> > > >>>>
> > > >>>> I'm making a pull for Stephen for the clk changes. Should patches 1,2,4
> > > >>>> go through the clk tree? Patches 3,5 go through the DRM tree?
> > > >>>
> > > >>> Only patches 1 and 2 should go through the clock tree.
> > > >>>
> > > >>> Patch 3, 4, 5 can all go through the soc tree if Angelo wants to pick up
> > > >>> DT binding patches. Otherwise I can push patch 3 through drm-misc.
> > > >>>
> > > >>
> > > >> Not sure if I can really take the DRM bindings patch through soc.
> > > >>
> > > >> I will take the devicetree ones exactly right now, even though it's going to
> > > >> give warnings.
> > > >>
> > > >> I trust that you'll make the binding get into linux-next before it's too late.
> > > >
> > > > Rob beat me to it. :D
> > >
> > > Love it!
> > >
> > > Thanks Rob :-D
> > >
> > > Cheers,
> > > Angelo

Re: [PATCH v4 0/5] powervr: MT8173 GPU support

[YoungJoon Lee]

Hi Chen-Yu,

A follow-up to my previous email.

The official v1.1 firmware did fix the original "GPU device lost"
problem.

The following now works correctly:

    PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 vulkaninfo --summary

The driver initializes successfully and detects the PowerVR Rogue
GX6250.

However, while testing actual rendering, I found another issue which
appears to be unrelated to the firmware.

Kernel:

    Linux 7.2.0-rc5-next-20260727-stb-cbm-next-pvr-v4+

Board:

    Google Elm (Acer Chromebook R13 / MT8173)

Mesa:

    mesa 26.1.5
    vulkan-powervr 26.1.5

Firmware:

    rogue_4.40.2.51_v1.fw
    FW version v1.1 (build 6976702 OS)

Kernel command line:

    powervr.exp_hw_support=1

Test command:

    PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 glmark2-es2-drm

Renderer:

    GL_RENDERER:
    zink Vulkan 1.2
    (PowerVR Rogue GX6250)

The benchmark progresses normally:

    build (VBO off)          212 FPS
    build (VBO on)           216 FPS
    texture nearest          174 FPS
    texture linear           173 FPS
    texture mipmap           174 FPS
    shading gouraud          165 FPS
    shading blinn-phong      135 FPS
    shading phong             99 FPS

It consistently hangs at:

    shading=cel

Immediately afterwards the kernel reports:

    refcount_t: underflow; use-after-free

The first warning is:

    pvr_free_list_put()
      -> pvr_hwrt_dataset_release()
      -> pvr_hwrt_dataset_put()
      -> pvr_ioctl_destroy_hwrt_dataset()

followed by:

    refcount_warn_saturate()

Shortly afterwards another kernel Oops occurs:

    Unable to handle kernel NULL pointer dereference

The second backtrace shows:

    pvr_gem_object_create()
      -> pvr_fw_object_create()
      -> pvr_hwrt_dataset_create()
      -> pvr_ioctl_create_hwrt_dataset()

The glmark2 process remains as:

    glmark2-es2-drm <defunct>

The system is otherwise still reachable through SSH.

I collected additional diagnostics, including:

    - complete dmesg
    - complete kernel journal
    - kernel configuration
    - PowerVR module information
    - userspace package versions
    - process/thread state
    - runtime PM state
    - running Device Tree

I can send any of these if they would help.

Also, please disregard my previous Tested-by tag for now, since this
rendering issue was discovered afterwards.

Thank you again for your help.

Best regards,

YoungJoon Lee

2026年7月29日(水) 13:38 YoungJoon Lee <getfeus@gmail.com>:
>
> Hi Chen-Yu,
>
> Thank you. Updating the firmware fixed the issue.
>
> I replaced my previous firmware blob with the official v1.1 firmware:
>
>   FW version v1.1 (build 6976702 OS)
>
>   SHA256:
>   e6bf10aaf442798fd81df9b9122e7e85900aafe77fcbec34b426af435c2b1c44
>
> After rebooting, the driver loaded the new firmware successfully:
>
>   powervr 13000000.gpu: [drm] loaded firmware
>   powervr/rogue_4.40.2.51_v1.fw
>   powervr 13000000.gpu: [drm] FW version v1.1
>   (build 6976702 OS)
>
> I then ran:
>
>   PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 vulkaninfo --summary
>
> This now completes successfully and detects the PowerVR Rogue GX6250.
> The previous "GPU device lost" error no longer occurs.
>
> So the issue was caused by the older, non-official firmware blob I was
> using, rather than the v4 kernel series or my kernel configuration.
>
> Thank you for pointing this out, and sorry for the noise.
>
> Tested-by: YoungJoon Lee <getfeus@gmail.com>
>
> Best regards,
> YoungJoon
>
> 2026年7月29日(水) 12:32 Chen-Yu Tsai <wenst@chromium.org>:
> >
> > On Wed, Jul 29, 2026 at 8:08 AM YoungJoon Lee <getfeus@gmail.com> wrote:
> > >
> > > Hi Chen-Yu,
> > >
> > > Thank you for posting the v4 series.
> > >
> > > I tested the complete v4 series on my MT8173 Chromebook, but I am
> > > seeing a GPU device loss as soon as Mesa initializes the Vulkan device.
> > >
> > > My current setup is:
> > >
> > >   Board: Google Elm / Acer Chromebook R13 (CB5-312T)
> > >   Kernel:
> > >     linux-next next-20260727
> > >     commit: 33d6e5134c70446eddafbb3fd5ad088e848a7ad6
> > >     (next-20260727-5-g33d6e5134c70)
> > >
> > >   Kernel release: 7.2.0-rc5-next-20260727-stb-cbm-next-pvr-v4+
> > >
> > >   Mesa: 26.1.5
> > >   vulkan-powervr: 26.1.5
> > >   Firmware:
> > >     rogue_4.40.2.51_v1.fw
> > >     SHA256:
> > >     f44b7056992fb4057c987dcd7073468bec628aa56cb9815b1162f1cb7c1d73f2
> >
> > My firmware blob is different from yours:
> >
> > powervr 13000000.gpu: [drm] loaded firmware powervr/rogue_4.40.2.51_v1.fw
> > powervr 13000000.gpu: [drm] FW version v1.0 (build 6503725 OS)
> >
> > SHA256: 1456504351bd041f0bf96667403ad32460fc7b807c09858df1f083e207323e4a
> >
> > Funny thing is neither of ours match the official firmware blobs released
> > by Imagination [1].
> >
> > The latest version is "FW version v1.1 (build 6976702 OS)" with
> > SHA256: e6bf10aaf442798fd81df9b9122e7e85900aafe77fcbec34b426af435c2b1c44
> >
> > This version also works for me.
> >
> > The "initial version" is "FW version v1.0 (build 6734358 OS)" with
> > SHA256: baa227de4f297b7c0928c6535d15affd80aa9c5f528d2d5dc4b764ad050d22f2
> >
> > And this version also works.
> >
> > It seems your firmware build is even older than mine. I suggest you
> > update it and try again?
> >
> > [1] https://gitlab.freedesktop.org/imagination/linux-firmware/-/blob/powervr/powervr/rogue_4.40.2.51_v1.fw
> >
> >
> > > All five patches applied cleanly. The PowerVR driver probes, loads the
> > > firmware, and creates the DRM render node successfully.
> > >
> > > However, when I run the following from an SSH session without GDM or
> > > another graphical session running:
> > >
> > >   PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 vulkaninfo --summary
> > >
> > > Mesa prints the expected GX6250 warnings:
> > >
> > >   Missing reset support for brn51764
> > >   Missing reset support for brn58839
> > >   Missing support for brn62269
> > >
> > > The command then hangs, and the kernel reports:
> > >
> > >   powervr 13000000.gpu: [drm] *ERROR* GPU device lost
> > >
> > > There are no additional timeout, MMU fault, firmware, clock, or runtime
> > > PM messages immediately before the device-lost message.
> > >
> > > I originally also observed the same failure when GDM started GNOME
> > > Shell, but reproducing it with vulkaninfo from a non-graphical SSH
> > > session indicates that this is not specific to Mutter or GNOME.
> > >
> > > Since your cover letter reports that vkmark and glmark2-es2-drm work
> > > with Mesa 26.1.5, I suspect that there may be a difference in the
> > > kernel configuration or another part of the test environment.
> > >
> > > Could you please share the following details from your working setup?
> > >
> > >   1. The exact Chromebook board/model used for testing
> >
> > The codename is "telesu", which is basically a hana in a different case.
> >
> > >   2. The exact kernel base commit
> >
> > I have a whole bunch of patches on top of next-20260727, but none
> > that should affect this.
> >
> > >   3. The kernel configuration, or at least the relevant DRM, PM,
> > >      generic power-domain, IOMMU, and MediaTek clock options
> >
> > All relevant options are built-in.
> >
> > >   4. Whether CONFIG_DRM_POWERVR was built-in or built as a module
> >
> > Module.
> >
> > >   5. The firmware SHA256
> >
> > See above.
> >
> > >   6. The kernel command line and bootloader used
> >
> > Chromebook's builtin bootloader.
> >
> > cmdline:
> >
> >     cros_secure root=PARTUUID=824526A4-24EE-344D-85A2-20630C42D31A
> >     console=tty0 console=ttyS0,115200n8 earlycon ro text drm.debug=0x106
> >     panic=30 rootwait log_buf_len=1M no_console_suspend
> >
> > AFAICT nothing special.
> >
> > >   7. Whether `vulkaninfo --summary` also completes successfully
> > >
> > > My current relevant configuration includes:
> > >
> > > CONFIG_PM_SLEEP=y
> > > CONFIG_PM=y
> > > CONFIG_PM_GENERIC_DOMAINS=y
> > > CONFIG_MODULES=y
> > > CONFIG_DMA_SHARED_BUFFER=y
> > > CONFIG_DRM_POWERVR=m
> > > CONFIG_DRM_MEDIATEK=y
> > > CONFIG_SYNC_FILE=y
> > > CONFIG_COMMON_CLK_MT8173_MFGTOP=y
> > > CONFIG_IOMMU_SUPPORT=y
> > > CONFIG_ARM_SMMU=y
> > > CONFIG_MTK_IOMMU=y
> > >
> > > I would be happy to test additional patches or provide any further
> > > logs, kernel configuration, or debugging information if that would
> > > help.
> >
> > As mentioned above, please try updating your firmware blob. Your
> > version is even older than mine, and neither of ours is the "official"
> > release.
> >
> >
> > Thanks
> > ChenYu
> >
> >
> > > Thanks,
> > > YoungJoon Lee
> > >
> > > 2026年7月29日(水) 0:28 AngeloGioacchino Del Regno
> > > <angelogioacchino.delregno@collabora.com>:
> > > >
> > > > On 7/28/26 16:44, Chen-Yu Tsai wrote:
> > > > > On Tue, Jul 28, 2026 at 10:33 PM AngeloGioacchino Del Regno
> > > > > <angelogioacchino.delregno@collabora.com> wrote:
> > > > >>
> > > > >> On 7/28/26 15:13, Chen-Yu Tsai wrote:
> > > > >>> On Tue, Jul 28, 2026 at 9:10 PM Brian Masney <bmasney@redhat.com> wrote:
> > > > >>>>
> > > > >>>> Hi Chen-Yu,
> > > > >>>>
> > > > >>>> On Tue, Jul 28, 2026 at 05:17:58PM +0800, Chen-Yu Tsai wrote:
> > > > >>>>> Hi everyone,
> > > > >>>>>
> > > > >>>>> This is v4 of my MT8173 PowerVR GPU support series.
> > > > >>>>>
> > > > >>>>> This time around Mesa was ready for basic testing, using both vulkanmark
> > > > >>>>> and glmark2-es2-drm (with Zink). Details below.
> > > > >>>>>
> > > > >>>>> Changes since v3 (all in the clk driver patch):
> > > > >>>>> - Changed pm_runtime_put() to pm_runtime_put_sync()
> > > > >>>>> - Added missing of_node_put() in remove function
> > > > >>>>>
> > > > >>>>> Changes since v2 (all in the clk driver patch):
> > > > >>>>> - Made COMMON_CLK_MT8173_MFGTOP depend on PM
> > > > >>>>>     - Needed since the driver implements PM domains using the generic PM
> > > > >>>>>       domain library, which also depends on PM
> > > > >>>>>     - Fixes build breakage (kernel test robot)
> > > > >>>>> - Fixed "RST_DELAY_CNT" name (Brian)
> > > > >>>>> - Dropped unused mfg_desc (Brian)
> > > > >>>>> - Added check of clk_prepare_enable()'s return value in
> > > > >>>>>     clk_mt8173_mfgtop_power_on() (Brian)
> > > > >>>>> - Saved error value for return in IS_ERR(data->clk_26m) branch
> > > > >>>>>     (Dan Carpenter / kernel test robot w/ smatch)
> > > > >>>>>
> > > > >>>>> Changes since v1:
> > > > >>>>> - Adapted to changed DT bindings
> > > > >>>>> - Dropped driver change
> > > > >>>>> - Use same power domain for "a" and "b" GPU power domains
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> This series enables the PowerVR GPU found in the MT8173 SoC, found in
> > > > >>>>> some Chromebooks.
> > > > >>>>
> > > > >>>> I'm making a pull for Stephen for the clk changes. Should patches 1,2,4
> > > > >>>> go through the clk tree? Patches 3,5 go through the DRM tree?
> > > > >>>
> > > > >>> Only patches 1 and 2 should go through the clock tree.
> > > > >>>
> > > > >>> Patch 3, 4, 5 can all go through the soc tree if Angelo wants to pick up
> > > > >>> DT binding patches. Otherwise I can push patch 3 through drm-misc.
> > > > >>>
> > > > >>
> > > > >> Not sure if I can really take the DRM bindings patch through soc.
> > > > >>
> > > > >> I will take the devicetree ones exactly right now, even though it's going to
> > > > >> give warnings.
> > > > >>
> > > > >> I trust that you'll make the binding get into linux-next before it's too late.
> > > > >
> > > > > Rob beat me to it. :D
> > > >
> > > > Love it!
> > > >
> > > > Thanks Rob :-D
> > > >
> > > > Cheers,
> > > > Angelo

Re: [PATCH v4 0/5] powervr: MT8173 GPU support

[Chen-Yu Tsai]

On Tue, Jul 28, 2026 at 10:33 PM AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com> wrote:
>
> On 7/28/26 15:13, Chen-Yu Tsai wrote:
> > On Tue, Jul 28, 2026 at 9:10 PM Brian Masney <bmasney@redhat.com> wrote:
> >>
> >> Hi Chen-Yu,
> >>
> >> On Tue, Jul 28, 2026 at 05:17:58PM +0800, Chen-Yu Tsai wrote:
> >>> Hi everyone,
> >>>
> >>> This is v4 of my MT8173 PowerVR GPU support series.
> >>>
> >>> This time around Mesa was ready for basic testing, using both vulkanmark
> >>> and glmark2-es2-drm (with Zink). Details below.
> >>>
> >>> Changes since v3 (all in the clk driver patch):
> >>> - Changed pm_runtime_put() to pm_runtime_put_sync()
> >>> - Added missing of_node_put() in remove function
> >>>
> >>> Changes since v2 (all in the clk driver patch):
> >>> - Made COMMON_CLK_MT8173_MFGTOP depend on PM
> >>>    - Needed since the driver implements PM domains using the generic PM
> >>>      domain library, which also depends on PM
> >>>    - Fixes build breakage (kernel test robot)
> >>> - Fixed "RST_DELAY_CNT" name (Brian)
> >>> - Dropped unused mfg_desc (Brian)
> >>> - Added check of clk_prepare_enable()'s return value in
> >>>    clk_mt8173_mfgtop_power_on() (Brian)
> >>> - Saved error value for return in IS_ERR(data->clk_26m) branch
> >>>    (Dan Carpenter / kernel test robot w/ smatch)
> >>>
> >>> Changes since v1:
> >>> - Adapted to changed DT bindings
> >>> - Dropped driver change
> >>> - Use same power domain for "a" and "b" GPU power domains
> >>>
> >>>
> >>> This series enables the PowerVR GPU found in the MT8173 SoC, found in
> >>> some Chromebooks.
> >>
> >> I'm making a pull for Stephen for the clk changes. Should patches 1,2,4
> >> go through the clk tree? Patches 3,5 go through the DRM tree?
> >
> > Only patches 1 and 2 should go through the clock tree.
> >
> > Patch 3, 4, 5 can all go through the soc tree if Angelo wants to pick up
> > DT binding patches. Otherwise I can push patch 3 through drm-misc.
> >
>
> Not sure if I can really take the DRM bindings patch through soc.
>
> I will take the devicetree ones exactly right now, even though it's going to
> give warnings.

Apologies for missing this, but the first DT patch depends on the clk DT
bindings patch for the clk ID macros. This is causing build errors in
linux-next right now.

Not sure how we can fix this right now.

Brian, would it be possible for you to split out that patch into a
separate immutable branch for Angelo to merge?

Otherwise Angelo might need to drop the DT patches until the next cycle.


Thanks
ChenYu

Re: [PATCH v4 0/5] powervr: MT8173 GPU support

[AngeloGioacchino Del Regno]

On 7/30/26 06:51, Chen-Yu Tsai wrote:
> On Tue, Jul 28, 2026 at 10:33 PM AngeloGioacchino Del Regno
> <angelogioacchino.delregno@collabora.com> wrote:
>>
>> On 7/28/26 15:13, Chen-Yu Tsai wrote:
>>> On Tue, Jul 28, 2026 at 9:10 PM Brian Masney <bmasney@redhat.com> wrote:
>>>>
>>>> Hi Chen-Yu,
>>>>
>>>> On Tue, Jul 28, 2026 at 05:17:58PM +0800, Chen-Yu Tsai wrote:
>>>>> Hi everyone,
>>>>>
>>>>> This is v4 of my MT8173 PowerVR GPU support series.
>>>>>
>>>>> This time around Mesa was ready for basic testing, using both vulkanmark
>>>>> and glmark2-es2-drm (with Zink). Details below.
>>>>>
>>>>> Changes since v3 (all in the clk driver patch):
>>>>> - Changed pm_runtime_put() to pm_runtime_put_sync()
>>>>> - Added missing of_node_put() in remove function
>>>>>
>>>>> Changes since v2 (all in the clk driver patch):
>>>>> - Made COMMON_CLK_MT8173_MFGTOP depend on PM
>>>>>     - Needed since the driver implements PM domains using the generic PM
>>>>>       domain library, which also depends on PM
>>>>>     - Fixes build breakage (kernel test robot)
>>>>> - Fixed "RST_DELAY_CNT" name (Brian)
>>>>> - Dropped unused mfg_desc (Brian)
>>>>> - Added check of clk_prepare_enable()'s return value in
>>>>>     clk_mt8173_mfgtop_power_on() (Brian)
>>>>> - Saved error value for return in IS_ERR(data->clk_26m) branch
>>>>>     (Dan Carpenter / kernel test robot w/ smatch)
>>>>>
>>>>> Changes since v1:
>>>>> - Adapted to changed DT bindings
>>>>> - Dropped driver change
>>>>> - Use same power domain for "a" and "b" GPU power domains
>>>>>
>>>>>
>>>>> This series enables the PowerVR GPU found in the MT8173 SoC, found in
>>>>> some Chromebooks.
>>>>
>>>> I'm making a pull for Stephen for the clk changes. Should patches 1,2,4
>>>> go through the clk tree? Patches 3,5 go through the DRM tree?
>>>
>>> Only patches 1 and 2 should go through the clock tree.
>>>
>>> Patch 3, 4, 5 can all go through the soc tree if Angelo wants to pick up
>>> DT binding patches. Otherwise I can push patch 3 through drm-misc.
>>>
>>
>> Not sure if I can really take the DRM bindings patch through soc.
>>
>> I will take the devicetree ones exactly right now, even though it's going to
>> give warnings.
> 
> Apologies for missing this, but the first DT patch depends on the clk DT
> bindings patch for the clk ID macros. This is causing build errors in
> linux-next right now.
> 
> Not sure how we can fix this right now.
> 
> Brian, would it be possible for you to split out that patch into a
> separate immutable branch for Angelo to merge?
> 
> Otherwise Angelo might need to drop the DT patches until the next cycle.
> 
> 
Yeah, that's so bad.
I'd be happy to be able to resolve this, but it's too late on my side.

I should've checked the DT patches more carefully, my bad: I got a bit too excited
to finally see this PowerVR stuff working on MT8173 and going upstream.

Sadly, I have to drop the devicetree patches :-(

Cheers,
Angelo

Re: [PATCH v4 0/5] powervr: MT8173 GPU support

[Chen-Yu Tsai]

On Wed, Jul 29, 2026 at 5:35 PM YoungJoon Lee <getfeus@gmail.com> wrote:
>
> Hi Chen-Yu,
>
> A follow-up to my previous email.
>
> The official v1.1 firmware did fix the original "GPU device lost"
> problem.
>
> The following now works correctly:
>
>     PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 vulkaninfo --summary
>
> The driver initializes successfully and detects the PowerVR Rogue
> GX6250.
>
> However, while testing actual rendering, I found another issue which
> appears to be unrelated to the firmware.
>
> Kernel:
>
>     Linux 7.2.0-rc5-next-20260727-stb-cbm-next-pvr-v4+
>
> Board:
>
>     Google Elm (Acer Chromebook R13 / MT8173)
>
> Mesa:
>
>     mesa 26.1.5
>     vulkan-powervr 26.1.5
>
> Firmware:
>
>     rogue_4.40.2.51_v1.fw
>     FW version v1.1 (build 6976702 OS)
>
> Kernel command line:
>
>     powervr.exp_hw_support=1
>
> Test command:
>
>     PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 glmark2-es2-drm
>
> Renderer:
>
>     GL_RENDERER:
>     zink Vulkan 1.2
>     (PowerVR Rogue GX6250)
>
> The benchmark progresses normally:
>
>     build (VBO off)          212 FPS
>     build (VBO on)           216 FPS
>     texture nearest          174 FPS
>     texture linear           173 FPS
>     texture mipmap           174 FPS
>     shading gouraud          165 FPS
>     shading blinn-phong      135 FPS
>     shading phong             99 FPS
>
> It consistently hangs at:
>
>     shading=cel
>
> Immediately afterwards the kernel reports:
>
>     refcount_t: underflow; use-after-free
>
> The first warning is:
>
>     pvr_free_list_put()
>       -> pvr_hwrt_dataset_release()
>       -> pvr_hwrt_dataset_put()
>       -> pvr_ioctl_destroy_hwrt_dataset()
>
> followed by:
>
>     refcount_warn_saturate()
>
> Shortly afterwards another kernel Oops occurs:
>
>     Unable to handle kernel NULL pointer dereference
>
> The second backtrace shows:
>
>     pvr_gem_object_create()
>       -> pvr_fw_object_create()
>       -> pvr_hwrt_dataset_create()
>       -> pvr_ioctl_create_hwrt_dataset()
>
> The glmark2 process remains as:
>
>     glmark2-es2-drm <defunct>

I think this is more related to the unsupported nature of the GX6250,
and not specific to MT8173. Maybe someone else on the Imagination or
DRM mailing lists has a better idea of what's going on.


ChenYu

> The system is otherwise still reachable through SSH.
>
> I collected additional diagnostics, including:
>
>     - complete dmesg
>     - complete kernel journal
>     - kernel configuration
>     - PowerVR module information
>     - userspace package versions
>     - process/thread state
>     - runtime PM state
>     - running Device Tree
>
> I can send any of these if they would help.
>
> Also, please disregard my previous Tested-by tag for now, since this
> rendering issue was discovered afterwards.
>
> Thank you again for your help.
>
> Best regards,
>
> YoungJoon Lee
>
> 2026年7月29日(水) 13:38 YoungJoon Lee <getfeus@gmail.com>:
> >
> > Hi Chen-Yu,
> >
> > Thank you. Updating the firmware fixed the issue.
> >
> > I replaced my previous firmware blob with the official v1.1 firmware:
> >
> >   FW version v1.1 (build 6976702 OS)
> >
> >   SHA256:
> >   e6bf10aaf442798fd81df9b9122e7e85900aafe77fcbec34b426af435c2b1c44
> >
> > After rebooting, the driver loaded the new firmware successfully:
> >
> >   powervr 13000000.gpu: [drm] loaded firmware
> >   powervr/rogue_4.40.2.51_v1.fw
> >   powervr 13000000.gpu: [drm] FW version v1.1
> >   (build 6976702 OS)
> >
> > I then ran:
> >
> >   PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 vulkaninfo --summary
> >
> > This now completes successfully and detects the PowerVR Rogue GX6250.
> > The previous "GPU device lost" error no longer occurs.
> >
> > So the issue was caused by the older, non-official firmware blob I was
> > using, rather than the v4 kernel series or my kernel configuration.
> >
> > Thank you for pointing this out, and sorry for the noise.
> >
> > Tested-by: YoungJoon Lee <getfeus@gmail.com>
> >
> > Best regards,
> > YoungJoon
> >
> > 2026年7月29日(水) 12:32 Chen-Yu Tsai <wenst@chromium.org>:
> > >
> > > On Wed, Jul 29, 2026 at 8:08 AM YoungJoon Lee <getfeus@gmail.com> wrote:
> > > >
> > > > Hi Chen-Yu,
> > > >
> > > > Thank you for posting the v4 series.
> > > >
> > > > I tested the complete v4 series on my MT8173 Chromebook, but I am
> > > > seeing a GPU device loss as soon as Mesa initializes the Vulkan device.
> > > >
> > > > My current setup is:
> > > >
> > > >   Board: Google Elm / Acer Chromebook R13 (CB5-312T)
> > > >   Kernel:
> > > >     linux-next next-20260727
> > > >     commit: 33d6e5134c70446eddafbb3fd5ad088e848a7ad6
> > > >     (next-20260727-5-g33d6e5134c70)
> > > >
> > > >   Kernel release: 7.2.0-rc5-next-20260727-stb-cbm-next-pvr-v4+
> > > >
> > > >   Mesa: 26.1.5
> > > >   vulkan-powervr: 26.1.5
> > > >   Firmware:
> > > >     rogue_4.40.2.51_v1.fw
> > > >     SHA256:
> > > >     f44b7056992fb4057c987dcd7073468bec628aa56cb9815b1162f1cb7c1d73f2
> > >
> > > My firmware blob is different from yours:
> > >
> > > powervr 13000000.gpu: [drm] loaded firmware powervr/rogue_4.40.2.51_v1.fw
> > > powervr 13000000.gpu: [drm] FW version v1.0 (build 6503725 OS)
> > >
> > > SHA256: 1456504351bd041f0bf96667403ad32460fc7b807c09858df1f083e207323e4a
> > >
> > > Funny thing is neither of ours match the official firmware blobs released
> > > by Imagination [1].
> > >
> > > The latest version is "FW version v1.1 (build 6976702 OS)" with
> > > SHA256: e6bf10aaf442798fd81df9b9122e7e85900aafe77fcbec34b426af435c2b1c44
> > >
> > > This version also works for me.
> > >
> > > The "initial version" is "FW version v1.0 (build 6734358 OS)" with
> > > SHA256: baa227de4f297b7c0928c6535d15affd80aa9c5f528d2d5dc4b764ad050d22f2
> > >
> > > And this version also works.
> > >
> > > It seems your firmware build is even older than mine. I suggest you
> > > update it and try again?
> > >
> > > [1] https://gitlab.freedesktop.org/imagination/linux-firmware/-/blob/powervr/powervr/rogue_4.40.2.51_v1.fw
> > >
> > >
> > > > All five patches applied cleanly. The PowerVR driver probes, loads the
> > > > firmware, and creates the DRM render node successfully.
> > > >
> > > > However, when I run the following from an SSH session without GDM or
> > > > another graphical session running:
> > > >
> > > >   PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 vulkaninfo --summary
> > > >
> > > > Mesa prints the expected GX6250 warnings:
> > > >
> > > >   Missing reset support for brn51764
> > > >   Missing reset support for brn58839
> > > >   Missing support for brn62269
> > > >
> > > > The command then hangs, and the kernel reports:
> > > >
> > > >   powervr 13000000.gpu: [drm] *ERROR* GPU device lost
> > > >
> > > > There are no additional timeout, MMU fault, firmware, clock, or runtime
> > > > PM messages immediately before the device-lost message.
> > > >
> > > > I originally also observed the same failure when GDM started GNOME
> > > > Shell, but reproducing it with vulkaninfo from a non-graphical SSH
> > > > session indicates that this is not specific to Mutter or GNOME.
> > > >
> > > > Since your cover letter reports that vkmark and glmark2-es2-drm work
> > > > with Mesa 26.1.5, I suspect that there may be a difference in the
> > > > kernel configuration or another part of the test environment.
> > > >
> > > > Could you please share the following details from your working setup?
> > > >
> > > >   1. The exact Chromebook board/model used for testing
> > >
> > > The codename is "telesu", which is basically a hana in a different case.
> > >
> > > >   2. The exact kernel base commit
> > >
> > > I have a whole bunch of patches on top of next-20260727, but none
> > > that should affect this.
> > >
> > > >   3. The kernel configuration, or at least the relevant DRM, PM,
> > > >      generic power-domain, IOMMU, and MediaTek clock options
> > >
> > > All relevant options are built-in.
> > >
> > > >   4. Whether CONFIG_DRM_POWERVR was built-in or built as a module
> > >
> > > Module.
> > >
> > > >   5. The firmware SHA256
> > >
> > > See above.
> > >
> > > >   6. The kernel command line and bootloader used
> > >
> > > Chromebook's builtin bootloader.
> > >
> > > cmdline:
> > >
> > >     cros_secure root=PARTUUID=824526A4-24EE-344D-85A2-20630C42D31A
> > >     console=tty0 console=ttyS0,115200n8 earlycon ro text drm.debug=0x106
> > >     panic=30 rootwait log_buf_len=1M no_console_suspend
> > >
> > > AFAICT nothing special.
> > >
> > > >   7. Whether `vulkaninfo --summary` also completes successfully
> > > >
> > > > My current relevant configuration includes:
> > > >
> > > > CONFIG_PM_SLEEP=y
> > > > CONFIG_PM=y
> > > > CONFIG_PM_GENERIC_DOMAINS=y
> > > > CONFIG_MODULES=y
> > > > CONFIG_DMA_SHARED_BUFFER=y
> > > > CONFIG_DRM_POWERVR=m
> > > > CONFIG_DRM_MEDIATEK=y
> > > > CONFIG_SYNC_FILE=y
> > > > CONFIG_COMMON_CLK_MT8173_MFGTOP=y
> > > > CONFIG_IOMMU_SUPPORT=y
> > > > CONFIG_ARM_SMMU=y
> > > > CONFIG_MTK_IOMMU=y
> > > >
> > > > I would be happy to test additional patches or provide any further
> > > > logs, kernel configuration, or debugging information if that would
> > > > help.
> > >
> > > As mentioned above, please try updating your firmware blob. Your
> > > version is even older than mine, and neither of ours is the "official"
> > > release.
> > >
> > >
> > > Thanks
> > > ChenYu
> > >
> > >
> > > > Thanks,
> > > > YoungJoon Lee
> > > >
> > > > 2026年7月29日(水) 0:28 AngeloGioacchino Del Regno
> > > > <angelogioacchino.delregno@collabora.com>:
> > > > >
> > > > > On 7/28/26 16:44, Chen-Yu Tsai wrote:
> > > > > > On Tue, Jul 28, 2026 at 10:33 PM AngeloGioacchino Del Regno
> > > > > > <angelogioacchino.delregno@collabora.com> wrote:
> > > > > >>
> > > > > >> On 7/28/26 15:13, Chen-Yu Tsai wrote:
> > > > > >>> On Tue, Jul 28, 2026 at 9:10 PM Brian Masney <bmasney@redhat.com> wrote:
> > > > > >>>>
> > > > > >>>> Hi Chen-Yu,
> > > > > >>>>
> > > > > >>>> On Tue, Jul 28, 2026 at 05:17:58PM +0800, Chen-Yu Tsai wrote:
> > > > > >>>>> Hi everyone,
> > > > > >>>>>
> > > > > >>>>> This is v4 of my MT8173 PowerVR GPU support series.
> > > > > >>>>>
> > > > > >>>>> This time around Mesa was ready for basic testing, using both vulkanmark
> > > > > >>>>> and glmark2-es2-drm (with Zink). Details below.
> > > > > >>>>>
> > > > > >>>>> Changes since v3 (all in the clk driver patch):
> > > > > >>>>> - Changed pm_runtime_put() to pm_runtime_put_sync()
> > > > > >>>>> - Added missing of_node_put() in remove function
> > > > > >>>>>
> > > > > >>>>> Changes since v2 (all in the clk driver patch):
> > > > > >>>>> - Made COMMON_CLK_MT8173_MFGTOP depend on PM
> > > > > >>>>>     - Needed since the driver implements PM domains using the generic PM
> > > > > >>>>>       domain library, which also depends on PM
> > > > > >>>>>     - Fixes build breakage (kernel test robot)
> > > > > >>>>> - Fixed "RST_DELAY_CNT" name (Brian)
> > > > > >>>>> - Dropped unused mfg_desc (Brian)
> > > > > >>>>> - Added check of clk_prepare_enable()'s return value in
> > > > > >>>>>     clk_mt8173_mfgtop_power_on() (Brian)
> > > > > >>>>> - Saved error value for return in IS_ERR(data->clk_26m) branch
> > > > > >>>>>     (Dan Carpenter / kernel test robot w/ smatch)
> > > > > >>>>>
> > > > > >>>>> Changes since v1:
> > > > > >>>>> - Adapted to changed DT bindings
> > > > > >>>>> - Dropped driver change
> > > > > >>>>> - Use same power domain for "a" and "b" GPU power domains
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>> This series enables the PowerVR GPU found in the MT8173 SoC, found in
> > > > > >>>>> some Chromebooks.
> > > > > >>>>
> > > > > >>>> I'm making a pull for Stephen for the clk changes. Should patches 1,2,4
> > > > > >>>> go through the clk tree? Patches 3,5 go through the DRM tree?
> > > > > >>>
> > > > > >>> Only patches 1 and 2 should go through the clock tree.
> > > > > >>>
> > > > > >>> Patch 3, 4, 5 can all go through the soc tree if Angelo wants to pick up
> > > > > >>> DT binding patches. Otherwise I can push patch 3 through drm-misc.
> > > > > >>>
> > > > > >>
> > > > > >> Not sure if I can really take the DRM bindings patch through soc.
> > > > > >>
> > > > > >> I will take the devicetree ones exactly right now, even though it's going to
> > > > > >> give warnings.
> > > > > >>
> > > > > >> I trust that you'll make the binding get into linux-next before it's too late.
> > > > > >
> > > > > > Rob beat me to it. :D
> > > > >
> > > > > Love it!
> > > > >
> > > > > Thanks Rob :-D
> > > > >
> > > > > Cheers,
> > > > > Angelo

Re: [PATCH v4 0/5] powervr: MT8173 GPU support

[YoungJoon Lee]

Thanks, that matches my understanding as well.

Since the MT8173 enablement patches do not touch the common HWRT/free-list
lifetime code, I agree that this is more likely related to the currently
unsupported GX6250 path.

I am preparing a diagnostic kernel patch to trace all free-list references
during HWRT creation and destruction. I will reproduce the issue again and
send the resulting trace to the Imagination and DRM mailing lists.

Thank you for taking a look.

2026年7月30日(木) 17:37 Chen-Yu Tsai <wenst@chromium.org>:
>
> On Wed, Jul 29, 2026 at 5:35 PM YoungJoon Lee <getfeus@gmail.com> wrote:
> >
> > Hi Chen-Yu,
> >
> > A follow-up to my previous email.
> >
> > The official v1.1 firmware did fix the original "GPU device lost"
> > problem.
> >
> > The following now works correctly:
> >
> >     PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 vulkaninfo --summary
> >
> > The driver initializes successfully and detects the PowerVR Rogue
> > GX6250.
> >
> > However, while testing actual rendering, I found another issue which
> > appears to be unrelated to the firmware.
> >
> > Kernel:
> >
> >     Linux 7.2.0-rc5-next-20260727-stb-cbm-next-pvr-v4+
> >
> > Board:
> >
> >     Google Elm (Acer Chromebook R13 / MT8173)
> >
> > Mesa:
> >
> >     mesa 26.1.5
> >     vulkan-powervr 26.1.5
> >
> > Firmware:
> >
> >     rogue_4.40.2.51_v1.fw
> >     FW version v1.1 (build 6976702 OS)
> >
> > Kernel command line:
> >
> >     powervr.exp_hw_support=1
> >
> > Test command:
> >
> >     PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 glmark2-es2-drm
> >
> > Renderer:
> >
> >     GL_RENDERER:
> >     zink Vulkan 1.2
> >     (PowerVR Rogue GX6250)
> >
> > The benchmark progresses normally:
> >
> >     build (VBO off)          212 FPS
> >     build (VBO on)           216 FPS
> >     texture nearest          174 FPS
> >     texture linear           173 FPS
> >     texture mipmap           174 FPS
> >     shading gouraud          165 FPS
> >     shading blinn-phong      135 FPS
> >     shading phong             99 FPS
> >
> > It consistently hangs at:
> >
> >     shading=cel
> >
> > Immediately afterwards the kernel reports:
> >
> >     refcount_t: underflow; use-after-free
> >
> > The first warning is:
> >
> >     pvr_free_list_put()
> >       -> pvr_hwrt_dataset_release()
> >       -> pvr_hwrt_dataset_put()
> >       -> pvr_ioctl_destroy_hwrt_dataset()
> >
> > followed by:
> >
> >     refcount_warn_saturate()
> >
> > Shortly afterwards another kernel Oops occurs:
> >
> >     Unable to handle kernel NULL pointer dereference
> >
> > The second backtrace shows:
> >
> >     pvr_gem_object_create()
> >       -> pvr_fw_object_create()
> >       -> pvr_hwrt_dataset_create()
> >       -> pvr_ioctl_create_hwrt_dataset()
> >
> > The glmark2 process remains as:
> >
> >     glmark2-es2-drm <defunct>
>
> I think this is more related to the unsupported nature of the GX6250,
> and not specific to MT8173. Maybe someone else on the Imagination or
> DRM mailing lists has a better idea of what's going on.
>
>
> ChenYu
>
> > The system is otherwise still reachable through SSH.
> >
> > I collected additional diagnostics, including:
> >
> >     - complete dmesg
> >     - complete kernel journal
> >     - kernel configuration
> >     - PowerVR module information
> >     - userspace package versions
> >     - process/thread state
> >     - runtime PM state
> >     - running Device Tree
> >
> > I can send any of these if they would help.
> >
> > Also, please disregard my previous Tested-by tag for now, since this
> > rendering issue was discovered afterwards.
> >
> > Thank you again for your help.
> >
> > Best regards,
> >
> > YoungJoon Lee
> >
> > 2026年7月29日(水) 13:38 YoungJoon Lee <getfeus@gmail.com>:
> > >
> > > Hi Chen-Yu,
> > >
> > > Thank you. Updating the firmware fixed the issue.
> > >
> > > I replaced my previous firmware blob with the official v1.1 firmware:
> > >
> > >   FW version v1.1 (build 6976702 OS)
> > >
> > >   SHA256:
> > >   e6bf10aaf442798fd81df9b9122e7e85900aafe77fcbec34b426af435c2b1c44
> > >
> > > After rebooting, the driver loaded the new firmware successfully:
> > >
> > >   powervr 13000000.gpu: [drm] loaded firmware
> > >   powervr/rogue_4.40.2.51_v1.fw
> > >   powervr 13000000.gpu: [drm] FW version v1.1
> > >   (build 6976702 OS)
> > >
> > > I then ran:
> > >
> > >   PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 vulkaninfo --summary
> > >
> > > This now completes successfully and detects the PowerVR Rogue GX6250.
> > > The previous "GPU device lost" error no longer occurs.
> > >
> > > So the issue was caused by the older, non-official firmware blob I was
> > > using, rather than the v4 kernel series or my kernel configuration.
> > >
> > > Thank you for pointing this out, and sorry for the noise.
> > >
> > > Tested-by: YoungJoon Lee <getfeus@gmail.com>
> > >
> > > Best regards,
> > > YoungJoon
> > >
> > > 2026年7月29日(水) 12:32 Chen-Yu Tsai <wenst@chromium.org>:
> > > >
> > > > On Wed, Jul 29, 2026 at 8:08 AM YoungJoon Lee <getfeus@gmail.com> wrote:
> > > > >
> > > > > Hi Chen-Yu,
> > > > >
> > > > > Thank you for posting the v4 series.
> > > > >
> > > > > I tested the complete v4 series on my MT8173 Chromebook, but I am
> > > > > seeing a GPU device loss as soon as Mesa initializes the Vulkan device.
> > > > >
> > > > > My current setup is:
> > > > >
> > > > >   Board: Google Elm / Acer Chromebook R13 (CB5-312T)
> > > > >   Kernel:
> > > > >     linux-next next-20260727
> > > > >     commit: 33d6e5134c70446eddafbb3fd5ad088e848a7ad6
> > > > >     (next-20260727-5-g33d6e5134c70)
> > > > >
> > > > >   Kernel release: 7.2.0-rc5-next-20260727-stb-cbm-next-pvr-v4+
> > > > >
> > > > >   Mesa: 26.1.5
> > > > >   vulkan-powervr: 26.1.5
> > > > >   Firmware:
> > > > >     rogue_4.40.2.51_v1.fw
> > > > >     SHA256:
> > > > >     f44b7056992fb4057c987dcd7073468bec628aa56cb9815b1162f1cb7c1d73f2
> > > >
> > > > My firmware blob is different from yours:
> > > >
> > > > powervr 13000000.gpu: [drm] loaded firmware powervr/rogue_4.40.2.51_v1.fw
> > > > powervr 13000000.gpu: [drm] FW version v1.0 (build 6503725 OS)
> > > >
> > > > SHA256: 1456504351bd041f0bf96667403ad32460fc7b807c09858df1f083e207323e4a
> > > >
> > > > Funny thing is neither of ours match the official firmware blobs released
> > > > by Imagination [1].
> > > >
> > > > The latest version is "FW version v1.1 (build 6976702 OS)" with
> > > > SHA256: e6bf10aaf442798fd81df9b9122e7e85900aafe77fcbec34b426af435c2b1c44
> > > >
> > > > This version also works for me.
> > > >
> > > > The "initial version" is "FW version v1.0 (build 6734358 OS)" with
> > > > SHA256: baa227de4f297b7c0928c6535d15affd80aa9c5f528d2d5dc4b764ad050d22f2
> > > >
> > > > And this version also works.
> > > >
> > > > It seems your firmware build is even older than mine. I suggest you
> > > > update it and try again?
> > > >
> > > > [1] https://gitlab.freedesktop.org/imagination/linux-firmware/-/blob/powervr/powervr/rogue_4.40.2.51_v1.fw
> > > >
> > > >
> > > > > All five patches applied cleanly. The PowerVR driver probes, loads the
> > > > > firmware, and creates the DRM render node successfully.
> > > > >
> > > > > However, when I run the following from an SSH session without GDM or
> > > > > another graphical session running:
> > > > >
> > > > >   PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 vulkaninfo --summary
> > > > >
> > > > > Mesa prints the expected GX6250 warnings:
> > > > >
> > > > >   Missing reset support for brn51764
> > > > >   Missing reset support for brn58839
> > > > >   Missing support for brn62269
> > > > >
> > > > > The command then hangs, and the kernel reports:
> > > > >
> > > > >   powervr 13000000.gpu: [drm] *ERROR* GPU device lost
> > > > >
> > > > > There are no additional timeout, MMU fault, firmware, clock, or runtime
> > > > > PM messages immediately before the device-lost message.
> > > > >
> > > > > I originally also observed the same failure when GDM started GNOME
> > > > > Shell, but reproducing it with vulkaninfo from a non-graphical SSH
> > > > > session indicates that this is not specific to Mutter or GNOME.
> > > > >
> > > > > Since your cover letter reports that vkmark and glmark2-es2-drm work
> > > > > with Mesa 26.1.5, I suspect that there may be a difference in the
> > > > > kernel configuration or another part of the test environment.
> > > > >
> > > > > Could you please share the following details from your working setup?
> > > > >
> > > > >   1. The exact Chromebook board/model used for testing
> > > >
> > > > The codename is "telesu", which is basically a hana in a different case.
> > > >
> > > > >   2. The exact kernel base commit
> > > >
> > > > I have a whole bunch of patches on top of next-20260727, but none
> > > > that should affect this.
> > > >
> > > > >   3. The kernel configuration, or at least the relevant DRM, PM,
> > > > >      generic power-domain, IOMMU, and MediaTek clock options
> > > >
> > > > All relevant options are built-in.
> > > >
> > > > >   4. Whether CONFIG_DRM_POWERVR was built-in or built as a module
> > > >
> > > > Module.
> > > >
> > > > >   5. The firmware SHA256
> > > >
> > > > See above.
> > > >
> > > > >   6. The kernel command line and bootloader used
> > > >
> > > > Chromebook's builtin bootloader.
> > > >
> > > > cmdline:
> > > >
> > > >     cros_secure root=PARTUUID=824526A4-24EE-344D-85A2-20630C42D31A
> > > >     console=tty0 console=ttyS0,115200n8 earlycon ro text drm.debug=0x106
> > > >     panic=30 rootwait log_buf_len=1M no_console_suspend
> > > >
> > > > AFAICT nothing special.
> > > >
> > > > >   7. Whether `vulkaninfo --summary` also completes successfully
> > > > >
> > > > > My current relevant configuration includes:
> > > > >
> > > > > CONFIG_PM_SLEEP=y
> > > > > CONFIG_PM=y
> > > > > CONFIG_PM_GENERIC_DOMAINS=y
> > > > > CONFIG_MODULES=y
> > > > > CONFIG_DMA_SHARED_BUFFER=y
> > > > > CONFIG_DRM_POWERVR=m
> > > > > CONFIG_DRM_MEDIATEK=y
> > > > > CONFIG_SYNC_FILE=y
> > > > > CONFIG_COMMON_CLK_MT8173_MFGTOP=y
> > > > > CONFIG_IOMMU_SUPPORT=y
> > > > > CONFIG_ARM_SMMU=y
> > > > > CONFIG_MTK_IOMMU=y
> > > > >
> > > > > I would be happy to test additional patches or provide any further
> > > > > logs, kernel configuration, or debugging information if that would
> > > > > help.
> > > >
> > > > As mentioned above, please try updating your firmware blob. Your
> > > > version is even older than mine, and neither of ours is the "official"
> > > > release.
> > > >
> > > >
> > > > Thanks
> > > > ChenYu
> > > >
> > > >
> > > > > Thanks,
> > > > > YoungJoon Lee
> > > > >
> > > > > 2026年7月29日(水) 0:28 AngeloGioacchino Del Regno
> > > > > <angelogioacchino.delregno@collabora.com>:
> > > > > >
> > > > > > On 7/28/26 16:44, Chen-Yu Tsai wrote:
> > > > > > > On Tue, Jul 28, 2026 at 10:33 PM AngeloGioacchino Del Regno
> > > > > > > <angelogioacchino.delregno@collabora.com> wrote:
> > > > > > >>
> > > > > > >> On 7/28/26 15:13, Chen-Yu Tsai wrote:
> > > > > > >>> On Tue, Jul 28, 2026 at 9:10 PM Brian Masney <bmasney@redhat.com> wrote:
> > > > > > >>>>
> > > > > > >>>> Hi Chen-Yu,
> > > > > > >>>>
> > > > > > >>>> On Tue, Jul 28, 2026 at 05:17:58PM +0800, Chen-Yu Tsai wrote:
> > > > > > >>>>> Hi everyone,
> > > > > > >>>>>
> > > > > > >>>>> This is v4 of my MT8173 PowerVR GPU support series.
> > > > > > >>>>>
> > > > > > >>>>> This time around Mesa was ready for basic testing, using both vulkanmark
> > > > > > >>>>> and glmark2-es2-drm (with Zink). Details below.
> > > > > > >>>>>
> > > > > > >>>>> Changes since v3 (all in the clk driver patch):
> > > > > > >>>>> - Changed pm_runtime_put() to pm_runtime_put_sync()
> > > > > > >>>>> - Added missing of_node_put() in remove function
> > > > > > >>>>>
> > > > > > >>>>> Changes since v2 (all in the clk driver patch):
> > > > > > >>>>> - Made COMMON_CLK_MT8173_MFGTOP depend on PM
> > > > > > >>>>>     - Needed since the driver implements PM domains using the generic PM
> > > > > > >>>>>       domain library, which also depends on PM
> > > > > > >>>>>     - Fixes build breakage (kernel test robot)
> > > > > > >>>>> - Fixed "RST_DELAY_CNT" name (Brian)
> > > > > > >>>>> - Dropped unused mfg_desc (Brian)
> > > > > > >>>>> - Added check of clk_prepare_enable()'s return value in
> > > > > > >>>>>     clk_mt8173_mfgtop_power_on() (Brian)
> > > > > > >>>>> - Saved error value for return in IS_ERR(data->clk_26m) branch
> > > > > > >>>>>     (Dan Carpenter / kernel test robot w/ smatch)
> > > > > > >>>>>
> > > > > > >>>>> Changes since v1:
> > > > > > >>>>> - Adapted to changed DT bindings
> > > > > > >>>>> - Dropped driver change
> > > > > > >>>>> - Use same power domain for "a" and "b" GPU power domains
> > > > > > >>>>>
> > > > > > >>>>>
> > > > > > >>>>> This series enables the PowerVR GPU found in the MT8173 SoC, found in
> > > > > > >>>>> some Chromebooks.
> > > > > > >>>>
> > > > > > >>>> I'm making a pull for Stephen for the clk changes. Should patches 1,2,4
> > > > > > >>>> go through the clk tree? Patches 3,5 go through the DRM tree?
> > > > > > >>>
> > > > > > >>> Only patches 1 and 2 should go through the clock tree.
> > > > > > >>>
> > > > > > >>> Patch 3, 4, 5 can all go through the soc tree if Angelo wants to pick up
> > > > > > >>> DT binding patches. Otherwise I can push patch 3 through drm-misc.
> > > > > > >>>
> > > > > > >>
> > > > > > >> Not sure if I can really take the DRM bindings patch through soc.
> > > > > > >>
> > > > > > >> I will take the devicetree ones exactly right now, even though it's going to
> > > > > > >> give warnings.
> > > > > > >>
> > > > > > >> I trust that you'll make the binding get into linux-next before it's too late.
> > > > > > >
> > > > > > > Rob beat me to it. :D
> > > > > >
> > > > > > Love it!
> > > > > >
> > > > > > Thanks Rob :-D
> > > > > >
> > > > > > Cheers,
> > > > > > Angelo

Re: [PATCH v4 0/5] powervr: MT8173 GPU support

[Brian Masney]

Hi Angelo and Chen-Yu,

On Thu, Jul 30, 2026 at 10:23:14AM +0200, AngeloGioacchino Del Regno wrote:
> On 7/30/26 06:51, Chen-Yu Tsai wrote:
> > On Tue, Jul 28, 2026 at 10:33 PM AngeloGioacchino Del Regno
> > <angelogioacchino.delregno@collabora.com> wrote:
> > > 
> > > On 7/28/26 15:13, Chen-Yu Tsai wrote:
> > > > On Tue, Jul 28, 2026 at 9:10 PM Brian Masney <bmasney@redhat.com> wrote:
> > > > > On Tue, Jul 28, 2026 at 05:17:58PM +0800, Chen-Yu Tsai wrote:
> > > > > > Hi everyone,
> > > > > > 
> > > > > > This is v4 of my MT8173 PowerVR GPU support series.
> > > > > > 
> > > > > > This time around Mesa was ready for basic testing, using both vulkanmark
> > > > > > and glmark2-es2-drm (with Zink). Details below.
> > > > > > 
> > > > > > Changes since v3 (all in the clk driver patch):
> > > > > > - Changed pm_runtime_put() to pm_runtime_put_sync()
> > > > > > - Added missing of_node_put() in remove function
> > > > > > 
> > > > > > Changes since v2 (all in the clk driver patch):
> > > > > > - Made COMMON_CLK_MT8173_MFGTOP depend on PM
> > > > > >     - Needed since the driver implements PM domains using the generic PM
> > > > > >       domain library, which also depends on PM
> > > > > >     - Fixes build breakage (kernel test robot)
> > > > > > - Fixed "RST_DELAY_CNT" name (Brian)
> > > > > > - Dropped unused mfg_desc (Brian)
> > > > > > - Added check of clk_prepare_enable()'s return value in
> > > > > >     clk_mt8173_mfgtop_power_on() (Brian)
> > > > > > - Saved error value for return in IS_ERR(data->clk_26m) branch
> > > > > >     (Dan Carpenter / kernel test robot w/ smatch)
> > > > > > 
> > > > > > Changes since v1:
> > > > > > - Adapted to changed DT bindings
> > > > > > - Dropped driver change
> > > > > > - Use same power domain for "a" and "b" GPU power domains
> > > > > > 
> > > > > > 
> > > > > > This series enables the PowerVR GPU found in the MT8173 SoC, found in
> > > > > > some Chromebooks.
> > > > > 
> > > > > I'm making a pull for Stephen for the clk changes. Should patches 1,2,4
> > > > > go through the clk tree? Patches 3,5 go through the DRM tree?
> > > > 
> > > > Only patches 1 and 2 should go through the clock tree.
> > > > 
> > > > Patch 3, 4, 5 can all go through the soc tree if Angelo wants to pick up
> > > > DT binding patches. Otherwise I can push patch 3 through drm-misc.
> > > > 
> > > 
> > > Not sure if I can really take the DRM bindings patch through soc.
> > > 
> > > I will take the devicetree ones exactly right now, even though it's going to
> > > give warnings.
> > 
> > Apologies for missing this, but the first DT patch depends on the clk DT
> > bindings patch for the clk ID macros. This is causing build errors in
> > linux-next right now.
> > 
> > Not sure how we can fix this right now.
> > 
> > Brian, would it be possible for you to split out that patch into a
> > separate immutable branch for Angelo to merge?

Yes, I can split things out and make an immutable branch this morning.
But it sounds too late for that.

> > 
> > Otherwise Angelo might need to drop the DT patches until the next cycle.
>
> Yeah, that's so bad.
> I'd be happy to be able to resolve this, but it's too late on my side.
> 
> I should've checked the DT patches more carefully, my bad: I got a bit too excited
> to finally see this PowerVR stuff working on MT8173 and going upstream.
> 
> Sadly, I have to drop the devicetree patches :-(

Chen-Yu: Could Angelo add an Acked-by to the three patches, and then I send
Stephen an additional pull with just those patches? Do you think he'd
pull that?

Brian

Re: [PATCH v4 0/5] powervr: MT8173 GPU support

[Chen-Yu Tsai]

On Thu, Jul 30, 2026 at 7:06 PM Brian Masney <bmasney@redhat.com> wrote:
>
> Hi Angelo and Chen-Yu,
>
> On Thu, Jul 30, 2026 at 10:23:14AM +0200, AngeloGioacchino Del Regno wrote:
> > On 7/30/26 06:51, Chen-Yu Tsai wrote:
> > > On Tue, Jul 28, 2026 at 10:33 PM AngeloGioacchino Del Regno
> > > <angelogioacchino.delregno@collabora.com> wrote:
> > > >
> > > > On 7/28/26 15:13, Chen-Yu Tsai wrote:
> > > > > On Tue, Jul 28, 2026 at 9:10 PM Brian Masney <bmasney@redhat.com> wrote:
> > > > > > On Tue, Jul 28, 2026 at 05:17:58PM +0800, Chen-Yu Tsai wrote:
> > > > > > > Hi everyone,
> > > > > > >
> > > > > > > This is v4 of my MT8173 PowerVR GPU support series.
> > > > > > >
> > > > > > > This time around Mesa was ready for basic testing, using both vulkanmark
> > > > > > > and glmark2-es2-drm (with Zink). Details below.
> > > > > > >
> > > > > > > Changes since v3 (all in the clk driver patch):
> > > > > > > - Changed pm_runtime_put() to pm_runtime_put_sync()
> > > > > > > - Added missing of_node_put() in remove function
> > > > > > >
> > > > > > > Changes since v2 (all in the clk driver patch):
> > > > > > > - Made COMMON_CLK_MT8173_MFGTOP depend on PM
> > > > > > >     - Needed since the driver implements PM domains using the generic PM
> > > > > > >       domain library, which also depends on PM
> > > > > > >     - Fixes build breakage (kernel test robot)
> > > > > > > - Fixed "RST_DELAY_CNT" name (Brian)
> > > > > > > - Dropped unused mfg_desc (Brian)
> > > > > > > - Added check of clk_prepare_enable()'s return value in
> > > > > > >     clk_mt8173_mfgtop_power_on() (Brian)
> > > > > > > - Saved error value for return in IS_ERR(data->clk_26m) branch
> > > > > > >     (Dan Carpenter / kernel test robot w/ smatch)
> > > > > > >
> > > > > > > Changes since v1:
> > > > > > > - Adapted to changed DT bindings
> > > > > > > - Dropped driver change
> > > > > > > - Use same power domain for "a" and "b" GPU power domains
> > > > > > >
> > > > > > >
> > > > > > > This series enables the PowerVR GPU found in the MT8173 SoC, found in
> > > > > > > some Chromebooks.
> > > > > >
> > > > > > I'm making a pull for Stephen for the clk changes. Should patches 1,2,4
> > > > > > go through the clk tree? Patches 3,5 go through the DRM tree?
> > > > >
> > > > > Only patches 1 and 2 should go through the clock tree.
> > > > >
> > > > > Patch 3, 4, 5 can all go through the soc tree if Angelo wants to pick up
> > > > > DT binding patches. Otherwise I can push patch 3 through drm-misc.
> > > > >
> > > >
> > > > Not sure if I can really take the DRM bindings patch through soc.
> > > >
> > > > I will take the devicetree ones exactly right now, even though it's going to
> > > > give warnings.
> > >
> > > Apologies for missing this, but the first DT patch depends on the clk DT
> > > bindings patch for the clk ID macros. This is causing build errors in
> > > linux-next right now.
> > >
> > > Not sure how we can fix this right now.
> > >
> > > Brian, would it be possible for you to split out that patch into a
> > > separate immutable branch for Angelo to merge?
>
> Yes, I can split things out and make an immutable branch this morning.
> But it sounds too late for that.
>
> > >
> > > Otherwise Angelo might need to drop the DT patches until the next cycle.
> >
> > Yeah, that's so bad.
> > I'd be happy to be able to resolve this, but it's too late on my side.
> >
> > I should've checked the DT patches more carefully, my bad: I got a bit too excited
> > to finally see this PowerVR stuff working on MT8173 and going upstream.
> >
> > Sadly, I have to drop the devicetree patches :-(
>
> Chen-Yu: Could Angelo add an Acked-by to the three patches, and then I send
> Stephen an additional pull with just those patches? Do you think he'd
> pull that?

(replying from my @kernel.org address again because I don't feel like
 pulling out my work laptop.)

I think the question is whether the soc & dt maintainers would be bothered
by it or not.

No need to sweat over it though. It's not like the GPU driver is production
ready anyway. We can just merge the DT patches in the next cycle. :)


ChenYu