[PATCH RFC] drm/msm/mdss: keep mdp1-mem interconnect alive during suspend on SDM845

[PATCH RFC] drm/msm/mdss: keep mdp1-mem interconnect alive during suspend on SDM845

[Sam Day via B4 Relay]

From: Sam Day <me@samcday.com>

If the peak vote for mdp1-mem is allowed to drop to zero, it seems to
cause the fabric to collapse that path entirely, which causes the device
to bus stall and fatally reset.

This issue was identified specifically on sdm845-oneplus-fajita, so this
workaround is applied narrowly to SDM845's MDSS.

---
This RFC patch is a spiritual successor to the "Addressing stability
issues on SDM845 with the -next tree" series sent by David and Petr 6
months ago.

As Dmitry pointed out, the patch introduces leakages to the runtime PM
refcounting. In practice, this means that MDSS never actually gets
suspended, which is why the patch appeared to "fix" the issue.

The deeper root cause is that, when msm_mdss_disable() runs and unvotes
the mdp1-mem interconnect bandwidth, that seems to collapse the fabric
entirely and causes the bus stall -> hang -> reboot behaviour.

I've confirmed that a tiny non-zero peak bandwidth vote keeps the fabric
alive and avoids the issue.

Of course, this is still a fairly egregious hack, but it *does* allow
blanking to suspend and resume DSI + DPU + MDSS properly without the bus
stall.

Here's what I've validated with instrumentation:

 * DSI host disable, IRQ disable, PLL state save, host power-off, link
   clock disable, regulator disable, SFPB disable, and PHY disable all
   complete successfully before the fatal reset occurrs.
 * DPU runtime suspend also completes. The bandwidth accounting was
   checked and confirmed to reach runtime suspend with 0 refs, with no
   pending frame state.
 * The device survives through MDSS clock disabling and mdp0-mem
   zero voting, it's really just the mdp1-mem zero vote that is isolated
   as the cause of the stall + reset.

So, I'm not really sure where to go from here. I'm sure that this
workaround is not suitable for inclusion upstream as it still seems to
be papering over an underlying issue... But it's unclear to me if this is
some kind of hardware quirk on SDM845, a problem with the SDM845 DT
wiring, a driver issue, or something else entirely.

I'd appreciate any advice on how to further diagnose this issue and what
direction to take from here.

Kind regards,
-Sam

Link: https://lore.kernel.org/phone-devel/20251213-stability-discussion-v1-0-b25df8453526@ixit.cz/
Signed-off-by: Sam Day <me@samcday.com>
---
 drivers/gpu/drm/msm/msm_mdss.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index 9087c4b290db..c635380b2ac3 100644
--- a/drivers/gpu/drm/msm/msm_mdss.c
+++ b/drivers/gpu/drm/msm/msm_mdss.c
@@ -284,8 +284,12 @@ static int msm_mdss_disable(struct msm_mdss *msm_mdss)
 
 	clk_bulk_disable_unprepare(msm_mdss->num_clocks, msm_mdss->clocks);
 
-	for (i = 0; i < msm_mdss->num_mdp_paths; i++)
-		icc_set_bw(msm_mdss->mdp_path[i], 0, 0);
+	for (i = 0; i < msm_mdss->num_mdp_paths; i++) {
+		if (of_device_is_compatible(msm_mdss->dev->of_node, "qcom,sdm845-mdss") && i == 1)
+			icc_set_bw(msm_mdss->mdp_path[i], 0, 1);
+		else
+			icc_set_bw(msm_mdss->mdp_path[i], 0, 0);
+	}
 
 	if (msm_mdss->reg_bus_path)
 		icc_set_bw(msm_mdss->reg_bus_path, 0, 0);

---
base-commit: 5a66900afbd6b2a063eebad35294038a654de2b0
change-id: 20260627-rfc-sdm845-interconnect-collapse-workaround-ba1cf846ca3f

Best regards,
-- 
Sam Day <me@samcday.com>

[PATCH RFC] drm/msm/mdss: keep mdp1-mem interconnect alive during suspend on SDM845

[Sam Day]

If the peak vote for mdp1-mem is allowed to drop to zero, it seems to
cause the fabric to collapse that path entirely, which causes the device
to bus stall and fatally reset.

This issue was identified specifically on sdm845-oneplus-fajita, so this
workaround is applied narrowly to SDM845's MDSS.

---
This RFC patch is a spiritual successor to the "Addressing stability
issues on SDM845 with the -next tree" series sent by David and Petr 6
months ago.

As Dmitry pointed out, the patch introduces leakages to the runtime PM
refcounting. In practice, this means that MDSS never actually gets
suspended, which is why the patch appeared to "fix" the issue.

The deeper root cause is that, when msm_mdss_disable() runs and unvotes
the mdp1-mem interconnect bandwidth, that seems to collapse the fabric
entirely and causes the bus stall -> hang -> reboot behaviour.

I've confirmed that a tiny non-zero peak bandwidth vote keeps the fabric
alive and avoids the issue.

