[PATCH 0/3] drm/msm: Enable dual MDSS power domains

[PATCH 0/3] drm/msm: Enable dual MDSS power domains

[Yongxing Mou]

Kaanapali (SM8750) and Glymur use two display power domains.
CORE_GDSC powers the main display hardware while INT2_GDSC powers
a subset of SSPP blocks.

The current MDSS implementation only manages the primary display
power domain. SSPPs backed by INT2_GDSC therefore remain inaccessible.

Add dual power-domain support to MDSS, update the DT bindings to
describe both domains, and add INT2_GDSC to the Kaanapali and Glymur
MDSS nodes.

Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
---
Yongxing Mou (3):
      dt-bindings: display: msm: Allow two MDSS power domains
      drm/msm/mdss: Enable INT2_GDSC alongside CORE_GDSC
      arm64: dts: qcom: Add INT2_GDSC to MDSS on Kaanapali and Glymur

 .../bindings/display/msm/mdss-common.yaml          |  3 +-
 .../bindings/display/msm/qcom,glymur-mdss.yaml     | 13 +++++-
 .../bindings/display/msm/qcom,kaanapali-mdss.yaml  | 13 +++++-
 arch/arm64/boot/dts/qcom/glymur.dtsi               |  4 +-
 arch/arm64/boot/dts/qcom/kaanapali.dtsi            |  4 +-
 drivers/gpu/drm/msm/msm_mdss.c                     | 53 +++++++++++++++++++++-
 6 files changed, 84 insertions(+), 6 deletions(-)
---
base-commit: bee763d5f341b99cf472afeb508d4988f62a6ca1
change-id: 20260720-msm_gdsc2-cb9230027a2d

Best regards,
-- 
Yongxing Mou <yongxing.mou@oss.qualcomm.com>

[PATCH 1/3] dt-bindings: display: msm: Allow two MDSS power domains

[Yongxing Mou]

Kaanapali (SM8750) and Glymur use two display power domains.
CORE_GDSC powers the main display hardware while INT2_GDSC
powers a subset of SSPP blocks.

Allow the MDSS bindings to describe both power domains and
their corresponding power-domain-names values.

Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
---
 .../devicetree/bindings/display/msm/mdss-common.yaml        |  3 ++-
 .../devicetree/bindings/display/msm/qcom,glymur-mdss.yaml   | 13 ++++++++++++-
 .../bindings/display/msm/qcom,kaanapali-mdss.yaml           | 13 ++++++++++++-
 3 files changed, 26 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/msm/mdss-common.yaml b/Documentation/devicetree/bindings/display/msm/mdss-common.yaml
index c6305a6e0334..c0b650ffd9ef 100644
--- a/Documentation/devicetree/bindings/display/msm/mdss-common.yaml
+++ b/Documentation/devicetree/bindings/display/msm/mdss-common.yaml
@@ -31,7 +31,8 @@ properties:
     const: mdss
 
   power-domains:
-    maxItems: 1
+    minItems: 1
+    maxItems: 2
 
   clocks:
     minItems: 2
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,glymur-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,glymur-mdss.yaml
index 64dde43373ac..685bedb26a12 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,glymur-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,glymur-mdss.yaml
@@ -38,6 +38,16 @@ properties:
       - const: mdp0-mem
       - const: cpu-cfg
 
+  power-domains:
+    items:
+      - description: MDSS core GDSC power domain
+      - description: MDSS INT2 GDSC power domain
+
+  power-domain-names:
+    items:
+      - const: core
+      - const: int2
+
 patternProperties:
   "^display-controller@[0-9a-f]+$":
     type: object
@@ -95,7 +105,8 @@ examples:
 
             resets = <&disp_cc_mdss_core_bcr>;
 
-            power-domains = <&mdss_gdsc>;
+            power-domains = <&mdss_gdsc>, <&mdss_int2_gdsc>;
+            power-domain-names = "core", "int2";
 
             iommus = <&apps_smmu 0x1c00 0x2>;
 
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,kaanapali-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,kaanapali-mdss.yaml
index 9f935defd6b1..088010f464c3 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,kaanapali-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,kaanapali-mdss.yaml
@@ -40,6 +40,16 @@ properties:
       - const: mdp0-mem
       - const: cpu-cfg
 
