[PATCH v2 0/9] arm64: dts: imx95: Add support for Mali G310 GPU

[PATCH v2 0/9] arm64: dts: imx95: Add support for Mali G310 GPU

[Marek Vasut]

The instance of the GPU populated in i.MX95 is the G310.
Add support for the GPUMIX reset via simple-reset driver,
add reset and multiple power domains support into panthor
GPU driver, add iMX95 GPU support into panthor driver and
describe the iMX95 GPU in imx95.dtsi DT.

Marek Vasut (9):
  dt-bindings: reset: imx95-gpu-blk-ctrl: Document Freescale i.MX95 GPU
    reset
  reset: simple: Add support for Freescale i.MX95 GPU reset
  dt-bindings: gpu: mali-valhall-csf: Document optional reset
  drm/panthor: Implement optional reset
  drm/panthor: Implement support for multiple power domains
  drm/panthor: Reset GPU after L2 cache power off
  dt-bindings: gpu: mali-valhall-csf: Document i.MX95 support
  drm/panthor: Add i.MX95 support
  arm64: dts: imx95: Describe Mali G310 GPU

 .../bindings/gpu/arm,mali-valhall-csf.yaml    | 12 +++
 .../reset/nxp,imx95-gpu-blk-ctrl.yaml         | 49 ++++++++++++
 arch/arm64/boot/dts/freescale/imx95.dtsi      | 58 ++++++++++++++
 drivers/gpu/drm/panthor/panthor_device.c      | 75 +++++++++++++++++++
 drivers/gpu/drm/panthor/panthor_device.h      |  8 ++
 drivers/gpu/drm/panthor/panthor_drv.c         |  1 +
 drivers/gpu/drm/panthor/panthor_gpu.c         | 12 +--
 drivers/reset/Kconfig                         |  8 ++
 drivers/reset/reset-simple.c                  |  9 +++
 9 files changed, 227 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/reset/nxp,imx95-gpu-blk-ctrl.yaml

---
Cc: Boris Brezillon <boris.brezillon@collabora.com>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Sebastian Reichel <sre@kernel.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Steven Price <steven.price@arm.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: imx@lists.linux.dev
Cc: linux-arm-kernel@lists.infradead.org

-- 
2.47.2

[PATCH v2 1/9] dt-bindings: reset: imx95-gpu-blk-ctrl: Document Freescale i.MX95 GPU reset

[Marek Vasut]

The instance of the GPU populated in Freescale i.MX95 does require
release from reset by writing into a single GPUMIX block controller
GPURESET register bit 0. Document support for this reset register.

Signed-off-by: Marek Vasut <marex@denx.de>
---
Cc: Boris Brezillon <boris.brezillon@collabora.com>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Sebastian Reichel <sre@kernel.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Steven Price <steven.price@arm.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: imx@lists.linux.dev
Cc: linux-arm-kernel@lists.infradead.org
---
V2: - Fix dt_binding_check errors in example, temporarily use fixed
      numbers to refer to IMX95_CLK_GPUAPB clock and IMX95_PD_GPU
      power-domain
    - Drop trailing pipe after description:
    - Drop leading dash before const in compatible:
    - Switch from fsl, to nxp, vendor prefix
---
 .../reset/nxp,imx95-gpu-blk-ctrl.yaml         | 49 +++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/reset/nxp,imx95-gpu-blk-ctrl.yaml

diff --git a/Documentation/devicetree/bindings/reset/nxp,imx95-gpu-blk-ctrl.yaml b/Documentation/devicetree/bindings/reset/nxp,imx95-gpu-blk-ctrl.yaml
new file mode 100644
index 0000000000000..ca841db20d35b
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/nxp,imx95-gpu-blk-ctrl.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reset/nxp,imx95-gpu-blk-ctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX95 GPU Block Controller
+
+maintainers:
+  - Marek Vasut <marex@denx.de>
+
+description:
+  This reset controller is a block of ad-hoc debug registers, one of
+  which is a single-bit GPU reset.
+
+properties:
+  compatible:
+    const: nxp,imx95-gpu-blk-ctrl
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+  power-domains:
+    maxItems: 1
+
+  '#reset-cells':
+    const: 1
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - power-domains
+  - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+  - |
+    reset-controller@4d810000 {
+        compatible = "nxp,imx95-gpu-blk-ctrl";
+        reg = <0x4d810000 0xc>;
+        clocks = <&clk 83>;
+        power-domains = <&scmi_devpd 14>;
+        #reset-cells = <1>;
+    };
-- 
2.47.2

Re: [PATCH v2 1/9] dt-bindings: reset: imx95-gpu-blk-ctrl: Document Freescale i.MX95 GPU reset

[Rob Herring (Arm)]

On Fri, 21 Mar 2025 21:05:51 +0100, Marek Vasut wrote:
> The instance of the GPU populated in Freescale i.MX95 does require
> release from reset by writing into a single GPUMIX block controller
> GPURESET register bit 0. Document support for this reset register.
> 
> Signed-off-by: Marek Vasut <marex@denx.de>
> ---
> Cc: Boris Brezillon <boris.brezillon@collabora.com>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: David Airlie <airlied@gmail.com>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Liviu Dudau <liviu.dudau@arm.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Sebastian Reichel <sre@kernel.org>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Simona Vetter <simona@ffwll.ch>
> Cc: Steven Price <steven.price@arm.com>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: devicetree@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: imx@lists.linux.dev
> Cc: linux-arm-kernel@lists.infradead.org
> ---
> V2: - Fix dt_binding_check errors in example, temporarily use fixed
>       numbers to refer to IMX95_CLK_GPUAPB clock and IMX95_PD_GPU
>       power-domain
>     - Drop trailing pipe after description:
>     - Drop leading dash before const in compatible:
>     - Switch from fsl, to nxp, vendor prefix
> ---
>  .../reset/nxp,imx95-gpu-blk-ctrl.yaml         | 49 +++++++++++++++++++
>  1 file changed, 49 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/reset/nxp,imx95-gpu-blk-ctrl.yaml
> 

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>

[PATCH v2 2/9] reset: simple: Add support for Freescale i.MX95 GPU reset

[Marek Vasut]

The instance of the GPU populated in Freescale i.MX95 does require
release from reset by writing into a single GPUMIX block controller
GPURESET register bit 0. Implement support for this reset register.

Signed-off-by: Marek Vasut <marex@denx.de>
---
Cc: Boris Brezillon <boris.brezillon@collabora.com>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Sebastian Reichel <sre@kernel.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Steven Price <steven.price@arm.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: imx@lists.linux.dev
Cc: linux-arm-kernel@lists.infradead.org
---
V2: - Set nr_resets=1 to limit the amount of resets to single bit
    - Switch from fsl, to nxp, vendor prefix
    - Add RESET_IMX95_GPU Kconfig symbol to select this reset driver
      on MX9
---
 drivers/reset/Kconfig        | 8 ++++++++
 drivers/reset/reset-simple.c | 9 +++++++++
 2 files changed, 17 insertions(+)

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 99f6f9784e686..0b48e76fd0aab 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -249,12 +249,20 @@ config RESET_SIMPLE
 	   - Altera SoCFPGAs
 	   - ASPEED BMC SoCs
 	   - Bitmain BM1880 SoC
+	   - NXP i.MX95 GPU
 	   - Realtek SoCs
 	   - RCC reset controller in STM32 MCUs
 	   - Allwinner SoCs
 	   - SiFive FU740 SoCs
 	   - Sophgo SoCs
 
+config RESET_IMX95_GPU
+	bool "NXP i.MX95 GPU Reset Driver" if COMPILE_TEST && !SOC_IMX9
+	default SOC_IMX9
+	select RESET_SIMPLE
+	help
+	  This enables the reset driver for i.MX95 GPU.
+
 config RESET_SOCFPGA
 	bool "SoCFPGA Reset Driver" if COMPILE_TEST && (!ARM || !ARCH_INTEL_SOCFPGA)
 	default ARM && ARCH_INTEL_SOCFPGA
diff --git a/drivers/reset/reset-simple.c b/drivers/reset/reset-simple.c
index 2760678398308..64aeda8f76b75 100644
--- a/drivers/reset/reset-simple.c
+++ b/drivers/reset/reset-simple.c
@@ -133,9 +133,18 @@ static const struct reset_simple_devdata reset_simple_active_low = {
 	.status_active_low = true,
 };
 
+static const struct reset_simple_devdata reset_simple_fsl_imx95_gpu_blk_ctrl = {
+	.reg_offset = 0x8,
+	.active_low = true,
+	.nr_resets = 1,
+	.status_active_low = true,
+};
+
 static const struct of_device_id reset_simple_dt_ids[] = {
 	{ .compatible = "altr,stratix10-rst-mgr",
 		.data = &reset_simple_socfpga },
+	{ .compatible = "nxp,imx95-gpu-blk-ctrl",
+		.data = &reset_simple_fsl_imx95_gpu_blk_ctrl },
 	{ .compatible = "st,stm32-rcc", },
 	{ .compatible = "allwinner,sun6i-a31-clock-reset",
 		.data = &reset_simple_active_low },
-- 
2.47.2

[PATCH v2 3/9] dt-bindings: gpu: mali-valhall-csf: Document optional reset

[Marek Vasut]

The instance of the GPU populated in Freescale i.MX95 does require
release from reset by writing into a single GPUMIX block controller
GPURESET register bit 0. Document support for one optional reset.

Acked-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Marek Vasut <marex@denx.de>
---
Cc: Boris Brezillon <boris.brezillon@collabora.com>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Sebastian Reichel <sre@kernel.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Steven Price <steven.price@arm.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: imx@lists.linux.dev
Cc: linux-arm-kernel@lists.infradead.org
---
V2: - Add RB from Frank
    - Add AB from Rob
---
 .../devicetree/bindings/gpu/arm,mali-valhall-csf.yaml          | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
index a5b4e00217587..0efa06822a543 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
@@ -61,6 +61,9 @@ properties:
     minItems: 1
     maxItems: 5
 
+  resets:
+    maxItems: 1
+
   sram-supply: true
 
   "#cooling-cells":
-- 
2.47.2

Re: [PATCH v2 3/9] dt-bindings: gpu: mali-valhall-csf: Document optional reset

[Liviu Dudau]

On Fri, Mar 21, 2025 at 09:05:53PM +0100, Marek Vasut wrote:
> The instance of the GPU populated in Freescale i.MX95 does require
> release from reset by writing into a single GPUMIX block controller
> GPURESET register bit 0. Document support for one optional reset.
> 
> Acked-by: Rob Herring (Arm) <robh@kernel.org>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Signed-off-by: Marek Vasut <marex@denx.de>

Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>

Best regards,
Liviu

> ---
> Cc: Boris Brezillon <boris.brezillon@collabora.com>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: David Airlie <airlied@gmail.com>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Liviu Dudau <liviu.dudau@arm.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Sebastian Reichel <sre@kernel.org>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Simona Vetter <simona@ffwll.ch>
> Cc: Steven Price <steven.price@arm.com>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: devicetree@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: imx@lists.linux.dev
> Cc: linux-arm-kernel@lists.infradead.org
> ---
> V2: - Add RB from Frank
>     - Add AB from Rob
> ---
>  .../devicetree/bindings/gpu/arm,mali-valhall-csf.yaml          | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
> index a5b4e00217587..0efa06822a543 100644
> --- a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
> @@ -61,6 +61,9 @@ properties:
>      minItems: 1
>      maxItems: 5
>  
> +  resets:
> +    maxItems: 1
> +
>    sram-supply: true
>  
>    "#cooling-cells":
> -- 
> 2.47.2
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

[PATCH v2 4/9] drm/panthor: Implement optional reset

[Marek Vasut]

The instance of the GPU populated in Freescale i.MX95 does require
release from reset by writing into a single GPUMIX block controller
GPURESET register bit 0. Implement support for one optional reset.

Signed-off-by: Marek Vasut <marex@denx.de>
---
Cc: Boris Brezillon <boris.brezillon@collabora.com>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Sebastian Reichel <sre@kernel.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Steven Price <steven.price@arm.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: imx@lists.linux.dev
Cc: linux-arm-kernel@lists.infradead.org
---
V2: Drop the select RESET_SIMPLE from Kconfig
---
 drivers/gpu/drm/panthor/panthor_device.c | 23 +++++++++++++++++++++++
 drivers/gpu/drm/panthor/panthor_device.h |  3 +++
 2 files changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/panthor/panthor_device.c b/drivers/gpu/drm/panthor/panthor_device.c
index a9da1d1eeb707..51ee9cae94504 100644
--- a/drivers/gpu/drm/panthor/panthor_device.c
+++ b/drivers/gpu/drm/panthor/panthor_device.c
@@ -64,6 +64,17 @@ static int panthor_clk_init(struct panthor_device *ptdev)
 	return 0;
 }
 