Of course, this is still a fairly egregious hack, but it *does* allow
blanking to suspend and resume DSI + DPU + MDSS properly without the bus
stall.

Here's what I've validated with instrumentation:

 * DSI host disable, IRQ disable, PLL state save, host power-off, link
   clock disable, regulator disable, SFPB disable, and PHY disable all
   complete successfully before the fatal reset occurrs.
 * DPU runtime suspend also completes. The bandwidth accounting was
   checked and confirmed to reach runtime suspend with 0 refs, with no
   pending frame state.
 * The device survives through MDSS clock disabling and mdp0-mem
   zero voting, it's really just the mdp1-mem zero vote that is isolated
   as the cause of the stall + reset.

So, I'm not really sure where to go from here. I'm sure that this
workaround is not suitable for inclusion upstream as it still seems to
be papering over an underlying issue... But it's unclear to me if this is
some kind of hardware quirk on SDM845, a problem with the SDM845 DT
wiring, a driver issue, or something else entirely.

I'd appreciate any advice on how to further diagnose this issue and what
direction to take from here.

Kind regards,
-Sam

Link: https://lore.kernel.org/phone-devel/20251213-stability-discussion-v1-0-b25df8453526@ixit.cz/
Signed-off-by: Sam Day <me@samcday.com>
---
 drivers/gpu/drm/msm/msm_mdss.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index 9087c4b290db..c635380b2ac3 100644
--- a/drivers/gpu/drm/msm/msm_mdss.c
+++ b/drivers/gpu/drm/msm/msm_mdss.c
@@ -284,8 +284,12 @@ static int msm_mdss_disable(struct msm_mdss *msm_mdss)
 
 	clk_bulk_disable_unprepare(msm_mdss->num_clocks, msm_mdss->clocks);
 
-	for (i = 0; i < msm_mdss->num_mdp_paths; i++)
-		icc_set_bw(msm_mdss->mdp_path[i], 0, 0);
+	for (i = 0; i < msm_mdss->num_mdp_paths; i++) {
+		if (of_device_is_compatible(msm_mdss->dev->of_node, "qcom,sdm845-mdss") && i == 1)
+			icc_set_bw(msm_mdss->mdp_path[i], 0, 1);
+		else
+			icc_set_bw(msm_mdss->mdp_path[i], 0, 0);
+	}
 
 	if (msm_mdss->reg_bus_path)
 		icc_set_bw(msm_mdss->reg_bus_path, 0, 0);

---
base-commit: 5a66900afbd6b2a063eebad35294038a654de2b0
change-id: 20260627-rfc-sdm845-interconnect-collapse-workaround-ba1cf846ca3f

Best regards,
-- 
Sam Day <me@samcday.com>

Re: [PATCH RFC] drm/msm/mdss: keep mdp1-mem interconnect alive during suspend on SDM845

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Low] Unnecessary device tree string matching on every iteration due to missing short-circuit evaluation.

Pre-existing issues:
- [High] Silent failure on `-EPROBE_DEFER` for `mdp1-mem` prevents the SDM845 workaround from applying.
--

commit 25610098a6bc164e41324a820ebd766373a58240
Author: Sam Day <me@samcday.com>

drm/msm/mdss: keep mdp1-mem interconnect alive during suspend on SDM845

If the peak vote for mdp1-mem is allowed to drop to zero, it seems to
cause the fabric to collapse that path entirely, which causes the device
to bus stall and fatally reset.

> diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
> index 9087c4b290dba..c635380b2ac3c 100644
> --- a/drivers/gpu/drm/msm/msm_mdss.c
> +++ b/drivers/gpu/drm/msm/msm_mdss.c
[ ... ]
> @@ -284,8 +284,12 @@ static int msm_mdss_disable(struct msm_mdss *msm_mdss)
>  
>  	clk_bulk_disable_unprepare(msm_mdss->num_clocks, msm_mdss->clocks);
>  
> -	for (i = 0; i < msm_mdss->num_mdp_paths; i++)
> -		icc_set_bw(msm_mdss->mdp_path[i], 0, 0);
> +	for (i = 0; i < msm_mdss->num_mdp_paths; i++) {
> +		if (of_device_is_compatible(msm_mdss->dev->of_node, "qcom,sdm845-mdss") && i == 1)

[Severity: Low]
Does this code perform unnecessary device tree string matching on every
iteration?

In C, the logical AND operator evaluates left-to-right. Thus,
of_device_is_compatible() is called on the first iteration (i == 0),
despite i == 1 being false. Swapping the conditions to
i == 1 && of_device_is_compatible(...) would properly short-circuit
the expensive device tree string matching.

[Severity: High]
This isn't a bug introduced by this patch, but does the silent failure on
-EPROBE_DEFER for mdp1-mem prevent this SDM845 workaround from applying?

Looking at msm_mdss_parse_data_bus_icc_path():

drivers/gpu/drm/msm/msm_mdss.c:msm_mdss_parse_data_bus_icc_path() {
    ...
	path1 = devm_of_icc_get(dev, "mdp1-mem");
	if (!IS_ERR_OR_NULL(path1)) {
    ...
}

During device probe, if the interconnect provider for mdp1-mem is not yet
ready, devm_of_icc_get() returns ERR_PTR(-EPROBE_DEFER). The condition
!IS_ERR_OR_NULL(path1) handles this by silently skipping mdp1-mem rather
than returning -EPROBE_DEFER to defer the probe.

If this happens on SDM845, num_mdp_paths remains 1, meaning the newly added
workaround loop here in msm_mdss_disable() never reaches i == 1.

Consequently, the vote for mdp1-mem drops to zero when the interconnect core
syncs state, which triggers the bus stall and fatal reset that this patch is
explicitly trying to fix.

> +			icc_set_bw(msm_mdss->mdp_path[i], 0, 1);
> +		else
> +			icc_set_bw(msm_mdss->mdp_path[i], 0, 0);
> +	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260627-rfc-sdm845-interconnect-collapse-workaround-v1-1-608a38de3715@samcday.com?part=1

Re: [PATCH RFC] drm/msm/mdss: keep mdp1-mem interconnect alive during suspend on SDM845

[Konrad Dybcio]

On 6/27/26 2:18 PM, Sam Day via B4 Relay wrote:
> From: Sam Day <me@samcday.com>
> 
> If the peak vote for mdp1-mem is allowed to drop to zero, it seems to
> cause the fabric to collapse that path entirely, which causes the device
> to bus stall and fatally reset.

Which fabric? MMSS_NOC?

Can you experiment with setting keepalive = true/false on bcm_mmX
in drivers/interconnect/qcom/sdm845.c?

Konrad

Re: [PATCH RFC] drm/msm/mdss: keep mdp1-mem interconnect alive during suspend on SDM845

[Dmitry Baryshkov]

On Sat, Jun 27, 2026 at 10:18:45PM +1000, Sam Day via B4 Relay wrote:
> From: Sam Day <me@samcday.com>
> 
> If the peak vote for mdp1-mem is allowed to drop to zero, it seems to
> cause the fabric to collapse that path entirely, which causes the device
> to bus stall and fatally reset.
> 
> This issue was identified specifically on sdm845-oneplus-fajita, so this
> workaround is applied narrowly to SDM845's MDSS.
> 
> ---
> This RFC patch is a spiritual successor to the "Addressing stability
> issues on SDM845 with the -next tree" series sent by David and Petr 6
> months ago.
> 
> As Dmitry pointed out, the patch introduces leakages to the runtime PM
> refcounting. In practice, this means that MDSS never actually gets
> suspended, which is why the patch appeared to "fix" the issue.
> 
> The deeper root cause is that, when msm_mdss_disable() runs and unvotes
> the mdp1-mem interconnect bandwidth, that seems to collapse the fabric
> entirely and causes the bus stall -> hang -> reboot behaviour.
> 
> I've confirmed that a tiny non-zero peak bandwidth vote keeps the fabric
> alive and avoids the issue.
> 
> Of course, this is still a fairly egregious hack, but it *does* allow
> blanking to suspend and resume DSI + DPU + MDSS properly without the bus
> stall.

I'm a bit sceptical about this patch. The Lenovo Yoga C630 uses a
variant of SDM845. There I don't observe any issues with the MM itself.
But cluster suspend can cause issues there too. I suspect that there is
a missing vote (or undervote) on the CX or MX, which results in
suspend/resume crashes. And if that's true, then your patch does exactly
that - I think it will add an internal CX vote, which won't be dropped,
preventing CX collapse.

> 
> Here's what I've validated with instrumentation:
> 
>  * DSI host disable, IRQ disable, PLL state save, host power-off, link
>    clock disable, regulator disable, SFPB disable, and PHY disable all
>    complete successfully before the fatal reset occurrs.
>  * DPU runtime suspend also completes. The bandwidth accounting was
>    checked and confirmed to reach runtime suspend with 0 refs, with no
>    pending frame state.
>  * The device survives through MDSS clock disabling and mdp0-mem
>    zero voting, it's really just the mdp1-mem zero vote that is isolated
>    as the cause of the stall + reset.

Will it work if you suspend the MDSS (dropping all votes) and then
forcibly break the device suspend by returning an error from the later
stage?
> 
> So, I'm not really sure where to go from here. I'm sure that this
> workaround is not suitable for inclusion upstream as it still seems to
> be papering over an underlying issue... But it's unclear to me if this is
> some kind of hardware quirk on SDM845, a problem with the SDM845 DT
> wiring, a driver issue, or something else entirely.

I don't have a good advice here. Try disabling cluster idle node. If the
device still works, it's not a mdp1-mem.

> 
> I'd appreciate any advice on how to further diagnose this issue and what
> direction to take from here.
> 
> Kind regards,
> -Sam
> 
> Link: https://lore.kernel.org/phone-devel/20251213-stability-discussion-v1-0-b25df8453526@ixit.cz/
> Signed-off-by: Sam Day <me@samcday.com>

-- 
With best wishes
Dmitry