+  power-domains:
+    items:
+      - description: MDSS core GDSC power domain
+      - description: MDSS INT2 GDSC power domain
+
+  power-domain-names:
+    items:
+      - const: core
+      - const: int2
+
 patternProperties:
   "^display-controller@[0-9a-f]+$":
     type: object
@@ -89,7 +99,8 @@ examples:
                  <&disp_cc_mdss_ahb_swi_clk>;
         resets = <&disp_cc_mdss_core_bcr>;
 
-        power-domains = <&mdss_gdsc>;
+        power-domains = <&mdss_gdsc>, <&mdss_int2_gdsc>;
+        power-domain-names = "core", "int2";
 
         iommus = <&apps_smmu 0x800 0x2>;
 

-- 
2.43.0

Re: [PATCH 1/3] dt-bindings: display: msm: Allow two MDSS power domains

[Konrad Dybcio]

On 7/20/26 10:43 AM, Yongxing Mou wrote:
> Kaanapali (SM8750) and Glymur use two display power domains.
> CORE_GDSC powers the main display hardware while INT2_GDSC
> powers a subset of SSPP blocks.

Can they operate independently? Does INT2_GDSC need to be
powered on after CORE_GDSC?

If so, perhaps changing the clock driver to make CORE a parent
of INT2 could be the simpler solution

Konrad

Re: [PATCH 1/3] dt-bindings: display: msm: Allow two MDSS power domains

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] Relaxing the global maximum number of `power-domains` in `mdss-common.yaml` without restricting legacy schemas allows invalid device trees to pass validation.
- [Medium] Missing `power-domain-names` in the `required` list allows incomplete device trees to pass validation.
- [Medium] Adding an items array to `power-domains` implicitly sets `minItems: 2`, breaking backward compatibility for existing device trees.
--

--- Patch [1]: [PATCH 1/3] dt-bindings: display: msm: Allow two MDSS power domains ---
commit 3afe59087bba460fdef9d8666ba4cb4a97273b44
Author: Yongxing Mou <yongxing.mou@oss.qualcomm.com>

dt-bindings: display: msm: Allow two MDSS power domains

Kaanapali (SM8750) and Glymur use two display power domains.
CORE_GDSC powers the main display hardware while INT2_GDSC
powers a subset of SSPP blocks.

Allow the MDSS bindings to describe both power domains and
their corresponding power-domain-names values.

> diff --git a/Documentation/devicetree/bindings/display/msm/mdss-common.yaml b/Documentation/devicetree/bindings/display/msm/mdss-common.yaml
> index c6305a6e03346..c0b650ffd9ef8 100644
> --- a/Documentation/devicetree/bindings/display/msm/mdss-common.yaml
> +++ b/Documentation/devicetree/bindings/display/msm/mdss-common.yaml
> @@ -31,7 +31,8 @@ properties:
>      const: mdss
>  
>    power-domains:
> -    maxItems: 1
> +    minItems: 1
> +    maxItems: 2

[Severity: Medium]
When we relax the global maximum number of power-domains here, does this allow
invalid device trees to pass validation for legacy platforms?

For example, schemas like qcom,sm8550-mdss.yaml include this common schema
but only have 1 hardware power domain. Without explicitly overriding
maxItems to 1 in those legacy schemas, they might silently accept invalid
device trees with 2 power domains.

>  
>    clocks:
>      minItems: 2
> diff --git a/Documentation/devicetree/bindings/display/msm/qcom,glymur-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,glymur-mdss.yaml
> index 64dde43373ac7..685bedb26a124 100644
> --- a/Documentation/devicetree/bindings/display/msm/qcom,glymur-mdss.yaml
> +++ b/Documentation/devicetree/bindings/display/msm/qcom,glymur-mdss.yaml
[ ... ]
> @@ -38,6 +38,16 @@ properties:
>        - const: mdp0-mem
>        - const: cpu-cfg
>  
> +  power-domains:
> +    items:
> +      - description: MDSS core GDSC power domain
> +      - description: MDSS INT2 GDSC power domain

[Severity: Medium]
Does adding this items array implicitly set minItems to 2 during dt-schema
evaluation?

If so, this might break backward compatibility for older device trees that
only specify a single power domain. Should minItems: 1 be explicitly
specified here?