+static int panthor_reset_init(struct panthor_device *ptdev)
+{
+	ptdev->resets = devm_reset_control_get_optional_exclusive_deasserted(ptdev->base.dev, NULL);
+	if (IS_ERR(ptdev->resets))
+		return dev_err_probe(ptdev->base.dev,
+				     PTR_ERR(ptdev->resets),
+				     "get reset failed");
+
+	return 0;
+}
+
 void panthor_device_unplug(struct panthor_device *ptdev)
 {
 	/* This function can be called from two different path: the reset work
@@ -217,6 +228,10 @@ int panthor_device_init(struct panthor_device *ptdev)
 	if (ret)
 		return ret;
 
+	ret = panthor_reset_init(ptdev);
+	if (ret)
+		return ret;
+
 	ret = panthor_devfreq_init(ptdev);
 	if (ret)
 		return ret;
@@ -470,6 +485,10 @@ int panthor_device_resume(struct device *dev)
 	if (ret)
 		goto err_disable_stacks_clk;
 
+	ret = reset_control_deassert(ptdev->resets);
+	if (ret)
+		goto err_disable_coregroup_clk;
+
 	panthor_devfreq_resume(ptdev);
 
 	if (panthor_device_is_initialized(ptdev) &&
@@ -512,6 +531,9 @@ int panthor_device_resume(struct device *dev)
 
 err_suspend_devfreq:
 	panthor_devfreq_suspend(ptdev);
+	reset_control_assert(ptdev->resets);
+
+err_disable_coregroup_clk:
 	clk_disable_unprepare(ptdev->clks.coregroup);
 
 err_disable_stacks_clk:
@@ -563,6 +585,7 @@ int panthor_device_suspend(struct device *dev)
 
 	panthor_devfreq_suspend(ptdev);
 
+	reset_control_assert(ptdev->resets);
 	clk_disable_unprepare(ptdev->clks.coregroup);
 	clk_disable_unprepare(ptdev->clks.stacks);
 	clk_disable_unprepare(ptdev->clks.core);
diff --git a/drivers/gpu/drm/panthor/panthor_device.h b/drivers/gpu/drm/panthor/panthor_device.h
index da6574021664b..fea3a05778e2e 100644
--- a/drivers/gpu/drm/panthor/panthor_device.h
+++ b/drivers/gpu/drm/panthor/panthor_device.h
@@ -111,6 +111,9 @@ struct panthor_device {
 		struct clk *coregroup;
 	} clks;
 
+	/** @resets: GPU reset. */
+	struct reset_control *resets;
+
 	/** @coherent: True if the CPU/GPU are memory coherent. */
 	bool coherent;
 
-- 
2.47.2

Re: [PATCH v2 4/9] drm/panthor: Implement optional reset

[Boris Brezillon]

On Fri, 21 Mar 2025 21:05:54 +0100
Marek Vasut <marex@denx.de> wrote:

> The instance of the GPU populated in Freescale i.MX95 does require
> release from reset by writing into a single GPUMIX block controller
> GPURESET register bit 0. Implement support for one optional reset.
> 
> Signed-off-by: Marek Vasut <marex@denx.de>
> ---
> Cc: Boris Brezillon <boris.brezillon@collabora.com>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: David Airlie <airlied@gmail.com>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Liviu Dudau <liviu.dudau@arm.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Sebastian Reichel <sre@kernel.org>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Simona Vetter <simona@ffwll.ch>
> Cc: Steven Price <steven.price@arm.com>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: devicetree@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: imx@lists.linux.dev
> Cc: linux-arm-kernel@lists.infradead.org
> ---
> V2: Drop the select RESET_SIMPLE from Kconfig
> ---
>  drivers/gpu/drm/panthor/panthor_device.c | 23 +++++++++++++++++++++++
>  drivers/gpu/drm/panthor/panthor_device.h |  3 +++
>  2 files changed, 26 insertions(+)
> 
> diff --git a/drivers/gpu/drm/panthor/panthor_device.c b/drivers/gpu/drm/panthor/panthor_device.c
> index a9da1d1eeb707..51ee9cae94504 100644
> --- a/drivers/gpu/drm/panthor/panthor_device.c
> +++ b/drivers/gpu/drm/panthor/panthor_device.c
> @@ -64,6 +64,17 @@ static int panthor_clk_init(struct panthor_device *ptdev)
>  	return 0;
>  }
>  
> +static int panthor_reset_init(struct panthor_device *ptdev)
> +{
> +	ptdev->resets = devm_reset_control_get_optional_exclusive_deasserted(ptdev->base.dev, NULL);
> +	if (IS_ERR(ptdev->resets))
> +		return dev_err_probe(ptdev->base.dev,
> +				     PTR_ERR(ptdev->resets),
> +				     "get reset failed");
> +
> +	return 0;
> +}
> +
>  void panthor_device_unplug(struct panthor_device *ptdev)
>  {
>  	/* This function can be called from two different path: the reset work
> @@ -217,6 +228,10 @@ int panthor_device_init(struct panthor_device *ptdev)
>  	if (ret)
>  		return ret;
>  
> +	ret = panthor_reset_init(ptdev);
> +	if (ret)
> +		return ret;
> +
>  	ret = panthor_devfreq_init(ptdev);
>  	if (ret)
>  		return ret;
> @@ -470,6 +485,10 @@ int panthor_device_resume(struct device *dev)
>  	if (ret)
>  		goto err_disable_stacks_clk;
>  
> +	ret = reset_control_deassert(ptdev->resets);
> +	if (ret)
> +		goto err_disable_coregroup_clk;
> +
>  	panthor_devfreq_resume(ptdev);
>  
>  	if (panthor_device_is_initialized(ptdev) &&
> @@ -512,6 +531,9 @@ int panthor_device_resume(struct device *dev)
>  
>  err_suspend_devfreq:
>  	panthor_devfreq_suspend(ptdev);
> +	reset_control_assert(ptdev->resets);
> +
> +err_disable_coregroup_clk:
>  	clk_disable_unprepare(ptdev->clks.coregroup);
>  
>  err_disable_stacks_clk:
> @@ -563,6 +585,7 @@ int panthor_device_suspend(struct device *dev)
>  
>  	panthor_devfreq_suspend(ptdev);
>  
> +	reset_control_assert(ptdev->resets);

Hm, that might be the cause of the fast reset issue (which is a fast
resume more than a fast reset BTW): if you re-assert the reset line on
runtime suspend, I guess this causes a full GPU reset, and the MCU ends
up in a state where it needs a slow reset (all data sections reset to
their initial state). Can you try to move the reset_control_[de]assert
to the unplug/init functions?

>  	clk_disable_unprepare(ptdev->clks.coregroup);
>  	clk_disable_unprepare(ptdev->clks.stacks);
>  	clk_disable_unprepare(ptdev->clks.core);
> diff --git a/drivers/gpu/drm/panthor/panthor_device.h b/drivers/gpu/drm/panthor/panthor_device.h
> index da6574021664b..fea3a05778e2e 100644
> --- a/drivers/gpu/drm/panthor/panthor_device.h
> +++ b/drivers/gpu/drm/panthor/panthor_device.h
> @@ -111,6 +111,9 @@ struct panthor_device {
>  		struct clk *coregroup;
>  	} clks;
>  
> +	/** @resets: GPU reset. */
> +	struct reset_control *resets;
> +
>  	/** @coherent: True if the CPU/GPU are memory coherent. */
>  	bool coherent;
>  

Re: [PATCH v2 4/9] drm/panthor: Implement optional reset

[Marek Vasut]

On 3/24/25 9:43 AM, Boris Brezillon wrote:

[...]

>> @@ -563,6 +585,7 @@ int panthor_device_suspend(struct device *dev)
>>   
>>   	panthor_devfreq_suspend(ptdev);
>>   
>> +	reset_control_assert(ptdev->resets);
> 
> Hm, that might be the cause of the fast reset issue (which is a fast
> resume more than a fast reset BTW): if you re-assert the reset line on
> runtime suspend, I guess this causes a full GPU reset, and the MCU ends
> up in a state where it needs a slow reset (all data sections reset to
> their initial state). Can you try to move the reset_control_[de]assert
> to the unplug/init functions?
The reset on the MX95 is not really a reset, it is clear-only 
set-never-again bit which goes only one way, the "unreset" way, so I 
don't think this has any impact. Also, I commented this out already and 
it made no difference. I will give the second part of our suggestion a 
try in the next few days though, and also try the updated downstream 
firmware blobs (sigh).

Re: [PATCH v2 4/9] drm/panthor: Implement optional reset

[Philipp Zabel]

On Mo, 2025-03-24 at 20:05 +0100, Marek Vasut wrote:
> On 3/24/25 9:43 AM, Boris Brezillon wrote:
> 
> [...]
> 
> > > @@ -563,6 +585,7 @@ int panthor_device_suspend(struct device *dev)
> > >   
> > >   	panthor_devfreq_suspend(ptdev);
> > >   
> > > +	reset_control_assert(ptdev->resets);
> > 
> > Hm, that might be the cause of the fast reset issue (which is a fast
> > resume more than a fast reset BTW): if you re-assert the reset line on
> > runtime suspend, I guess this causes a full GPU reset, and the MCU ends
> > up in a state where it needs a slow reset (all data sections reset to
> > their initial state). Can you try to move the reset_control_[de]assert
> > to the unplug/init functions?
> The reset on the MX95 is not really a reset, it is clear-only 
> set-never-again bit which goes only one way, the "unreset" way, so I 
> don't think this has any impact.

This sounds like the bit is initially set to 1 (reset asserted) and can
be cleared by writing 0 (once, to deassert the reset). But in the
reset-simple patch it looks to be the other way around (active_low =
true)?

If the reset control can't be asserted again on this hardware, it would
be better to have custom driver that doesn't implement the .assert()
callback at all.

regards
Philipp

Re: [PATCH v2 4/9] drm/panthor: Implement optional reset

[Marek Vasut]

On 3/25/25 3:12 PM, Philipp Zabel wrote:
> On Mo, 2025-03-24 at 20:05 +0100, Marek Vasut wrote:
>> On 3/24/25 9:43 AM, Boris Brezillon wrote:
>>
>> [...]
>>
>>>> @@ -563,6 +585,7 @@ int panthor_device_suspend(struct device *dev)
>>>>    
>>>>    	panthor_devfreq_suspend(ptdev);
>>>>    
>>>> +	reset_control_assert(ptdev->resets);
>>>
>>> Hm, that might be the cause of the fast reset issue (which is a fast
>>> resume more than a fast reset BTW): if you re-assert the reset line on
>>> runtime suspend, I guess this causes a full GPU reset, and the MCU ends
>>> up in a state where it needs a slow reset (all data sections reset to
>>> their initial state). Can you try to move the reset_control_[de]assert
>>> to the unplug/init functions?
>> The reset on the MX95 is not really a reset, it is clear-only
>> set-never-again bit which goes only one way, the "unreset" way, so I
>> don't think this has any impact.
> 
> This sounds like the bit is initially set to 1 (reset asserted) and can
> be cleared by writing 0 (once, to deassert the reset). But in the
> reset-simple patch it looks to be the other way around (active_low =
> true)?
> 
> If the reset control can't be asserted again on this hardware, it would
> be better to have custom driver that doesn't implement the .assert()
> callback at all.
Maybe the reset-simple driver can be extended with some mode of 
operation like this instead , to make it skip assert once deasserted , 
for specific reset controllers ?

Re: [PATCH v2 4/9] drm/panthor: Implement optional reset

[Philipp Zabel]

On Di, 2025-03-25 at 15:27 +0100, Marek Vasut wrote:
> On 3/25/25 3:12 PM, Philipp Zabel wrote:
> > On Mo, 2025-03-24 at 20:05 +0100, Marek Vasut wrote:
> > > On 3/24/25 9:43 AM, Boris Brezillon wrote:
> > > 
> > > [...]
> > > 
> > > > > @@ -563,6 +585,7 @@ int panthor_device_suspend(struct device *dev)
> > > > >    
> > > > >    	panthor_devfreq_suspend(ptdev);
> > > > >    
> > > > > +	reset_control_assert(ptdev->resets);
> > > > 
> > > > Hm, that might be the cause of the fast reset issue (which is a fast
> > > > resume more than a fast reset BTW): if you re-assert the reset line on
> > > > runtime suspend, I guess this causes a full GPU reset, and the MCU ends
> > > > up in a state where it needs a slow reset (all data sections reset to
> > > > their initial state). Can you try to move the reset_control_[de]assert
> > > > to the unplug/init functions?
> > > The reset on the MX95 is not really a reset, it is clear-only
> > > set-never-again bit which goes only one way, the "unreset" way, so I
> > > don't think this has any impact.
> > 
> > This sounds like the bit is initially set to 1 (reset asserted) and can
> > be cleared by writing 0 (once, to deassert the reset). But in the
> > reset-simple patch it looks to be the other way around (active_low =
> > true)?
> > 
> > If the reset control can't be asserted again on this hardware, it would
> > be better to have custom driver that doesn't implement the .assert()
> > callback at all.
> Maybe the reset-simple driver can be extended with some mode of 
> operation like this instead , to make it skip assert once deasserted , 
> for specific reset controllers ?

How about a second reset_control_ops struct without .assert, selected
in reset_simple_probe() by a new flag in reset_simple_devdata.

regards
Philipp

Re: [PATCH v2 4/9] drm/panthor: Implement optional reset

[Marek Vasut]

On 3/24/25 9:43 AM, Boris Brezillon wrote:

[...]

>> @@ -563,6 +585,7 @@ int panthor_device_suspend(struct device *dev)
>>   
>>   	panthor_devfreq_suspend(ptdev);
>>   
>> +	reset_control_assert(ptdev->resets);
> 
> Hm, that might be the cause of the fast reset issue (which is a fast
> resume more than a fast reset BTW): if you re-assert the reset line on
> runtime suspend, I guess this causes a full GPU reset, and the MCU ends
> up in a state where it needs a slow reset (all data sections reset to
> their initial state). Can you try to move the reset_control_[de]assert
> to the unplug/init functions?
Is it correct to assume , that if I remove all reset_control_assert() 
calls (and keep only the _deassert() calls), the slow resume problem 
should go away too ?

Re: [PATCH v2 4/9] drm/panthor: Implement optional reset

[Boris Brezillon]

On Tue, 25 Mar 2025 00:37:59 +0100
Marek Vasut <marex@denx.de> wrote:

> On 3/24/25 9:43 AM, Boris Brezillon wrote:
> 
> [...]
> 
> >> @@ -563,6 +585,7 @@ int panthor_device_suspend(struct device *dev)
> >>   
> >>   	panthor_devfreq_suspend(ptdev);
> >>   
> >> +	reset_control_assert(ptdev->resets);  
> > 
> > Hm, that might be the cause of the fast reset issue (which is a fast
> > resume more than a fast reset BTW): if you re-assert the reset line on
> > runtime suspend, I guess this causes a full GPU reset, and the MCU ends
> > up in a state where it needs a slow reset (all data sections reset to
> > their initial state). Can you try to move the reset_control_[de]assert
> > to the unplug/init functions?  
> Is it correct to assume , that if I remove all reset_control_assert() 
> calls (and keep only the _deassert() calls), the slow resume problem 
> should go away too ?

Yeah, dropping the _assert()s should do the trick.

Re: [PATCH v2 4/9] drm/panthor: Implement optional reset

[Marek Vasut]

On 3/25/25 8:43 AM, Boris Brezillon wrote:
> On Tue, 25 Mar 2025 00:37:59 +0100
> Marek Vasut <marex@denx.de> wrote:
> 
>> On 3/24/25 9:43 AM, Boris Brezillon wrote:
>>
>> [...]
>>
>>>> @@ -563,6 +585,7 @@ int panthor_device_suspend(struct device *dev)
>>>>    
>>>>    	panthor_devfreq_suspend(ptdev);
>>>>    
>>>> +	reset_control_assert(ptdev->resets);
>>>
>>> Hm, that might be the cause of the fast reset issue (which is a fast
>>> resume more than a fast reset BTW): if you re-assert the reset line on
>>> runtime suspend, I guess this causes a full GPU reset, and the MCU ends
>>> up in a state where it needs a slow reset (all data sections reset to
>>> their initial state). Can you try to move the reset_control_[de]assert
>>> to the unplug/init functions?
>> Is it correct to assume , that if I remove all reset_control_assert()
>> calls (and keep only the _deassert() calls), the slow resume problem
>> should go away too ?
> 
> Yeah, dropping the _assert()s should do the trick.
Hmmm, no, that does not help. I was hoping maybe NXP can chime in and 
suggest something too ?

Re: [PATCH v2 4/9] drm/panthor: Implement optional reset

[Boris Brezillon]

On Tue, 25 Mar 2025 14:50:32 +0100
Marek Vasut <marex@denx.de> wrote:

> On 3/25/25 8:43 AM, Boris Brezillon wrote:
> > On Tue, 25 Mar 2025 00:37:59 +0100
> > Marek Vasut <marex@denx.de> wrote:
> >   
> >> On 3/24/25 9:43 AM, Boris Brezillon wrote:
> >>
> >> [...]
> >>  
> >>>> @@ -563,6 +585,7 @@ int panthor_device_suspend(struct device *dev)
> >>>>    
> >>>>    	panthor_devfreq_suspend(ptdev);
> >>>>    
> >>>> +	reset_control_assert(ptdev->resets);  
> >>>
> >>> Hm, that might be the cause of the fast reset issue (which is a fast
> >>> resume more than a fast reset BTW): if you re-assert the reset line on
> >>> runtime suspend, I guess this causes a full GPU reset, and the MCU ends
> >>> up in a state where it needs a slow reset (all data sections reset to
> >>> their initial state). Can you try to move the reset_control_[de]assert
> >>> to the unplug/init functions?  
> >> Is it correct to assume , that if I remove all reset_control_assert()
> >> calls (and keep only the _deassert() calls), the slow resume problem
> >> should go away too ?  
> > 
> > Yeah, dropping the _assert()s should do the trick.  
> Hmmm, no, that does not help. I was hoping maybe NXP can chime in and 
> suggest something too ?

Can you try keep all the clks/regulators/power-domains/... on after
init, and see if the fast resume works with that. If it does,
re-introduce one resource at a time to find out which one causes the
MCU to lose its state.

Re: [PATCH v2 4/9] drm/panthor: Implement optional reset

[Marek Vasut]

On 3/25/25 3:35 PM, Boris Brezillon wrote:
> On Tue, 25 Mar 2025 14:50:32 +0100
> Marek Vasut <marex@denx.de> wrote:
> 
>> On 3/25/25 8:43 AM, Boris Brezillon wrote:
>>> On Tue, 25 Mar 2025 00:37:59 +0100
>>> Marek Vasut <marex@denx.de> wrote:
>>>    
>>>> On 3/24/25 9:43 AM, Boris Brezillon wrote:
>>>>
>>>> [...]
>>>>   
>>>>>> @@ -563,6 +585,7 @@ int panthor_device_suspend(struct device *dev)
>>>>>>     
>>>>>>     	panthor_devfreq_suspend(ptdev);
>>>>>>     
>>>>>> +	reset_control_assert(ptdev->resets);
>>>>>
>>>>> Hm, that might be the cause of the fast reset issue (which is a fast
>>>>> resume more than a fast reset BTW): if you re-assert the reset line on
>>>>> runtime suspend, I guess this causes a full GPU reset, and the MCU ends
>>>>> up in a state where it needs a slow reset (all data sections reset to
>>>>> their initial state). Can you try to move the reset_control_[de]assert
>>>>> to the unplug/init functions?
>>>> Is it correct to assume , that if I remove all reset_control_assert()
>>>> calls (and keep only the _deassert() calls), the slow resume problem
>>>> should go away too ?
>>>
>>> Yeah, dropping the _assert()s should do the trick.
>> Hmmm, no, that does not help. I was hoping maybe NXP can chime in and
>> suggest something too ?
> 
> Can you try keep all the clks/regulators/power-domains/... on after
> init, and see if the fast resume works with that. If it does,
> re-introduce one resource at a time to find out which one causes the
> MCU to lose its state.

I already tried that too . I spent quite a while until I reached that L2 
workaround in fact.

Re: [PATCH v2 4/9] drm/panthor: Implement optional reset

[Boris Brezillon]

On Tue, 25 Mar 2025 15:37:01 +0100
Marek Vasut <marex@denx.de> wrote:

> On 3/25/25 3:35 PM, Boris Brezillon wrote:
> > On Tue, 25 Mar 2025 14:50:32 +0100
> > Marek Vasut <marex@denx.de> wrote:
> >   
> >> On 3/25/25 8:43 AM, Boris Brezillon wrote:  
> >>> On Tue, 25 Mar 2025 00:37:59 +0100
> >>> Marek Vasut <marex@denx.de> wrote:
> >>>      
> >>>> On 3/24/25 9:43 AM, Boris Brezillon wrote:
> >>>>
> >>>> [...]
> >>>>     
> >>>>>> @@ -563,6 +585,7 @@ int panthor_device_suspend(struct device *dev)
> >>>>>>     
> >>>>>>     	panthor_devfreq_suspend(ptdev);
> >>>>>>     
> >>>>>> +	reset_control_assert(ptdev->resets);  
> >>>>>
> >>>>> Hm, that might be the cause of the fast reset issue (which is a fast
> >>>>> resume more than a fast reset BTW): if you re-assert the reset line on
> >>>>> runtime suspend, I guess this causes a full GPU reset, and the MCU ends
> >>>>> up in a state where it needs a slow reset (all data sections reset to
> >>>>> their initial state). Can you try to move the reset_control_[de]assert
> >>>>> to the unplug/init functions?  
> >>>> Is it correct to assume , that if I remove all reset_control_assert()
> >>>> calls (and keep only the _deassert() calls), the slow resume problem
> >>>> should go away too ?  
> >>>
> >>> Yeah, dropping the _assert()s should do the trick.  
> >> Hmmm, no, that does not help. I was hoping maybe NXP can chime in and
> >> suggest something too ?  
> > 
> > Can you try keep all the clks/regulators/power-domains/... on after
> > init, and see if the fast resume works with that. If it does,
> > re-introduce one resource at a time to find out which one causes the
> > MCU to lose its state.  
> 
> I already tried that too . I spent quite a while until I reached that L2 
> workaround in fact.

So, with your RPM suspend/resume being NOPs, it still doesn't work?
Unless the FW is doing something behind our back, I don't really see
why this would fail on your platform, but not on the rk3588. Are you
sure the power domains are kept on at all times. I'm asking, because if
you linked all the PDs, the on/off sequence is automatically handled by
the RPM core at suspend/resume time.

Re: [PATCH v2 4/9] drm/panthor: Implement optional reset

[Marek Vasut]

[-- Attachment #1: Type: text/plain, Size: 3776 bytes --]

On 3/25/25 3:52 PM, Boris Brezillon wrote:

Hello Boris,

sorry for the late reply.

>>>>>>> Hm, that might be the cause of the fast reset issue (which is a fast
>>>>>>> resume more than a fast reset BTW): if you re-assert the reset line on
>>>>>>> runtime suspend, I guess this causes a full GPU reset, and the MCU ends
>>>>>>> up in a state where it needs a slow reset (all data sections reset to
>>>>>>> their initial state). Can you try to move the reset_control_[de]assert
>>>>>>> to the unplug/init functions?
>>>>>> Is it correct to assume , that if I remove all reset_control_assert()
>>>>>> calls (and keep only the _deassert() calls), the slow resume problem
>>>>>> should go away too ?
>>>>>
>>>>> Yeah, dropping the _assert()s should do the trick.
>>>> Hmmm, no, that does not help. I was hoping maybe NXP can chime in and
>>>> suggest something too ?
>>>
>>> Can you try keep all the clks/regulators/power-domains/... on after
>>> init, and see if the fast resume works with that. If it does,
>>> re-introduce one resource at a time to find out which one causes the
>>> MCU to lose its state.
>>
>> I already tried that too . I spent quite a while until I reached that L2
>> workaround in fact.
> 
> So, with your RPM suspend/resume being NOPs, it still doesn't work?
> Unless the FW is doing something behind our back, I don't really see
> why this would fail on your platform, but not on the rk3588. Are you
> sure the power domains are kept on at all times. I'm asking, because if
> you linked all the PDs, the on/off sequence is automatically handled by
> the RPM core at suspend/resume time.

I revisited this now.

Can you please test the following patch (also attached) on one of your 
devices, and tell me what the status is at the end . The diff sets the 
GLB_HALT bit and then clears it again, which I suspect should first halt 
the GPU and (this is what I am unsure about) then again un-halt/resume 
the GPU ?

"
diff --git a/drivers/gpu/drm/panthor/panthor_fw.c 
b/drivers/gpu/drm/panthor/panthor_fw.c
index 9bf06e55eaeea..57c0d4fd29aa2 100644
--- a/drivers/gpu/drm/panthor/panthor_fw.c
+++ b/drivers/gpu/drm/panthor/panthor_fw.c
@@ -1087,8 +1087,16 @@ void panthor_fw_pre_reset(struct panthor_device 
*ptdev, bool on_hang)
  		struct panthor_fw_global_iface *glb_iface = 
panthor_fw_get_glb_iface(ptdev);
  		u32 status;

+pr_err("%s[%d] pre-halt status=%x\n", __func__, __LINE__, 
gpu_read(ptdev, MCU_STATUS));
+
  		panthor_fw_update_reqs(glb_iface, req, GLB_HALT, GLB_HALT);
  		gpu_write(ptdev, CSF_DOORBELL(CSF_GLB_DOORBELL_ID), 1);
+mdelay(100);
+pr_err("%s[%d] likely-halted status=%x\n", __func__, __LINE__, 
gpu_read(ptdev, MCU_STATUS));
+		panthor_fw_update_reqs(glb_iface, req, 0, GLB_HALT);
+mdelay(100);
+pr_err("%s[%d] likely-running ? status=%x\n", __func__, __LINE__, 
gpu_read(ptdev, MCU_STATUS));
+
  		if (!gpu_read_poll_timeout(ptdev, MCU_STATUS, status,
  					   status == MCU_STATUS_HALT, 10,
  					   100000)) {
"

In my case, the relevant output looks like this:

"
[    3.326805] panthor_fw_pre_reset[1090] pre-halt status=1
[    3.432151] panthor_fw_pre_reset[1095] likely-halted status=2
[    3.542179] panthor_fw_pre_reset[1098] likely-running ? status=2
"

That means, the GPU remains halted at the end, even if the "GLB_HALT" 
bit is cleared before the last print. The clearing of GLB_HALT is also 
what panthor_fw_post_reset() does.

I suspect the extra soft reset I did before "un-halted" the GPU and 
allowed it to proceed.

I wonder if there is some way to un-halt the GPU using some gpu_write() 
direct register access, is there ? Maybe the GPU remains halted because 
setting the GLB_HALT stops command stream processing, and the GPU never 
samples the clearing of GLB_HALT and therefore remains halted forever ?

[-- Attachment #2: pan.diff --]
[-- Type: text/x-patch, Size: 1014 bytes --]

diff --git a/drivers/gpu/drm/panthor/panthor_fw.c b/drivers/gpu/drm/panthor/panthor_fw.c
index 9bf06e55eaeea..57c0d4fd29aa2 100644
--- a/drivers/gpu/drm/panthor/panthor_fw.c
+++ b/drivers/gpu/drm/panthor/panthor_fw.c
@@ -1087,8 +1087,16 @@ void panthor_fw_pre_reset(struct panthor_device *ptdev, bool on_hang)
 		struct panthor_fw_global_iface *glb_iface = panthor_fw_get_glb_iface(ptdev);
 		u32 status;
 
+pr_err("%s[%d] pre-halt status=%x\n", __func__, __LINE__, gpu_read(ptdev, MCU_STATUS));
+
 		panthor_fw_update_reqs(glb_iface, req, GLB_HALT, GLB_HALT);
 		gpu_write(ptdev, CSF_DOORBELL(CSF_GLB_DOORBELL_ID), 1);
+mdelay(100);
+pr_err("%s[%d] likely-halted status=%x\n", __func__, __LINE__, gpu_read(ptdev, MCU_STATUS));
+		panthor_fw_update_reqs(glb_iface, req, 0, GLB_HALT);
+mdelay(100);
+pr_err("%s[%d] likely-running ? status=%x\n", __func__, __LINE__, gpu_read(ptdev, MCU_STATUS));
+
 		if (!gpu_read_poll_timeout(ptdev, MCU_STATUS, status,
 					   status == MCU_STATUS_HALT, 10,
 					   100000)) {

Re: [PATCH v2 4/9] drm/panthor: Implement optional reset

[Boris Brezillon]

Hello Marek,

On Wed, 3 Sep 2025 23:44:59 +0200
Marek Vasut <marek.vasut@mailbox.org> wrote:

> On 3/25/25 3:52 PM, Boris Brezillon wrote:
> 
> Hello Boris,
> 
> sorry for the late reply.
> 
> >>>>>>> Hm, that might be the cause of the fast reset issue (which is a fast
> >>>>>>> resume more than a fast reset BTW): if you re-assert the reset line on
> >>>>>>> runtime suspend, I guess this causes a full GPU reset, and the MCU ends
> >>>>>>> up in a state where it needs a slow reset (all data sections reset to
> >>>>>>> their initial state). Can you try to move the reset_control_[de]assert
> >>>>>>> to the unplug/init functions?  
> >>>>>> Is it correct to assume , that if I remove all reset_control_assert()
> >>>>>> calls (and keep only the _deassert() calls), the slow resume problem
> >>>>>> should go away too ?  
> >>>>>
> >>>>> Yeah, dropping the _assert()s should do the trick.  
> >>>> Hmmm, no, that does not help. I was hoping maybe NXP can chime in and
> >>>> suggest something too ?  
> >>>
> >>> Can you try keep all the clks/regulators/power-domains/... on after
> >>> init, and see if the fast resume works with that. If it does,
> >>> re-introduce one resource at a time to find out which one causes the
> >>> MCU to lose its state.  
> >>
> >> I already tried that too . I spent quite a while until I reached that L2
> >> workaround in fact.  
> > 
> > So, with your RPM suspend/resume being NOPs, it still doesn't work?
> > Unless the FW is doing something behind our back, I don't really see
> > why this would fail on your platform, but not on the rk3588. Are you
> > sure the power domains are kept on at all times. I'm asking, because if
> > you linked all the PDs, the on/off sequence is automatically handled by
> > the RPM core at suspend/resume time.  
> 
> I revisited this now.
> 
> Can you please test the following patch (also attached) on one of your 
> devices, and tell me what the status is at the end . The diff sets the 
> GLB_HALT bit and then clears it again, which I suspect should first halt 
> the GPU and (this is what I am unsure about) then again un-halt/resume 
> the GPU ?

It doesn't work like that. What you're describing is like executing
"shutdown" on your terminal and then typing "boot" on the keyboard
after your computer has been shut down.

> 
> "
> diff --git a/drivers/gpu/drm/panthor/panthor_fw.c 
> b/drivers/gpu/drm/panthor/panthor_fw.c
> index 9bf06e55eaeea..57c0d4fd29aa2 100644
> --- a/drivers/gpu/drm/panthor/panthor_fw.c
> +++ b/drivers/gpu/drm/panthor/panthor_fw.c
> @@ -1087,8 +1087,16 @@ void panthor_fw_pre_reset(struct panthor_device 
> *ptdev, bool on_hang)
>   		struct panthor_fw_global_iface *glb_iface = 
> panthor_fw_get_glb_iface(ptdev);
>   		u32 status;
> 
> +pr_err("%s[%d] pre-halt status=%x\n", __func__, __LINE__, 
> gpu_read(ptdev, MCU_STATUS));
> +
>   		panthor_fw_update_reqs(glb_iface, req, GLB_HALT, GLB_HALT);
>   		gpu_write(ptdev, CSF_DOORBELL(CSF_GLB_DOORBELL_ID), 1);
> +mdelay(100);
> +pr_err("%s[%d] likely-halted status=%x\n", __func__, __LINE__, 
> gpu_read(ptdev, MCU_STATUS));
> +		panthor_fw_update_reqs(glb_iface, req, 0, GLB_HALT);
> +mdelay(100);
> +pr_err("%s[%d] likely-running ? status=%x\n", __func__, __LINE__, 
> gpu_read(ptdev, MCU_STATUS));
> +
>   		if (!gpu_read_poll_timeout(ptdev, MCU_STATUS, status,
>   					   status == MCU_STATUS_HALT, 10,
>   					   100000)) {
> "
> 
> In my case, the relevant output looks like this:
> 
> "
> [    3.326805] panthor_fw_pre_reset[1090] pre-halt status=1
> [    3.432151] panthor_fw_pre_reset[1095] likely-halted status=2
> [    3.542179] panthor_fw_pre_reset[1098] likely-running ? status=2
> "
> 
> That means, the GPU remains halted at the end, even if the "GLB_HALT" 
> bit is cleared before the last print. The clearing of GLB_HALT is also 
> what panthor_fw_post_reset() does.

After the halt has been processed by the FW, the memory region where
you check the halt status again is inert, since the micro-controller
(MCU) supposed to update those bits is off at this point. The FW
interface is really just a shared memory region between the CPU and
MCU, nothing more.

> 
> I suspect the extra soft reset I did before "un-halted" the GPU and 
> allowed it to proceed.

Hm, not quite. I mean, you still need to explicitly boot the MCU after
a reset, which is what the write to MCU_CONTROL [1] does. What the
soft-reset does though, is reset all GPU blocks, including the MCU.
This means the MCU starts from a fresh state when you reach [1].

If I had to guess, I'd say something is messed up when the GPU is
halted, and you need a soft-reset to recover from that. Unfortunately,
I don't know enough about what your FW is doing to help. Maybe
Arm/Freescale could...

> 
> I wonder if there is some way to un-halt the GPU using some gpu_write() 
> direct register access, is there ?

That's MCU_CONTROL, yes. And it's done here [1] already.

> Maybe the GPU remains halted because 
> setting the GLB_HALT stops command stream processing, and the GPU never 
> samples the clearing of GLB_HALT and therefore remains halted forever ?

Exactly that, and that's expected.

Regards,

Boris


[1]https://elixir.bootlin.com/linux/v6.16.4/source/drivers/gpu/drm/panthor/panthor_fw.c#L1034

Re: [PATCH v2 4/9] drm/panthor: Implement optional reset

[Alexander Stein]

Hi,

Am Donnerstag, 4. September 2025, 08:22:24 CEST schrieb Boris Brezillon:
> On Wed, 3 Sep 2025 23:44:59 +0200
> Marek Vasut <marek.vasut@mailbox.org> wrote:
> 
> > On 3/25/25 3:52 PM, Boris Brezillon wrote:
> > 
> > Hello Boris,
> > 
> > sorry for the late reply.
> > 
> > >>>>>>> Hm, that might be the cause of the fast reset issue (which is a fast
> > >>>>>>> resume more than a fast reset BTW): if you re-assert the reset line on
> > >>>>>>> runtime suspend, I guess this causes a full GPU reset, and the MCU ends
> > >>>>>>> up in a state where it needs a slow reset (all data sections reset to
> > >>>>>>> their initial state). Can you try to move the reset_control_[de]assert
> > >>>>>>> to the unplug/init functions?  
> > >>>>>> Is it correct to assume , that if I remove all reset_control_assert()
> > >>>>>> calls (and keep only the _deassert() calls), the slow resume problem
> > >>>>>> should go away too ?  
> > >>>>>
> > >>>>> Yeah, dropping the _assert()s should do the trick.  
> > >>>> Hmmm, no, that does not help. I was hoping maybe NXP can chime in and
> > >>>> suggest something too ?  
> > >>>
> > >>> Can you try keep all the clks/regulators/power-domains/... on after
> > >>> init, and see if the fast resume works with that. If it does,
> > >>> re-introduce one resource at a time to find out which one causes the
> > >>> MCU to lose its state.  
> > >>
> > >> I already tried that too . I spent quite a while until I reached that L2
> > >> workaround in fact.  
> > > 
> > > So, with your RPM suspend/resume being NOPs, it still doesn't work?
> > > Unless the FW is doing something behind our back, I don't really see
> > > why this would fail on your platform, but not on the rk3588. Are you
> > > sure the power domains are kept on at all times. I'm asking, because if
> > > you linked all the PDs, the on/off sequence is automatically handled by
> > > the RPM core at suspend/resume time.  
> > 
> > I revisited this now.
> > 
> > Can you please test the following patch (also attached) on one of your 
> > devices, and tell me what the status is at the end . The diff sets the 
> > GLB_HALT bit and then clears it again, which I suspect should first halt 
> > the GPU and (this is what I am unsure about) then again un-halt/resume 
> > the GPU ?
> 
> It doesn't work like that. What you're describing is like executing
> "shutdown" on your terminal and then typing "boot" on the keyboard
> after your computer has been shut down.
> 
> > 
> > "
> > diff --git a/drivers/gpu/drm/panthor/panthor_fw.c 
> > b/drivers/gpu/drm/panthor/panthor_fw.c
> > index 9bf06e55eaeea..57c0d4fd29aa2 100644
> > --- a/drivers/gpu/drm/panthor/panthor_fw.c
> > +++ b/drivers/gpu/drm/panthor/panthor_fw.c
> > @@ -1087,8 +1087,16 @@ void panthor_fw_pre_reset(struct panthor_device 
> > *ptdev, bool on_hang)
> >   		struct panthor_fw_global_iface *glb_iface = 
> > panthor_fw_get_glb_iface(ptdev);
> >   		u32 status;
> > 
> > +pr_err("%s[%d] pre-halt status=%x\n", __func__, __LINE__, 
> > gpu_read(ptdev, MCU_STATUS));
> > +
> >   		panthor_fw_update_reqs(glb_iface, req, GLB_HALT, GLB_HALT);
> >   		gpu_write(ptdev, CSF_DOORBELL(CSF_GLB_DOORBELL_ID), 1);
> > +mdelay(100);
> > +pr_err("%s[%d] likely-halted status=%x\n", __func__, __LINE__, 
> > gpu_read(ptdev, MCU_STATUS));
> > +		panthor_fw_update_reqs(glb_iface, req, 0, GLB_HALT);
> > +mdelay(100);
> > +pr_err("%s[%d] likely-running ? status=%x\n", __func__, __LINE__, 
> > gpu_read(ptdev, MCU_STATUS));
> > +
> >   		if (!gpu_read_poll_timeout(ptdev, MCU_STATUS, status,
> >   					   status == MCU_STATUS_HALT, 10,
> >   					   100000)) {
> > "
> > 
> > In my case, the relevant output looks like this:
> > 
> > "
> > [    3.326805] panthor_fw_pre_reset[1090] pre-halt status=1
> > [    3.432151] panthor_fw_pre_reset[1095] likely-halted status=2
> > [    3.542179] panthor_fw_pre_reset[1098] likely-running ? status=2
> > "
> > 
> > That means, the GPU remains halted at the end, even if the "GLB_HALT" 
> > bit is cleared before the last print. The clearing of GLB_HALT is also 
> > what panthor_fw_post_reset() does.
> 
> After the halt has been processed by the FW, the memory region where
> you check the halt status again is inert, since the micro-controller
> (MCU) supposed to update those bits is off at this point. The FW
> interface is really just a shared memory region between the CPU and
> MCU, nothing more.
> 
> > 
> > I suspect the extra soft reset I did before "un-halted" the GPU and 
> > allowed it to proceed.
> 
> Hm, not quite. I mean, you still need to explicitly boot the MCU after
> a reset, which is what the write to MCU_CONTROL [1] does. What the
> soft-reset does though, is reset all GPU blocks, including the MCU.
> This means the MCU starts from a fresh state when you reach [1].
> 
> If I had to guess, I'd say something is messed up when the GPU is
> halted, and you need a soft-reset to recover from that. Unfortunately,
> I don't know enough about what your FW is doing to help. Maybe
> Arm/Freescale could...
> 
> > 
> > I wonder if there is some way to un-halt the GPU using some gpu_write() 
> > direct register access, is there ?
> 
> That's MCU_CONTROL, yes. And it's done here [1] already.
> 
> > Maybe the GPU remains halted because 
> > setting the GLB_HALT stops command stream processing, and the GPU never 
> > samples the clearing of GLB_HALT and therefore remains halted forever ?
> 
> Exactly that, and that's expected.

FYI: in a new release of system manager software (starting from lf-6.12.3-1.0.0),
the GPU reset is reasserted in SM software already [1] and access to GPU
block control has been removed from Cortex-A [2]. Starting from B0 step this
version is required AFAIK.

Best regards
Alexander

[1] https://github.com/nxp-imx/imx-sm/commit/2dcc0409ede82eef54857be50daa588b23b3ba7b
[2] https://github.com/nxp-imx/imx-sm/commit/a3e5da9ea51144f513ac3909fa151fa7df394100

-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/

Re: [PATCH v2 4/9] drm/panthor: Implement optional reset

[Marek Vasut]

On 9/4/25 8:36 AM, Alexander Stein wrote:

Hello Alexander,

>>> Maybe the GPU remains halted because
>>> setting the GLB_HALT stops command stream processing, and the GPU never
>>> samples the clearing of GLB_HALT and therefore remains halted forever ?
>>
>> Exactly that, and that's expected.
> 
> FYI: in a new release of system manager software (starting from lf-6.12.3-1.0.0),
> the GPU reset is reasserted in SM software already [1] and access to GPU
> block control has been removed from Cortex-A [2]. Starting from B0 step this
> version is required AFAIK.

I don't think the SM is involved in this, because if I do the following 
test, the MCU also fails to boot unless I do a reset:

"
diff --git a/drivers/gpu/drm/panthor/panthor_device.c 
b/drivers/gpu/drm/panthor/panthor_device.c
index d4d73eebca49d..fd81cd2654111 100644
--- a/drivers/gpu/drm/panthor/panthor_device.c
+++ b/drivers/gpu/drm/panthor/panthor_device.c
@@ -642,6 +642,18 @@ int panthor_device_suspend(struct device *dev)
  		panthor_fw_suspend(ptdev);
  		panthor_mmu_suspend(ptdev);
  		panthor_gpu_suspend(ptdev);
+
+
+panthor_gpu_soft_reset(ptdev); // needed, else panthor_fw_resume() 
below fails
+
+		panthor_gpu_resume(ptdev);
+		panthor_mmu_resume(ptdev);
+
+		ret = panthor_fw_resume(ptdev);
+		if (!ret)
+			return 0;
+
+
  		drm_dev_exit(cookie);
  	}

"

Re: [PATCH v2 4/9] drm/panthor: Implement optional reset

[Alexander Stein]

Hi,

Am Donnerstag, 4. September 2025, 15:52:38 CEST schrieb Marek Vasut:
> On 9/4/25 8:36 AM, Alexander Stein wrote:
> 
> Hello Alexander,
> 
> >>> Maybe the GPU remains halted because
> >>> setting the GLB_HALT stops command stream processing, and the GPU never
> >>> samples the clearing of GLB_HALT and therefore remains halted forever ?
> >>
> >> Exactly that, and that's expected.
> > 
> > FYI: in a new release of system manager software (starting from lf-6.12.3-1.0.0),
> > the GPU reset is reasserted in SM software already [1] and access to GPU
> > block control has been removed from Cortex-A [2]. Starting from B0 step this
> > version is required AFAIK.
> 
> I don't think the SM is involved in this, because if I do the following 
> test, the MCU also fails to boot unless I do a reset:

Is this some other reset than BLK_CTRL_GPUMIX? If so, it might be required.
Don't know much about internal details though.

Best regards
Alexander

> "
> diff --git a/drivers/gpu/drm/panthor/panthor_device.c 
> b/drivers/gpu/drm/panthor/panthor_device.c
> index d4d73eebca49d..fd81cd2654111 100644
> --- a/drivers/gpu/drm/panthor/panthor_device.c
> +++ b/drivers/gpu/drm/panthor/panthor_device.c
> @@ -642,6 +642,18 @@ int panthor_device_suspend(struct device *dev)
>   		panthor_fw_suspend(ptdev);
>   		panthor_mmu_suspend(ptdev);
>   		panthor_gpu_suspend(ptdev);
> +
> +
> +panthor_gpu_soft_reset(ptdev); // needed, else panthor_fw_resume() 
> below fails
> +
> +		panthor_gpu_resume(ptdev);
> +		panthor_mmu_resume(ptdev);
> +
> +		ret = panthor_fw_resume(ptdev);
> +		if (!ret)
> +			return 0;
> +
> +
>   		drm_dev_exit(cookie);
>   	}
> 
> "
> 


-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/

Re: [PATCH v2 4/9] drm/panthor: Implement optional reset

[Marek Vasut]

On 9/4/25 4:39 PM, Alexander Stein wrote:
> Hi,
> 
> Am Donnerstag, 4. September 2025, 15:52:38 CEST schrieb Marek Vasut:
>> On 9/4/25 8:36 AM, Alexander Stein wrote:
>>
>> Hello Alexander,
>>
>>>>> Maybe the GPU remains halted because
>>>>> setting the GLB_HALT stops command stream processing, and the GPU never
>>>>> samples the clearing of GLB_HALT and therefore remains halted forever ?
>>>>
>>>> Exactly that, and that's expected.
>>>
>>> FYI: in a new release of system manager software (starting from lf-6.12.3-1.0.0),
>>> the GPU reset is reasserted in SM software already [1] and access to GPU
>>> block control has been removed from Cortex-A [2]. Starting from B0 step this
>>> version is required AFAIK.
>>
>> I don't think the SM is involved in this, because if I do the following
>> test, the MCU also fails to boot unless I do a reset:
> 
> Is this some other reset than BLK_CTRL_GPUMIX? If so, it might be required.
> Don't know much about internal details though.
Yes

    296	/**
    297	 * panthor_gpu_soft_reset() - Issue a soft-reset
    298	 * @ptdev: Device.
    299	 *
    300	 * Return: 0 on success, a negative error code otherwise.
    301	 */
    302	int panthor_gpu_soft_reset(struct panthor_device *ptdev)
    303	{
    304		bool timedout = false;
    305		unsigned long flags;
    306	
    307		spin_lock_irqsave(&ptdev->gpu->reqs_lock, flags);
    308		if (!drm_WARN_ON(&ptdev->base,
    309				 ptdev->gpu->pending_reqs & GPU_IRQ_RESET_COMPLETED)) {
    310			ptdev->gpu->pending_reqs |= GPU_IRQ_RESET_COMPLETED;
    311			gpu_write(ptdev, GPU_INT_CLEAR, GPU_IRQ_RESET_COMPLETED);
    312			gpu_write(ptdev, GPU_CMD, GPU_SOFT_RESET);
    313		}
    314		spin_unlock_irqrestore(&ptdev->gpu->reqs_lock, flags);
    315	
    316		if (!wait_event_timeout(ptdev->gpu->reqs_acked,
    317					!(ptdev->gpu->pending_reqs & GPU_IRQ_RESET_COMPLETED),
    318					msecs_to_jiffies(100))) {
    319			spin_lock_irqsave(&ptdev->gpu->reqs_lock, flags);
    320			if ((ptdev->gpu->pending_reqs & GPU_IRQ_RESET_COMPLETED) != 0 &&
    321			    !(gpu_read(ptdev, GPU_INT_RAWSTAT) & GPU_IRQ_RESET_COMPLETED))
    322				timedout = true;
    323			else
    324				ptdev->gpu->pending_reqs &= ~GPU_IRQ_RESET_COMPLETED;
    325			spin_unlock_irqrestore(&ptdev->gpu->reqs_lock, flags);
    326		}
    327	
    328		if (timedout) {
    329			drm_err(&ptdev->base, "Soft reset timeout");
    330			return -ETIMEDOUT;
    331		}
    332	
    333		return 0;
    334	}

Re: [PATCH v2 4/9] drm/panthor: Implement optional reset

[Marek Vasut]

On 9/4/25 8:22 AM, Boris Brezillon wrote:
> Hello Marek,

Hello Boris,

>> Can you please test the following patch (also attached) on one of your
>> devices, and tell me what the status is at the end . The diff sets the
>> GLB_HALT bit and then clears it again, which I suspect should first halt
>> the GPU and (this is what I am unsure about) then again un-halt/resume
>> the GPU ?
> 
> It doesn't work like that. What you're describing is like executing
> "shutdown" on your terminal and then typing "boot" on the keyboard
> after your computer has been shut down.

That is what I thought , yes .

I think what I am looking for is the "power key" .

[...]

>> That means, the GPU remains halted at the end, even if the "GLB_HALT"
>> bit is cleared before the last print. The clearing of GLB_HALT is also
>> what panthor_fw_post_reset() does.
> 
> After the halt has been processed by the FW, the memory region where
> you check the halt status again is inert, since the micro-controller
> (MCU) supposed to update those bits is off at this point. The FW
> interface is really just a shared memory region between the CPU and
> MCU, nothing more.

Right.

>> I suspect the extra soft reset I did before "un-halted" the GPU and
>> allowed it to proceed.
> 
> Hm, not quite. I mean, you still need to explicitly boot the MCU after
> a reset, which is what the write to MCU_CONTROL [1] does. What the
> soft-reset does though, is reset all GPU blocks, including the MCU.
> This means the MCU starts from a fresh state when you reach [1].

I have a feeling the write to MCU_CONTROL does nothing in my case.

Is there some way to probe the MCU state before/after setting GLB_HALT, 
and also before/after the MCU_CONTROL write, using 
gpu_read()/gpu_write() register operations, to find out what is going on 
with the MCU at each point ?

Re: [PATCH v2 4/9] drm/panthor: Implement optional reset

[Boris Brezillon]

On Thu, 4 Sep 2025 15:49:31 +0200
Marek Vasut <marek.vasut@mailbox.org> wrote:

> >> I suspect the extra soft reset I did before "un-halted" the GPU and
> >> allowed it to proceed.  
> > 
> > Hm, not quite. I mean, you still need to explicitly boot the MCU after
> > a reset, which is what the write to MCU_CONTROL [1] does. What the
> > soft-reset does though, is reset all GPU blocks, including the MCU.
> > This means the MCU starts from a fresh state when you reach [1].  
> 
> I have a feeling the write to MCU_CONTROL does nothing in my case.

I believe it does, otherwise you wouldn't be able to kick the MCU
and get things working until the first runtime suspend happens. I gut
feeling is that there's something fishy in the FW or SoC integration
that causes the FW HALT request to put the MCU/GPU in a bad state
preventing further MCU_CONTROL(AUTO_START) from functioning correctly
after that point.

> 
> Is there some way to probe the MCU state before/after setting GLB_HALT, 
> and also before/after the MCU_CONTROL write, using 
> gpu_read()/gpu_write() register operations, to find out what is going on 
> with the MCU at each point ?

Yes, there's an MCU_STATUS register [1].

[1]https://elixir.bootlin.com/linux/v6.16.4/source/drivers/gpu/drm/panthor/panthor_fw.c#L1045

Re: [PATCH v2 4/9] drm/panthor: Implement optional reset

[Marek Vasut]

On 9/4/25 4:04 PM, Boris Brezillon wrote:

Hello Boris,

>>>> I suspect the extra soft reset I did before "un-halted" the GPU and
>>>> allowed it to proceed.
>>>
>>> Hm, not quite. I mean, you still need to explicitly boot the MCU after
>>> a reset, which is what the write to MCU_CONTROL [1] does. What the
>>> soft-reset does though, is reset all GPU blocks, including the MCU.
>>> This means the MCU starts from a fresh state when you reach [1].
>>
>> I have a feeling the write to MCU_CONTROL does nothing in my case.
> 
> I believe it does, otherwise you wouldn't be able to kick the MCU
> and get things working until the first runtime suspend happens. I gut
> feeling is that there's something fishy in the FW or SoC integration
> that causes the FW HALT request to put the MCU/GPU in a bad state
> preventing further MCU_CONTROL(AUTO_START) from functioning correctly
> after that point.

I wonder who at NXP could chime in ... Peng, do you know ?

>> Is there some way to probe the MCU state before/after setting GLB_HALT,
>> and also before/after the MCU_CONTROL write, using
>> gpu_read()/gpu_write() register operations, to find out what is going on
>> with the MCU at each point ?
> 
> Yes, there's an MCU_STATUS register [1].
Is that the only register I can use , or is there something more 
detailed ? This register only returns values 0..3 which is not very 
informative.

Re: [PATCH v2 4/9] drm/panthor: Implement optional reset

[Boris Brezillon]

On Thu, 4 Sep 2025 16:54:38 +0200
Marek Vasut <marek.vasut@mailbox.org> wrote:

> On 9/4/25 4:04 PM, Boris Brezillon wrote:
> 
> Hello Boris,
> 
> >>>> I suspect the extra soft reset I did before "un-halted" the GPU and
> >>>> allowed it to proceed.  
> >>>
> >>> Hm, not quite. I mean, you still need to explicitly boot the MCU after
> >>> a reset, which is what the write to MCU_CONTROL [1] does. What the
> >>> soft-reset does though, is reset all GPU blocks, including the MCU.
> >>> This means the MCU starts from a fresh state when you reach [1].  
> >>
> >> I have a feeling the write to MCU_CONTROL does nothing in my case.  
> > 
> > I believe it does, otherwise you wouldn't be able to kick the MCU
> > and get things working until the first runtime suspend happens. I gut
> > feeling is that there's something fishy in the FW or SoC integration
> > that causes the FW HALT request to put the MCU/GPU in a bad state
> > preventing further MCU_CONTROL(AUTO_START) from functioning correctly
> > after that point.  
> 
> I wonder who at NXP could chime in ... Peng, do you know ?
> 
> >> Is there some way to probe the MCU state before/after setting GLB_HALT,
> >> and also before/after the MCU_CONTROL write, using
> >> gpu_read()/gpu_write() register operations, to find out what is going on
> >> with the MCU at each point ?  
> > 
> > Yes, there's an MCU_STATUS register [1].  
> Is that the only register I can use , or is there something more 
> detailed ? This register only returns values 0..3 which is not very 
> informative.

Not that I'm aware.

Re: [PATCH v2 4/9] drm/panthor: Implement optional reset

[Marek Vasut]

On 9/4/25 5:20 PM, Boris Brezillon wrote:
> On Thu, 4 Sep 2025 16:54:38 +0200
> Marek Vasut <marek.vasut@mailbox.org> wrote:
> 
>> On 9/4/25 4:04 PM, Boris Brezillon wrote:
>>
>> Hello Boris,
>>
>>>>>> I suspect the extra soft reset I did before "un-halted" the GPU and
>>>>>> allowed it to proceed.
>>>>>
>>>>> Hm, not quite. I mean, you still need to explicitly boot the MCU after
>>>>> a reset, which is what the write to MCU_CONTROL [1] does. What the
>>>>> soft-reset does though, is reset all GPU blocks, including the MCU.
>>>>> This means the MCU starts from a fresh state when you reach [1].
>>>>
>>>> I have a feeling the write to MCU_CONTROL does nothing in my case.
>>>
>>> I believe it does, otherwise you wouldn't be able to kick the MCU
>>> and get things working until the first runtime suspend happens. I gut
>>> feeling is that there's something fishy in the FW or SoC integration
>>> that causes the FW HALT request to put the MCU/GPU in a bad state
>>> preventing further MCU_CONTROL(AUTO_START) from functioning correctly
>>> after that point.
>>
>> I wonder who at NXP could chime in ... Peng, do you know ?
>>
>>>> Is there some way to probe the MCU state before/after setting GLB_HALT,
>>>> and also before/after the MCU_CONTROL write, using
>>>> gpu_read()/gpu_write() register operations, to find out what is going on
>>>> with the MCU at each point ?
>>>
>>> Yes, there's an MCU_STATUS register [1].
>> Is that the only register I can use , or is there something more
>> detailed ? This register only returns values 0..3 which is not very
>> informative.
> 
> Not that I'm aware.

Hmmmmm ... is there any way we can progress with the MX95 upstreaming 
with full reset , as a hardware implementation workaround in the driver, 
or some such ?

[PATCH v2 5/9] drm/panthor: Implement support for multiple power domains

[Marek Vasut]

The driver code power domain binding to driver instances only works
for single power domain, in case there are multiple power domains,
it is necessary to explicitly attach via dev_pm_domain_attach*().
As DT bindings list support for up to 5 power domains, add support
for attaching them all. This is useful on Freescale i.MX95 which
does have two power domains.

Signed-off-by: Marek Vasut <marex@denx.de>
---
Cc: Boris Brezillon <boris.brezillon@collabora.com>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Sebastian Reichel <sre@kernel.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Steven Price <steven.price@arm.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: imx@lists.linux.dev
Cc: linux-arm-kernel@lists.infradead.org
---
V2: Exit from panthor_genpd_init() on any pm_domain_attach_by_id() failure
---
 drivers/gpu/drm/panthor/panthor_device.c | 52 ++++++++++++++++++++++++
 drivers/gpu/drm/panthor/panthor_device.h |  5 +++
 2 files changed, 57 insertions(+)

diff --git a/drivers/gpu/drm/panthor/panthor_device.c b/drivers/gpu/drm/panthor/panthor_device.c
index 51ee9cae94504..8aa79c6d157e1 100644
--- a/drivers/gpu/drm/panthor/panthor_device.c
+++ b/drivers/gpu/drm/panthor/panthor_device.c
@@ -75,6 +75,54 @@ static int panthor_reset_init(struct panthor_device *ptdev)
 	return 0;
 }
 
+/* Generic power domain handling code, see drivers/gpu/drm/tiny/simpledrm.c */
+static void panthor_detach_genpd(void *res)
+{
+	struct panthor_device *ptdev = res;
+	int i;
+
+	if (ptdev->pwr_dom_count <= 1)
+		return;
+
+	for (i = ptdev->pwr_dom_count - 1; i >= 0; i--)
+		dev_pm_domain_detach(ptdev->pwr_dom_devs[i], true);
+}
+
+static int panthor_genpd_init(struct panthor_device *ptdev)
+{
+	struct device *dev = ptdev->base.dev;
+	int i;
+
+	ptdev->pwr_dom_count = of_count_phandle_with_args(dev->of_node, "power-domains",
+							  "#power-domain-cells");
+	/*
+	 * Single power-domain devices are handled by driver core nothing to do
+	 * here. The same for device nodes without "power-domains" property.
+	 */
+	if (ptdev->pwr_dom_count <= 1)
+		return 0;
+
+	if (ptdev->pwr_dom_count > ARRAY_SIZE(ptdev->pwr_dom_devs)) {
+		drm_warn(&ptdev->base, "Too many power domains (%d) for this device\n",
+			 ptdev->pwr_dom_count);
+		return -EINVAL;
+	}
+
+	for (i = 0; i < ptdev->pwr_dom_count; i++) {
+		ptdev->pwr_dom_devs[i] = dev_pm_domain_attach_by_id(dev, i);
+		if (!IS_ERR(ptdev->pwr_dom_devs[i]))
+			continue;
+
+		/* Missing dependency, try again. */
+		panthor_detach_genpd(ptdev);
+		return dev_err_probe(ptdev->base.dev,
+				     PTR_ERR(ptdev->pwr_dom_devs[i]),
+				     "pm_domain_attach_by_id(%u) failed\n", i);
+	}
+
+	return devm_add_action_or_reset(dev, panthor_detach_genpd, ptdev);
+}
+
 void panthor_device_unplug(struct panthor_device *ptdev)
 {
 	/* This function can be called from two different path: the reset work
@@ -232,6 +280,10 @@ int panthor_device_init(struct panthor_device *ptdev)
 	if (ret)
 		return ret;
 
+	ret = panthor_genpd_init(ptdev);
+	if (ret)
+		return ret;
+
 	ret = panthor_devfreq_init(ptdev);
 	if (ret)
 		return ret;
diff --git a/drivers/gpu/drm/panthor/panthor_device.h b/drivers/gpu/drm/panthor/panthor_device.h
index fea3a05778e2e..7fb65447253e9 100644
--- a/drivers/gpu/drm/panthor/panthor_device.h
+++ b/drivers/gpu/drm/panthor/panthor_device.h
@@ -114,6 +114,11 @@ struct panthor_device {
 	/** @resets: GPU reset. */
 	struct reset_control *resets;
 
+	/** @pwr_dom_count: Power domain count */
+	int pwr_dom_count;
+	/** @pwr_dom_dev: Power domain devices */
+	struct device *pwr_dom_devs[5];
+
 	/** @coherent: True if the CPU/GPU are memory coherent. */
 	bool coherent;
 
-- 
2.47.2

Re: [PATCH v2 5/9] drm/panthor: Implement support for multiple power domains

[Steven Price]

On 21/03/2025 20:05, Marek Vasut wrote:
> The driver code power domain binding to driver instances only works
> for single power domain, in case there are multiple power domains,
> it is necessary to explicitly attach via dev_pm_domain_attach*().
> As DT bindings list support for up to 5 power domains, add support
> for attaching them all. This is useful on Freescale i.MX95 which
> does have two power domains.
> 
> Signed-off-by: Marek Vasut <marex@denx.de>
> ---
> Cc: Boris Brezillon <boris.brezillon@collabora.com>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: David Airlie <airlied@gmail.com>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Liviu Dudau <liviu.dudau@arm.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Sebastian Reichel <sre@kernel.org>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Simona Vetter <simona@ffwll.ch>
> Cc: Steven Price <steven.price@arm.com>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: devicetree@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: imx@lists.linux.dev
> Cc: linux-arm-kernel@lists.infradead.org
> ---
> V2: Exit from panthor_genpd_init() on any pm_domain_attach_by_id() failure
> ---
>  drivers/gpu/drm/panthor/panthor_device.c | 52 ++++++++++++++++++++++++
>  drivers/gpu/drm/panthor/panthor_device.h |  5 +++
>  2 files changed, 57 insertions(+)
> 
> diff --git a/drivers/gpu/drm/panthor/panthor_device.c b/drivers/gpu/drm/panthor/panthor_device.c
> index 51ee9cae94504..8aa79c6d157e1 100644
> --- a/drivers/gpu/drm/panthor/panthor_device.c
> +++ b/drivers/gpu/drm/panthor/panthor_device.c
> @@ -75,6 +75,54 @@ static int panthor_reset_init(struct panthor_device *ptdev)
>  	return 0;
>  }
>  
> +/* Generic power domain handling code, see drivers/gpu/drm/tiny/simpledrm.c */
> +static void panthor_detach_genpd(void *res)
> +{
> +	struct panthor_device *ptdev = res;
> +	int i;
> +
> +	if (ptdev->pwr_dom_count <= 1)
> +		return;
> +
> +	for (i = ptdev->pwr_dom_count - 1; i >= 0; i--)
> +		dev_pm_domain_detach(ptdev->pwr_dom_devs[i], true);
> +}
> +
> +static int panthor_genpd_init(struct panthor_device *ptdev)
> +{
> +	struct device *dev = ptdev->base.dev;
> +	int i;
> +
> +	ptdev->pwr_dom_count = of_count_phandle_with_args(dev->of_node, "power-domains",
> +							  "#power-domain-cells");
> +	/*
> +	 * Single power-domain devices are handled by driver core nothing to do
> +	 * here. The same for device nodes without "power-domains" property.
> +	 */
> +	if (ptdev->pwr_dom_count <= 1)
> +		return 0;
> +
> +	if (ptdev->pwr_dom_count > ARRAY_SIZE(ptdev->pwr_dom_devs)) {
> +		drm_warn(&ptdev->base, "Too many power domains (%d) for this device\n",
> +			 ptdev->pwr_dom_count);
> +		return -EINVAL;
> +	}
> +
> +	for (i = 0; i < ptdev->pwr_dom_count; i++) {
> +		ptdev->pwr_dom_devs[i] = dev_pm_domain_attach_by_id(dev, i);
> +		if (!IS_ERR(ptdev->pwr_dom_devs[i]))
> +			continue;
> +
> +		/* Missing dependency, try again. */
> +		panthor_detach_genpd(ptdev);

If ptdev->pwr_dom_devs[i] is assigned an error pointer, then the call in
panthor_detach_genpd() to dev_pm_domain_detach() is going to use that
error pointer. But AFAICT dev_pm_domain_detach() assumes the pointer is
valid. So this will break.

Steve

> +		return dev_err_probe(ptdev->base.dev,
> +				     PTR_ERR(ptdev->pwr_dom_devs[i]),
> +				     "pm_domain_attach_by_id(%u) failed\n", i);
> +	}
> +
> +	return devm_add_action_or_reset(dev, panthor_detach_genpd, ptdev);
> +}
> +
>  void panthor_device_unplug(struct panthor_device *ptdev)
>  {
>  	/* This function can be called from two different path: the reset work
> @@ -232,6 +280,10 @@ int panthor_device_init(struct panthor_device *ptdev)
>  	if (ret)
>  		return ret;
>  
> +	ret = panthor_genpd_init(ptdev);
> +	if (ret)
> +		return ret;
> +
>  	ret = panthor_devfreq_init(ptdev);
>  	if (ret)
>  		return ret;
> diff --git a/drivers/gpu/drm/panthor/panthor_device.h b/drivers/gpu/drm/panthor/panthor_device.h
> index fea3a05778e2e..7fb65447253e9 100644
> --- a/drivers/gpu/drm/panthor/panthor_device.h
> +++ b/drivers/gpu/drm/panthor/panthor_device.h
> @@ -114,6 +114,11 @@ struct panthor_device {
>  	/** @resets: GPU reset. */
>  	struct reset_control *resets;
>  
> +	/** @pwr_dom_count: Power domain count */
> +	int pwr_dom_count;
> +	/** @pwr_dom_dev: Power domain devices */
> +	struct device *pwr_dom_devs[5];
> +
>  	/** @coherent: True if the CPU/GPU are memory coherent. */
>  	bool coherent;
>  

[PATCH v2 6/9] drm/panthor: Reset GPU after L2 cache power off

[Marek Vasut]

This seems necessary on Freescale i.MX95 Mali G310 to reliably resume
from runtime PM suspend. Without this, if only the L2 is powered down
on RPM entry, the GPU gets stuck and does not indicate the firmware is
booted after RPM resume.

Signed-off-by: Marek Vasut <marex@denx.de>
---
Cc: Boris Brezillon <boris.brezillon@collabora.com>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Sebastian Reichel <sre@kernel.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Steven Price <steven.price@arm.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: imx@lists.linux.dev
Cc: linux-arm-kernel@lists.infradead.org
---
V2: No change
---
 drivers/gpu/drm/panthor/panthor_gpu.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/panthor/panthor_gpu.c b/drivers/gpu/drm/panthor/panthor_gpu.c
index 671049020afaa..0f07ef7d9aea7 100644
--- a/drivers/gpu/drm/panthor/panthor_gpu.c
+++ b/drivers/gpu/drm/panthor/panthor_gpu.c
@@ -470,11 +470,12 @@ int panthor_gpu_soft_reset(struct panthor_device *ptdev)
  */
 void panthor_gpu_suspend(struct panthor_device *ptdev)
 {
-	/* On a fast reset, simply power down the L2. */
-	if (!ptdev->reset.fast)
-		panthor_gpu_soft_reset(ptdev);
-	else
-		panthor_gpu_power_off(ptdev, L2, 1, 20000);
+	/*
+	 * Power off the L2 and soft reset the GPU, that makes
+	 * iMX95 Mali G310 resume without firmware boot timeout.
+	 */
+	panthor_gpu_power_off(ptdev, L2, 1, 20000);
+	panthor_gpu_soft_reset(ptdev);
 
 	panthor_gpu_irq_suspend(&ptdev->gpu->irq);
 }
-- 
2.47.2

[PATCH v2 7/9] dt-bindings: gpu: mali-valhall-csf: Document i.MX95 support

[Marek Vasut]

The instance of the GPU populated in Freescale i.MX95 is the
Mali G310, document support for this variant.

Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Marek Vasut <marex@denx.de>
---
Cc: Boris Brezillon <boris.brezillon@collabora.com>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Sebastian Reichel <sre@kernel.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Steven Price <steven.price@arm.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: imx@lists.linux.dev
Cc: linux-arm-kernel@lists.infradead.org
---
V2: - Add RB from Frank and Alexander
    - Make resets: mandatory on i.MX95
    - Switch from fsl, to nxp, vendor prefix
---
 .../devicetree/bindings/gpu/arm,mali-valhall-csf.yaml    | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
index 0efa06822a543..485609de54eac 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
@@ -18,6 +18,7 @@ properties:
     oneOf:
       - items:
           - enum:
+              - nxp,imx95-mali            # G310
               - rockchip,rk3588-mali
           - const: arm,mali-valhall-csf   # Mali Valhall GPU model/revision is fully discoverable
 
@@ -111,6 +112,14 @@ allOf:
         power-domains:
           maxItems: 1
         power-domain-names: false
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: nxp,imx95-mali
+    then:
+      required:
+        - resets
 
 examples:
   - |
-- 
2.47.2

Re: [PATCH v2 7/9] dt-bindings: gpu: mali-valhall-csf: Document i.MX95 support

[Rob Herring (Arm)]

On Fri, 21 Mar 2025 21:05:57 +0100, Marek Vasut wrote:
> The instance of the GPU populated in Freescale i.MX95 is the
> Mali G310, document support for this variant.
> 
> Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Signed-off-by: Marek Vasut <marex@denx.de>
> ---
> Cc: Boris Brezillon <boris.brezillon@collabora.com>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: David Airlie <airlied@gmail.com>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Liviu Dudau <liviu.dudau@arm.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Sebastian Reichel <sre@kernel.org>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Simona Vetter <simona@ffwll.ch>
> Cc: Steven Price <steven.price@arm.com>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: devicetree@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: imx@lists.linux.dev
> Cc: linux-arm-kernel@lists.infradead.org
> ---
> V2: - Add RB from Frank and Alexander
>     - Make resets: mandatory on i.MX95
>     - Switch from fsl, to nxp, vendor prefix
> ---
>  .../devicetree/bindings/gpu/arm,mali-valhall-csf.yaml    | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>

[PATCH v2 8/9] drm/panthor: Add i.MX95 support

[Marek Vasut]

The instance of the GPU populated in Freescale i.MX95 is the
Mali G310, add support for this variant.

Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Marek Vasut <marex@denx.de>
---
Cc: Boris Brezillon <boris.brezillon@collabora.com>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Sebastian Reichel <sre@kernel.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Steven Price <steven.price@arm.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: imx@lists.linux.dev
Cc: linux-arm-kernel@lists.infradead.org
---
V2: - Add RB from Frank
    - Switch from fsl, to nxp, vendor prefix
    - Fix up GPU_MODEL(g310, 0, 0) to GPU_MODEL(g310, 10, 4)
    - Remove code comments about MX95 and G310
---
 drivers/gpu/drm/panthor/panthor_drv.c | 1 +
 drivers/gpu/drm/panthor/panthor_gpu.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/panthor/panthor_drv.c b/drivers/gpu/drm/panthor/panthor_drv.c
index 06fe46e320738..299ec8bafdd17 100644
--- a/drivers/gpu/drm/panthor/panthor_drv.c
+++ b/drivers/gpu/drm/panthor/panthor_drv.c
@@ -1591,6 +1591,7 @@ static struct attribute *panthor_attrs[] = {
 ATTRIBUTE_GROUPS(panthor);
 
 static const struct of_device_id dt_match[] = {
+	{ .compatible = "nxp,imx95-mali" },
 	{ .compatible = "rockchip,rk3588-mali" },
 	{ .compatible = "arm,mali-valhall-csf" },
 	{}
diff --git a/drivers/gpu/drm/panthor/panthor_gpu.c b/drivers/gpu/drm/panthor/panthor_gpu.c
index 0f07ef7d9aea7..59fc1cacefcfe 100644
--- a/drivers/gpu/drm/panthor/panthor_gpu.c
+++ b/drivers/gpu/drm/panthor/panthor_gpu.c
@@ -67,6 +67,7 @@ struct panthor_model {
 }
 
 static const struct panthor_model gpu_models[] = {
+	GPU_MODEL(g310, 10, 4),
 	GPU_MODEL(g610, 10, 7),
 	{},
 };
-- 
2.47.2

[PATCH v2 9/9] arm64: dts: imx95: Describe Mali G310 GPU

[Marek Vasut]

The instance of the GPU populated in i.MX95 is the G310,
describe this GPU in the DT. Include description of the
GPUMIX block controller, which can be operated as a simple
reset. Include dummy GPU voltage regulator and OPP tables.

Signed-off-by: Marek Vasut <marex@denx.de>
---
Cc: Boris Brezillon <boris.brezillon@collabora.com>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Sebastian Reichel <sre@kernel.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Steven Price <steven.price@arm.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: imx@lists.linux.dev
Cc: linux-arm-kernel@lists.infradead.org
---
V2: - Drop regulator-{always,boot}-on from fixed-gpu-reg regulator
    - Keep the GPU and GPUMIX always enabled
    - Switch from fsl, to nxp, vendor prefix
    - Fix opp_table to opp-table
    - Describe IMX95_CLK_GPUAPB as coregroup clock
    - Sort interrupts by their names to match bindings
---
 arch/arm64/boot/dts/freescale/imx95.dtsi | 58 ++++++++++++++++++++++++
 1 file changed, 58 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi
index 9bb26b466a061..3acdbd7fd4eee 100644
--- a/arch/arm64/boot/dts/freescale/imx95.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
@@ -249,6 +249,35 @@ dummy: clock-dummy {
 		clock-output-names = "dummy";
 	};
 
+	gpu_fixed_reg: fixed-gpu-reg {
+		compatible = "regulator-fixed";
+		regulator-min-microvolt = <920000>;
+		regulator-max-microvolt = <920000>;
+		regulator-name = "vdd_gpu";
+	};
+
+	gpu_opp_table: opp-table {
+		compatible = "operating-points-v2";
+
+		opp-500000000 {
+			opp-hz = /bits/ 64 <500000000>;
+			opp-hz-real = /bits/ 64 <500000000>;
+			opp-microvolt = <920000>;
+		};
+
+		opp-800000000 {
+			opp-hz = /bits/ 64 <800000000>;
+			opp-hz-real = /bits/ 64 <800000000>;
+			opp-microvolt = <920000>;
+		};
+
+		opp-1000000000 {
+			opp-hz = /bits/ 64 <1000000000>;
+			opp-hz-real = /bits/ 64 <1000000000>;
+			opp-microvolt = <920000>;
+		};
+	};
+
 	clk_ext1: clock-ext1 {
 		compatible = "fixed-clock";
 		#clock-cells = <0>;
@@ -1890,6 +1919,35 @@ netc_emdio: mdio@0,0 {
 			};
 		};
 
+		gpu_blk_ctrl: reset-controller@4d810000 {
+			compatible = "nxp,imx95-gpu-blk-ctrl";
+			reg = <0x0 0x4d810000 0x0 0xc>;
+			#reset-cells = <1>;
+			clocks = <&scmi_clk IMX95_CLK_GPUAPB>;
+			assigned-clocks = <&scmi_clk IMX95_CLK_GPUAPB>;
+			assigned-clock-parents = <&scmi_clk IMX95_CLK_SYSPLL1_PFD1_DIV2>;
+			assigned-clock-rates = <133333333>;
+			power-domains = <&scmi_devpd IMX95_PD_GPU>;
+		};
+
+		gpu: gpu@4d900000 {
+			compatible = "nxp,imx95-mali", "arm,mali-valhall-csf";
+			reg = <0 0x4d900000 0 0x480000>;
+			clocks = <&scmi_clk IMX95_CLK_GPU>, <&scmi_clk IMX95_CLK_GPUAPB>;
+			clock-names = "core", "coregroup";
+			interrupts = <GIC_SPI 289 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 288 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "job", "mmu", "gpu";
+			mali-supply = <&gpu_fixed_reg>;
+			operating-points-v2 = <&gpu_opp_table>;
+			power-domains = <&scmi_devpd IMX95_PD_GPU>, <&scmi_perf IMX95_PERF_GPU>;
+			power-domain-names = "mix", "perf";
+			resets = <&gpu_blk_ctrl 0>;
+			#cooling-cells = <2>;
+			dynamic-power-coefficient = <1013>;
+		};
+
 		ddr-pmu@4e090dc0 {
 			compatible = "fsl,imx95-ddr-pmu", "fsl,imx93-ddr-pmu";
 			reg = <0x0 0x4e090dc0 0x0 0x200>;
-- 
2.47.2

Re: [PATCH v2 9/9] arm64: dts: imx95: Describe Mali G310 GPU

[Alexander Stein]

Am Freitag, 21. März 2025, 21:05:59 CET schrieb Marek Vasut:
> The instance of the GPU populated in i.MX95 is the G310,
> describe this GPU in the DT. Include description of the
> GPUMIX block controller, which can be operated as a simple
> reset. Include dummy GPU voltage regulator and OPP tables.
> 
> Signed-off-by: Marek Vasut <marex@denx.de>
> ---
> Cc: Boris Brezillon <boris.brezillon@collabora.com>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: David Airlie <airlied@gmail.com>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Liviu Dudau <liviu.dudau@arm.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Sebastian Reichel <sre@kernel.org>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Simona Vetter <simona@ffwll.ch>
> Cc: Steven Price <steven.price@arm.com>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: devicetree@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: imx@lists.linux.dev
> Cc: linux-arm-kernel@lists.infradead.org
> ---
> V2: - Drop regulator-{always,boot}-on from fixed-gpu-reg regulator
>     - Keep the GPU and GPUMIX always enabled
>     - Switch from fsl, to nxp, vendor prefix
>     - Fix opp_table to opp-table
>     - Describe IMX95_CLK_GPUAPB as coregroup clock
>     - Sort interrupts by their names to match bindings
> ---
>  arch/arm64/boot/dts/freescale/imx95.dtsi | 58 ++++++++++++++++++++++++
>  1 file changed, 58 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi
> index 9bb26b466a061..3acdbd7fd4eee 100644
> --- a/arch/arm64/boot/dts/freescale/imx95.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
> @@ -249,6 +249,35 @@ dummy: clock-dummy {
>  		clock-output-names = "dummy";
>  	};
>  
> +	gpu_fixed_reg: fixed-gpu-reg {
> +		compatible = "regulator-fixed";
> +		regulator-min-microvolt = <920000>;
> +		regulator-max-microvolt = <920000>;
> +		regulator-name = "vdd_gpu";
> +	};
> +
> +	gpu_opp_table: opp-table {
> +		compatible = "operating-points-v2";
> +
> +		opp-500000000 {
> +			opp-hz = /bits/ 64 <500000000>;
> +			opp-hz-real = /bits/ 64 <500000000>;
> +			opp-microvolt = <920000>;
> +		};
> +
> +		opp-800000000 {
> +			opp-hz = /bits/ 64 <800000000>;
> +			opp-hz-real = /bits/ 64 <800000000>;
> +			opp-microvolt = <920000>;
> +		};
> +
> +		opp-1000000000 {
> +			opp-hz = /bits/ 64 <1000000000>;
> +			opp-hz-real = /bits/ 64 <1000000000>;
> +			opp-microvolt = <920000>;
> +		};
> +	};
> +
>  	clk_ext1: clock-ext1 {
>  		compatible = "fixed-clock";
>  		#clock-cells = <0>;
> @@ -1890,6 +1919,35 @@ netc_emdio: mdio@0,0 {
>  			};
>  		};
>  
> +		gpu_blk_ctrl: reset-controller@4d810000 {
> +			compatible = "nxp,imx95-gpu-blk-ctrl";
> +			reg = <0x0 0x4d810000 0x0 0xc>;
> +			#reset-cells = <1>;
> +			clocks = <&scmi_clk IMX95_CLK_GPUAPB>;
> +			assigned-clocks = <&scmi_clk IMX95_CLK_GPUAPB>;
> +			assigned-clock-parents = <&scmi_clk IMX95_CLK_SYSPLL1_PFD1_DIV2>;
> +			assigned-clock-rates = <133333333>;
> +			power-domains = <&scmi_devpd IMX95_PD_GPU>;
> +		};

With the SM release lf-6.12.3-1.0.0 AP does not have any access to
this BLK_CTRL anymore. See [1]

Best regards,
Alexander

[1] https://github.com/nxp-imx/imx-sm/blob/master/sm/doc/rn_cl.md#sm-184-deassert-the-gpu-reset-when-the-gpumix-is-powered-up-rn_detail_sm_184

> +
> +		gpu: gpu@4d900000 {
> +			compatible = "nxp,imx95-mali", "arm,mali-valhall-csf";
> +			reg = <0 0x4d900000 0 0x480000>;
> +			clocks = <&scmi_clk IMX95_CLK_GPU>, <&scmi_clk IMX95_CLK_GPUAPB>;
> +			clock-names = "core", "coregroup";
> +			interrupts = <GIC_SPI 289 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 288 IRQ_TYPE_LEVEL_HIGH>;
> +			interrupt-names = "job", "mmu", "gpu";
> +			mali-supply = <&gpu_fixed_reg>;
> +			operating-points-v2 = <&gpu_opp_table>;
> +			power-domains = <&scmi_devpd IMX95_PD_GPU>, <&scmi_perf IMX95_PERF_GPU>;
> +			power-domain-names = "mix", "perf";
> +			resets = <&gpu_blk_ctrl 0>;
> +			#cooling-cells = <2>;
> +			dynamic-power-coefficient = <1013>;
> +		};
> +
>  		ddr-pmu@4e090dc0 {
>  			compatible = "fsl,imx95-ddr-pmu", "fsl,imx93-ddr-pmu";
>  			reg = <0x0 0x4e090dc0 0x0 0x200>;
> 


-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/

Re: [PATCH v2 9/9] arm64: dts: imx95: Describe Mali G310 GPU

[Marek Vasut]

On 3/24/25 8:02 AM, Alexander Stein wrote:

Hi,

>> @@ -1890,6 +1919,35 @@ netc_emdio: mdio@0,0 {
>>   			};
>>   		};
>>   
>> +		gpu_blk_ctrl: reset-controller@4d810000 {
>> +			compatible = "nxp,imx95-gpu-blk-ctrl";
>> +			reg = <0x0 0x4d810000 0x0 0xc>;
>> +			#reset-cells = <1>;
>> +			clocks = <&scmi_clk IMX95_CLK_GPUAPB>;
>> +			assigned-clocks = <&scmi_clk IMX95_CLK_GPUAPB>;
>> +			assigned-clock-parents = <&scmi_clk IMX95_CLK_SYSPLL1_PFD1_DIV2>;
>> +			assigned-clock-rates = <133333333>;
>> +			power-domains = <&scmi_devpd IMX95_PD_GPU>;
>> +		};
> 
> With the SM release lf-6.12.3-1.0.0 AP does not have any access to
> this BLK_CTRL anymore. See [1]
I just built SM 6.12 and it still requires the reset, without reset I 
cannot use the GPU ... or ... which BLK CTRL do you refer to ?

Re: [PATCH v2 9/9] arm64: dts: imx95: Describe Mali G310 GPU

[Alexander Stein]

Hi Marek,

Am Dienstag, 25. März 2025, 00:35:41 CET schrieb Marek Vasut:
> On 3/24/25 8:02 AM, Alexander Stein wrote:
> 
> Hi,
> 
> >> @@ -1890,6 +1919,35 @@ netc_emdio: mdio@0,0 {
> >>   			};
> >>   		};
> >>   
> >> +		gpu_blk_ctrl: reset-controller@4d810000 {
> >> +			compatible = "nxp,imx95-gpu-blk-ctrl";
> >> +			reg = <0x0 0x4d810000 0x0 0xc>;
> >> +			#reset-cells = <1>;
> >> +			clocks = <&scmi_clk IMX95_CLK_GPUAPB>;
> >> +			assigned-clocks = <&scmi_clk IMX95_CLK_GPUAPB>;
> >> +			assigned-clock-parents = <&scmi_clk IMX95_CLK_SYSPLL1_PFD1_DIV2>;
> >> +			assigned-clock-rates = <133333333>;
> >> +			power-domains = <&scmi_devpd IMX95_PD_GPU>;
> >> +		};
> > 
> > With the SM release lf-6.12.3-1.0.0 AP does not have any access to
> > this BLK_CTRL anymore. See [1]
> I just built SM 6.12 and it still requires the reset, without reset I 
> cannot use the GPU ... or ... which BLK CTRL do you refer to ?

I'm specifically looking at [1]. AFAIU after that change AP has no access
to BLK_CTRL_GPUMIX. But this is just from looking at the changes.

Best regards
Alexander

[1] https://github.com/nxp-imx/imx-sm/commit/a3e5da9ea51144f513ac3909fa151fa7df394100
-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/

Re: [PATCH v2 9/9] arm64: dts: imx95: Describe Mali G310 GPU

[Peng Fan]

On Mon, Mar 24, 2025 at 08:02:06AM +0100, Alexander Stein wrote:
>Am Freitag, 21. M?rz 2025, 21:05:59 CET schrieb Marek Vasut:
>> The instance of the GPU populated in i.MX95 is the G310,
>> describe this GPU in the DT. Include description of the
>> GPUMIX block controller, which can be operated as a simple
>> reset. Include dummy GPU voltage regulator and OPP tables.
>> 
>> Signed-off-by: Marek Vasut <marex@denx.de>
>> ---
>> Cc: Boris Brezillon <boris.brezillon@collabora.com>
>> Cc: Conor Dooley <conor+dt@kernel.org>
>> Cc: David Airlie <airlied@gmail.com>
>> Cc: Fabio Estevam <festevam@gmail.com>
>> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
>> Cc: Liviu Dudau <liviu.dudau@arm.com>
>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>> Cc: Maxime Ripard <mripard@kernel.org>
>> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
>> Cc: Philipp Zabel <p.zabel@pengutronix.de>
>> Cc: Rob Herring <robh@kernel.org>
>> Cc: Sascha Hauer <s.hauer@pengutronix.de>
>> Cc: Sebastian Reichel <sre@kernel.org>
>> Cc: Shawn Guo <shawnguo@kernel.org>
>> Cc: Simona Vetter <simona@ffwll.ch>
>> Cc: Steven Price <steven.price@arm.com>
>> Cc: Thomas Zimmermann <tzimmermann@suse.de>
>> Cc: devicetree@vger.kernel.org
>> Cc: dri-devel@lists.freedesktop.org
>> Cc: imx@lists.linux.dev
>> Cc: linux-arm-kernel@lists.infradead.org
>> ---
>> V2: - Drop regulator-{always,boot}-on from fixed-gpu-reg regulator
>>     - Keep the GPU and GPUMIX always enabled
>>     - Switch from fsl, to nxp, vendor prefix
>>     - Fix opp_table to opp-table
>>     - Describe IMX95_CLK_GPUAPB as coregroup clock
>>     - Sort interrupts by their names to match bindings
>> ---
>>  arch/arm64/boot/dts/freescale/imx95.dtsi | 58 ++++++++++++++++++++++++
>>  1 file changed, 58 insertions(+)
>> 
>> diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi
>> index 9bb26b466a061..3acdbd7fd4eee 100644
>> --- a/arch/arm64/boot/dts/freescale/imx95.dtsi
>> +++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
>> @@ -249,6 +249,35 @@ dummy: clock-dummy {
>>  		clock-output-names = "dummy";
>>  	};
>>  
>> +	gpu_fixed_reg: fixed-gpu-reg {
>> +		compatible = "regulator-fixed";
>> +		regulator-min-microvolt = <920000>;
>> +		regulator-max-microvolt = <920000>;
>> +		regulator-name = "vdd_gpu";
>> +	};
>> +
>> +	gpu_opp_table: opp-table {
>> +		compatible = "operating-points-v2";
>> +
>> +		opp-500000000 {
>> +			opp-hz = /bits/ 64 <500000000>;
>> +			opp-hz-real = /bits/ 64 <500000000>;
>> +			opp-microvolt = <920000>;
>> +		};
>> +
>> +		opp-800000000 {
>> +			opp-hz = /bits/ 64 <800000000>;
>> +			opp-hz-real = /bits/ 64 <800000000>;
>> +			opp-microvolt = <920000>;
>> +		};
>> +
>> +		opp-1000000000 {
>> +			opp-hz = /bits/ 64 <1000000000>;
>> +			opp-hz-real = /bits/ 64 <1000000000>;
>> +			opp-microvolt = <920000>;
>> +		};
>> +	};
>> +
>>  	clk_ext1: clock-ext1 {
>>  		compatible = "fixed-clock";
>>  		#clock-cells = <0>;
>> @@ -1890,6 +1919,35 @@ netc_emdio: mdio@0,0 {
>>  			};
>>  		};
>>  
>> +		gpu_blk_ctrl: reset-controller@4d810000 {
>> +			compatible = "nxp,imx95-gpu-blk-ctrl";
>> +			reg = <0x0 0x4d810000 0x0 0xc>;
>> +			#reset-cells = <1>;
>> +			clocks = <&scmi_clk IMX95_CLK_GPUAPB>;
>> +			assigned-clocks = <&scmi_clk IMX95_CLK_GPUAPB>;
>> +			assigned-clock-parents = <&scmi_clk IMX95_CLK_SYSPLL1_PFD1_DIV2>;
>> +			assigned-clock-rates = <133333333>;
>> +			power-domains = <&scmi_devpd IMX95_PD_GPU>;
>> +		};
>
>With the SM release lf-6.12.3-1.0.0 AP does not have any access to
>this BLK_CTRL anymore. See [1]

Right. In configs/mx95evk.cfg, BLK_CTRL_GPUMIX is assigned to M33P, and
System manager will automatically handle this reset.

Regards
Peng

>
>Best regards,
>Alexander
>
>[1] https://github.com/nxp-imx/imx-sm/blob/master/sm/doc/rn_cl.md#sm-184-deassert-the-gpu-reset-when-the-gpumix-is-powered-up-rn_detail_sm_184
>
>> +
>> +		gpu: gpu@4d900000 {
>> +			compatible = "nxp,imx95-mali", "arm,mali-valhall-csf";
>> +			reg = <0 0x4d900000 0 0x480000>;
>> +			clocks = <&scmi_clk IMX95_CLK_GPU>, <&scmi_clk IMX95_CLK_GPUAPB>;
>> +			clock-names = "core", "coregroup";
>> +			interrupts = <GIC_SPI 289 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 288 IRQ_TYPE_LEVEL_HIGH>;
>> +			interrupt-names = "job", "mmu", "gpu";
>> +			mali-supply = <&gpu_fixed_reg>;
>> +			operating-points-v2 = <&gpu_opp_table>;
>> +			power-domains = <&scmi_devpd IMX95_PD_GPU>, <&scmi_perf IMX95_PERF_GPU>;
>> +			power-domain-names = "mix", "perf";
>> +			resets = <&gpu_blk_ctrl 0>;
>> +			#cooling-cells = <2>;
>> +			dynamic-power-coefficient = <1013>;
>> +		};
>> +
>>  		ddr-pmu@4e090dc0 {
>>  			compatible = "fsl,imx95-ddr-pmu", "fsl,imx93-ddr-pmu";
>>  			reg = <0x0 0x4e090dc0 0x0 0x200>;
>> 
>
>
>-- 
>TQ-Systems GmbH | M?hlstra?e 2, Gut Delling | 82229 Seefeld, Germany
>Amtsgericht M?nchen, HRB 105018
>Gesch?ftsf?hrer: Detlef Schneider, R?diger Stahl, Stefan Schneider
>http://www.tq-group.com/
>
>

Re: [PATCH v2 9/9] arm64: dts: imx95: Describe Mali G310 GPU

[Marek Vasut]

On 9/4/25 11:54 AM, Peng Fan wrote:

Hello Peng,

>>> @@ -1890,6 +1919,35 @@ netc_emdio: mdio@0,0 {
>>>   			};
>>>   		};
>>>   
>>> +		gpu_blk_ctrl: reset-controller@4d810000 {
>>> +			compatible = "nxp,imx95-gpu-blk-ctrl";
>>> +			reg = <0x0 0x4d810000 0x0 0xc>;
>>> +			#reset-cells = <1>;
>>> +			clocks = <&scmi_clk IMX95_CLK_GPUAPB>;
>>> +			assigned-clocks = <&scmi_clk IMX95_CLK_GPUAPB>;
>>> +			assigned-clock-parents = <&scmi_clk IMX95_CLK_SYSPLL1_PFD1_DIV2>;
>>> +			assigned-clock-rates = <133333333>;
>>> +			power-domains = <&scmi_devpd IMX95_PD_GPU>;
>>> +		};
>>
>> With the SM release lf-6.12.3-1.0.0 AP does not have any access to
>> this BLK_CTRL anymore. See [1]
> 
> Right. In configs/mx95evk.cfg, BLK_CTRL_GPUMIX is assigned to M33P, and
> System manager will automatically handle this reset.
This discussion will get interesting, because there are systems in the 
field where this is not the case, and they cannot easily update their 
bootloader. How do we handle that ?

I can still update most of the systems I care about, but this really 
isn't the way to handle this, because this reset part is part of 
firmware ABI, which has changed now.