> +
> +  power-domain-names:
> +    items:
> +      - const: core
> +      - const: int2

[Severity: Medium]
If a device tree specifies 2 power domains but omits power-domain-names,
will it pass schema validation?

The driver might fail to probe at runtime when attempting to attach power
domains by name. Should power-domain-names be conditionally required in the
required list (using an if-then block) when multiple power domains are
provided?

> +
>  patternProperties:
>    "^display-controller@[0-9a-f]+$":
>      type: object
> diff --git a/Documentation/devicetree/bindings/display/msm/qcom,kaanapali-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,kaanapali-mdss.yaml
> index 9f935defd6b12..088010f464c3d 100644
> --- a/Documentation/devicetree/bindings/display/msm/qcom,kaanapali-mdss.yaml
> +++ b/Documentation/devicetree/bindings/display/msm/qcom,kaanapali-mdss.yaml
[ ... ]
> @@ -40,6 +40,16 @@ properties:
>        - const: mdp0-mem
>        - const: cpu-cfg
>  
> +  power-domains:
> +    items:
> +      - description: MDSS core GDSC power domain
> +      - description: MDSS INT2 GDSC power domain

[Severity: Medium]
Similar to the glymur binding, does this items array implicitly set minItems
to 2 and break backward compatibility?

> +
> +  power-domain-names:
> +    items:
> +      - const: core
> +      - const: int2

[Severity: Medium]
Also similar to the glymur binding, should power-domain-names be conditionally
required to ensure device trees with two power domains provide the necessary
names for the driver?

> +
>  patternProperties:
>    "^display-controller@[0-9a-f]+$":
>      type: object

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720-msm_gdsc2-v1-0-4687866d6cb0@oss.qualcomm.com?part=1

Re: [PATCH 1/3] dt-bindings: display: msm: Allow two MDSS power domains

[Dmitry Baryshkov]

On Mon, Jul 20, 2026 at 04:43:53PM +0800, Yongxing Mou wrote:
> Kaanapali (SM8750) and Glymur use two display power domains.
> CORE_GDSC powers the main display hardware while INT2_GDSC
> powers a subset of SSPP blocks.

I see that INT2_GDSC is defined since SC8280XP / SM8450. Does it need to
be enabled on all those platforms?

> 
> Allow the MDSS bindings to describe both power domains and
> their corresponding power-domain-names values.
> 
> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
> ---
>  .../devicetree/bindings/display/msm/mdss-common.yaml        |  3 ++-
>  .../devicetree/bindings/display/msm/qcom,glymur-mdss.yaml   | 13 ++++++++++++-
>  .../bindings/display/msm/qcom,kaanapali-mdss.yaml           | 13 ++++++++++++-
>  3 files changed, 26 insertions(+), 3 deletions(-)
> 

-- 
With best wishes
Dmitry

Re: [PATCH 1/3] dt-bindings: display: msm: Allow two MDSS power domains

[Dmitry Baryshkov]

On Mon, Jul 20, 2026 at 04:43:53PM +0800, Yongxing Mou wrote:
> Kaanapali (SM8750) and Glymur use two display power domains.
> CORE_GDSC powers the main display hardware while INT2_GDSC
> powers a subset of SSPP blocks.
> 
> Allow the MDSS bindings to describe both power domains and
> their corresponding power-domain-names values.

Another question... If INT2_GDSC only powers up a subset of SSPPs, why
is it being declared as powering up the full MDSS? Can we move it to the
DPU device instead?

> 
> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
> ---
>  .../devicetree/bindings/display/msm/mdss-common.yaml        |  3 ++-
>  .../devicetree/bindings/display/msm/qcom,glymur-mdss.yaml   | 13 ++++++++++++-
>  .../bindings/display/msm/qcom,kaanapali-mdss.yaml           | 13 ++++++++++++-
>  3 files changed, 26 insertions(+), 3 deletions(-)
> 

-- 
With best wishes
Dmitry

[PATCH 2/3] drm/msm/mdss: Enable INT2_GDSC alongside CORE_GDSC

[Yongxing Mou]

Kaanapali (SM8750) and Glymur use two display power domains.
CORE_GDSC powers the main display hardware while INT2_GDSC powers
a subset of SSPP blocks (VIG2/VIG3/DMA5/DMA6).

The MDSS driver currently relies on the default runtime PM handling
and does not enable the secondary INT2_GDSC. As a result, display
pipes backed by INT2_GDSC remain inaccessible.

Attach and manage both power domains explicitly and enable them
during MDSS runtime PM activation.

Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
---
 drivers/gpu/drm/msm/msm_mdss.c | 53 +++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 52 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index 9087c4b290db..63ece55c4f2e 100644
--- a/drivers/gpu/drm/msm/msm_mdss.c
+++ b/drivers/gpu/drm/msm/msm_mdss.c
@@ -13,6 +13,7 @@
 #include <linux/irqchip/chained_irq.h>
 #include <linux/of_platform.h>
 #include <linux/platform_device.h>
+#include <linux/pm_domain.h>
 #include <linux/pm_runtime.h>
 #include <linux/reset.h>
 
@@ -44,6 +45,7 @@ struct msm_mdss {
 	struct icc_path *mdp_path[2];
 	u32 num_mdp_paths;
 	struct icc_path *reg_bus_path;
+	struct dev_pm_domain_list *pd_list;
 };
 
 static int msm_mdss_parse_data_bus_icc_path(struct device *dev,
@@ -233,6 +235,21 @@ static int msm_mdss_enable(struct msm_mdss *msm_mdss)
 	int ret, i;
 	u32 hw_rev;
 
+	/*
+	 * Platforms with two power domains (e.g. Kaanapali, Glymur) need both
+	 * GDSCs enabled explicitly; the core framework only auto-attaches a
+	 * single power domain.
+	 */
+	if (msm_mdss->pd_list) {
+		ret = pm_runtime_resume_and_get(msm_mdss->pd_list->pd_devs[0]);
+		if (ret < 0)
+			return ret;
+
+		ret = pm_runtime_resume_and_get(msm_mdss->pd_list->pd_devs[1]);
+		if (ret < 0)
+			goto err_put_core;
+	}
+
 	/*
 	 * Several components have AXI clocks that can only be turned on if
 	 * the interconnect is enabled (non-zero bandwidth). Let's make sure
@@ -255,7 +272,7 @@ static int msm_mdss_enable(struct msm_mdss *msm_mdss)
 	ret = clk_bulk_prepare_enable(msm_mdss->num_clocks, msm_mdss->clocks);
 	if (ret) {
 		dev_err(msm_mdss->dev, "clock enable failed, ret:%d\n", ret);
-		return ret;
+		goto err_put_int2;
 	}
 
 	/*
@@ -276,6 +293,14 @@ static int msm_mdss_enable(struct msm_mdss *msm_mdss)
 	/* else UBWC 1.0 or none, no params to program */
 
 	return ret;
+
+err_put_int2:
+	if (msm_mdss->pd_list)
+		pm_runtime_put_sync(msm_mdss->pd_list->pd_devs[1]);
+err_put_core:
+	if (msm_mdss->pd_list)
+		pm_runtime_put_sync(msm_mdss->pd_list->pd_devs[0]);
+	return ret;
 }
 
 static int msm_mdss_disable(struct msm_mdss *msm_mdss)
@@ -290,6 +315,11 @@ static int msm_mdss_disable(struct msm_mdss *msm_mdss)
 	if (msm_mdss->reg_bus_path)
 		icc_set_bw(msm_mdss->reg_bus_path, 0, 0);
 
+	if (msm_mdss->pd_list) {
+		pm_runtime_put_sync(msm_mdss->pd_list->pd_devs[1]);
+		pm_runtime_put_sync(msm_mdss->pd_list->pd_devs[0]);
+	}
+
 	return 0;
 }
 
@@ -421,6 +451,27 @@ static struct msm_mdss *msm_mdss_init(struct platform_device *pdev, bool is_mdp5
 	irq_set_chained_handler_and_data(irq, msm_mdss_irq,
 					 msm_mdss);
 
+	/*
+	 * When two power domains are listed in DT, the core framework does not
+	 * auto-attach either of them.  Attach and manage both explicitly so
+	 * that INT2_GDSC (needed for VIG2/VIG3) is enabled alongside the main
+	 * CORE_GDSC.  Single-domain platforms are unaffected.
+	 */
+	if (of_count_phandle_with_args(pdev->dev.of_node, "power-domains",
+				       "#power-domain-cells") > 1) {
+		static const char * const mdss_pd_names[] = { "core", "int2" };
+		static const struct dev_pm_domain_attach_data pd_data = {
+			.pd_names = mdss_pd_names,
+			.num_pd_names = ARRAY_SIZE(mdss_pd_names),
+			.pd_flags = PD_FLAG_NO_DEV_LINK,
+		};
+
+		ret = devm_pm_domain_attach_list(&pdev->dev, &pd_data,
+						 &msm_mdss->pd_list);
+		if (ret < 0)
+			return ERR_PTR(ret);
+	}
+
 	pm_runtime_enable(&pdev->dev);
 
 	return msm_mdss;

-- 
2.43.0

Re: [PATCH 2/3] drm/msm/mdss: Enable INT2_GDSC alongside CORE_GDSC

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing cleanup for IRQ domain and chained handler on power domain attach failure.
--

--- Patch [2]: [PATCH 2/3] drm/msm/mdss: Enable INT2_GDSC alongside CORE_GDSC ---
commit 9d271e868146fa30f583363d709a200283bfe76e
Author: Yongxing Mou <yongxing.mou@oss.qualcomm.com>

drm/msm/mdss: Enable INT2_GDSC alongside CORE_GDSC

This patch explicitly attaches and manages the secondary INT2_GDSC power
domain for platforms that use it. It also ensures both power domains are
enabled during MDSS runtime PM activation.

> diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
> index 9087c4b290dba..63ece55c4f2ec 100644
> --- a/drivers/gpu/drm/msm/msm_mdss.c
> +++ b/drivers/gpu/drm/msm/msm_mdss.c

[ ... ]

> @@ -421,6 +451,27 @@ static struct msm_mdss *msm_mdss_init(struct platform_device *pdev, bool is_mdp5
>  	irq_set_chained_handler_and_data(irq, msm_mdss_irq,
>  					 msm_mdss);
>  
> +	/*
> +	 * When two power domains are listed in DT, the core framework does not
> +	 * auto-attach either of them.  Attach and manage both explicitly so
> +	 * that INT2_GDSC (needed for VIG2/VIG3) is enabled alongside the main
> +	 * CORE_GDSC.  Single-domain platforms are unaffected.
> +	 */
> +	if (of_count_phandle_with_args(pdev->dev.of_node, "power-domains",
> +				       "#power-domain-cells") > 1) {
> +		static const char * const mdss_pd_names[] = { "core", "int2" };
> +		static const struct dev_pm_domain_attach_data pd_data = {
> +			.pd_names = mdss_pd_names,
> +			.num_pd_names = ARRAY_SIZE(mdss_pd_names),
> +			.pd_flags = PD_FLAG_NO_DEV_LINK,
> +		};
> +
> +		ret = devm_pm_domain_attach_list(&pdev->dev, &pd_data,
> +						 &msm_mdss->pd_list);
> +		if (ret < 0)
> +			return ERR_PTR(ret);

[Severity: High]
If devm_pm_domain_attach_list() fails here, we return directly with an error
pointer. Since the msm_mdss structure is allocated with devm_kzalloc(), it
will be automatically freed by the devres subsystem when the probe fails.

However, irq_set_chained_handler_and_data() was already called just above to
register msm_mdss_irq() with msm_mdss as its data pointer.

Could this leave a dangling pointer in the active chained handler, resulting
in a use-after-free if an interrupt fires? Also, do we need to clean up the
IRQ domain created by _msm_mdss_irq_domain_add() before returning on this
error path?

> +	}
> +
>  	pm_runtime_enable(&pdev->dev);
>  
>  	return msm_mdss;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720-msm_gdsc2-v1-0-4687866d6cb0@oss.qualcomm.com?part=2

Re: [PATCH 2/3] drm/msm/mdss: Enable INT2_GDSC alongside CORE_GDSC

[Dmitry Baryshkov]

On Mon, Jul 20, 2026 at 04:43:54PM +0800, Yongxing Mou wrote:
> Kaanapali (SM8750) and Glymur use two display power domains.
> CORE_GDSC powers the main display hardware while INT2_GDSC powers
> a subset of SSPP blocks (VIG2/VIG3/DMA5/DMA6).
> 
> The MDSS driver currently relies on the default runtime PM handling
> and does not enable the secondary INT2_GDSC. As a result, display
> pipes backed by INT2_GDSC remain inaccessible.
> 
> Attach and manage both power domains explicitly and enable them
> during MDSS runtime PM activation.
> 
> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
> ---
>  drivers/gpu/drm/msm/msm_mdss.c | 53 +++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 52 insertions(+), 1 deletion(-)

Why is it being handled in the MDSS rather than DPU?

> @@ -421,6 +451,27 @@ static struct msm_mdss *msm_mdss_init(struct platform_device *pdev, bool is_mdp5
>  	irq_set_chained_handler_and_data(irq, msm_mdss_irq,
>  					 msm_mdss);
>  
> +	/*
> +	 * When two power domains are listed in DT, the core framework does not
> +	 * auto-attach either of them.  Attach and manage both explicitly so
> +	 * that INT2_GDSC (needed for VIG2/VIG3) is enabled alongside the main
> +	 * CORE_GDSC.  Single-domain platforms are unaffected.
> +	 */
> +	if (of_count_phandle_with_args(pdev->dev.of_node, "power-domains",
> +				       "#power-domain-cells") > 1) {
> +		static const char * const mdss_pd_names[] = { "core", "int2" };
> +		static const struct dev_pm_domain_attach_data pd_data = {
> +			.pd_names = mdss_pd_names,
> +			.num_pd_names = ARRAY_SIZE(mdss_pd_names),
> +			.pd_flags = PD_FLAG_NO_DEV_LINK,

Can't you use DL_FLAG_PM_RUNTIME here?

> +		};
> +
> +		ret = devm_pm_domain_attach_list(&pdev->dev, &pd_data,
> +						 &msm_mdss->pd_list);
> +		if (ret < 0)
> +			return ERR_PTR(ret);
> +	}
> +
>  	pm_runtime_enable(&pdev->dev);
>  
>  	return msm_mdss;
> 
> -- 
> 2.43.0
> 

-- 
With best wishes
Dmitry

[PATCH 3/3] arm64: dts: qcom: Add INT2_GDSC to MDSS on Kaanapali and Glymur

[Yongxing Mou]

Kaanapali (SM8750) and Glymur use two display power domains.
CORE_GDSC powers the main display hardware while INT2_GDSC powers
a subset of SSPP blocks (VIG2/VIG3/DMA5/DMA6).

Add DISP_CC_MDSS_CORE_INT2_GDSC alongside the existing CORE_GDSC
reference in the MDSS node on both platforms and provide matching
power-domain-names entries for the display power domains.

Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/glymur.dtsi    | 4 +++-
 arch/arm64/boot/dts/qcom/kaanapali.dtsi | 4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
index dd80da14ab10..1e447c1d69f7 100644
--- a/arch/arm64/boot/dts/qcom/glymur.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
@@ -4898,7 +4898,9 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
 			interconnect-names = "mdp0-mem",
 					     "cpu-cfg";
 
-			power-domains = <&dispcc DISP_CC_MDSS_CORE_GDSC>;
+			power-domains = <&dispcc DISP_CC_MDSS_CORE_GDSC>,
+					<&dispcc DISP_CC_MDSS_CORE_INT2_GDSC>;
+			power-domain-names = "core", "int2";
 
 			iommus = <&apps_smmu 0x1de0 0x2>;
 
diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index ace19b8b12d7..ae851adec5a6 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -3581,7 +3581,9 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
 			interconnect-names = "mdp0-mem",
 					     "cpu-cfg";
 
-			power-domains = <&dispcc DISP_CC_MDSS_CORE_GDSC>;
+			power-domains = <&dispcc DISP_CC_MDSS_CORE_GDSC>,
+					<&dispcc DISP_CC_MDSS_CORE_INT2_GDSC>;
+			power-domain-names = "core", "int2";
 
 			iommus = <&apps_smmu 0x800 0x2>;
 

-- 
2.43.0

Re: [PATCH 3/3] arm64: dts: qcom: Add INT2_GDSC to MDSS on Kaanapali and Glymur

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The patch omits `sm8750.dtsi`, failing to add the `INT2_GDSC` power domain for SM8750 despite the commit message explicitly declaring that SM8750 requires it.
- [High] Missing cleanup of the IRQ domain and chained handler when power domain attachment fails, leading to a Use-After-Free.
--

--- Patch [3]: [PATCH 3/3] arm64: dts: qcom: Add INT2_GDSC to MDSS on Kaanapali and Glymur ---
commit a757d0e4c829d9c4eb6cdd0c681fb7e3459e226e
Author: Yongxing Mou <yongxing.mou@oss.qualcomm.com>

arm64: dts: qcom: Add INT2_GDSC to MDSS on Kaanapali and Glymur

Kaanapali (SM8750) and Glymur use two display power domains.
CORE_GDSC powers the main display hardware while INT2_GDSC powers
a subset of SSPP blocks (VIG2/VIG3/DMA5/DMA6).

Add DISP_CC_MDSS_CORE_INT2_GDSC alongside the existing CORE_GDSC
reference in the MDSS node on both platforms and provide matching
power-domain-names entries for the display power domains.

> Kaanapali (SM8750) and Glymur use two display power domains.
> CORE_GDSC powers the main display hardware while INT2_GDSC powers
> a subset of SSPP blocks (VIG2/VIG3/DMA5/DMA6).

[Severity: High]
The commit message explicitly states that Kaanapali (SM8750) requires the
INT2_GDSC power domain. However, the patch omits updating sm8750.dtsi.

Could this omission cause SM8750 platforms using sm8750.dtsi to fall back
to single-domain mode and fail to attach the secondary power domain, leaving
a subset of SSPP blocks (VIG2/VIG3/DMA5/DMA6) unpowered and inaccessible?

diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index 9087c4b290dba..63ece55c4f2ec 100644
--- a/drivers/gpu/drm/msm/msm_mdss.c
+++ b/drivers/gpu/drm/msm/msm_mdss.c
[ ... ]
@@ -421,6 +451,27 @@ static struct msm_mdss *msm_mdss_init(struct platform_device *pdev, bool is_mdp5
 	irq_set_chained_handler_and_data(irq, msm_mdss_irq,
 					 msm_mdss);
 
+	/*
+	 * When two power domains are listed in DT, the core framework does not
+	 * auto-attach either of them.  Attach and manage both explicitly so
+	 * that INT2_GDSC (needed for VIG2/VIG3) is enabled alongside the main
+	 * CORE_GDSC.  Single-domain platforms are unaffected.
+	 */
+	if (of_count_phandle_with_args(pdev->dev.of_node, "power-domains",
+				       "#power-domain-cells") > 1) {
+		static const char * const mdss_pd_names[] = { "core", "int2" };
+		static const struct dev_pm_domain_attach_data pd_data = {
+			.pd_names = mdss_pd_names,
+			.num_pd_names = ARRAY_SIZE(mdss_pd_names),
+			.pd_flags = PD_FLAG_NO_DEV_LINK,
+		};
+
+		ret = devm_pm_domain_attach_list(&pdev->dev, &pd_data,
+						 &msm_mdss->pd_list);
+		if (ret < 0)
+			return ERR_PTR(ret);

[Severity: High]
Is it possible this error path leaves a dangling pointer registered in the IRQ
subsystem?

In msm_mdss_init(), irq_set_chained_handler_and_data() is called earlier to
install the chained handler with msm_mdss as the data pointer, and the IRQ
domain is created via irq_domain_create_linear(). If
devm_pm_domain_attach_list() fails (e.g., due to probe deferral), this block
directly returns an error without calling irq_set_chained_handler_and_data()
with NULL to clean it up, or calling irq_domain_remove().

Because msm_mdss is devres-allocated, it will be freed upon probe failure.
If a spurious or shared interrupt fires on that IRQ line, will the kernel
execute msm_mdss_irq() and dereference the freed msm_mdss pointer, causing a
use-after-free and a kernel panic?

+	}
+
 	pm_runtime_enable(&pdev->dev);
 
 	return msm_mdss;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720-msm_gdsc2-v1-0-4687866d6cb0@oss.qualcomm.com?part=3