Re: [PATCH v7 00/35] drm/msm/dp: Add MST support for MSM chipsets

[Yongxing Mou <yongxing.mou@oss.qualcomm.com>]

On 11/8/2026 9:14 AM, Joonhoe Kim wrote:
> I tested this series on the Lenovo Y700 Gen 5 (TB323FU, Kaanapali):
> DP0 over USB-C (pmic_glink altmode) to a dual-screen monitor with a
> built-in Realtek MST hub (two 1920x1200@60 sinks), with the built-in
> dual-DSI 1904x3040 panel also on. The base is Linux v7.3, not
> linux-next, with Dmitry's "drm: handle IRQ_HPD events correctly" v8
> [1] (the cover letter lists v5) and this series. A few hunks were
> adapted to other patches I carry. On hpd v8 the second hunk of 34/35 is
> not needed, because msm_dp_bridge_hpd_notify() already handles the
> plug before IRQ_HPD.
> 
> With three local changes, both screens show separate desktops next to
> the built-in panel and come back after s2idle.
> 
> 1. The plugged_lock / mode_config.mutex deadlock that Sashiko reported
>     on 32/35 happens at boot with the monitor attached. The stacks are
>     in my reply there [2]. I dropped 32/35.
> 
>  From the cover letter:
> 
>> With 4x4K monitors, due to lack of layer mixers that combination will not
>> work but this can be supported as well after some rework on the DPU side.
> 
Thanks , will  dropped in the next version, same as you did locally. It 
not needed
> 2. With all three displays on, the commit for the second MST screen
>     fails:
> 
>     [drm:_dpu_rm_check_lm_and_get_connected_blks] [dpu error]LM_4, invalid DSPP_-1
>     [drm:_dpu_rm_check_lm_and_get_connected_blks] [dpu error]LM_5, invalid DSPP_-1
>     [drm:_dpu_rm_check_lm_and_get_connected_blks] [dpu error]LM_6, invalid DSPP_-1
>     [drm:_dpu_rm_check_lm_and_get_connected_blks] [dpu error]LM_7, invalid DSPP_-1
>     [drm:_dpu_rm_make_reservation] [dpu error]unable to find appropriate mixers
>     [drm:dpu_rm_reserve] [dpu error]failed to reserve hw resources: -119
> 
>     The compositor sets a CTM on every CRTC, identity when unused
>     (adding or removing a CTM later forces a modeset that reassigns
>     resources), so each CRTC asks for one DSPP per LM. Kaanapali has
>     DSPPs only on LM 0-3. The built-in panel takes LM 0-1, and the
>     first MST screen takes LM 2-3 because 1920 > MAX_HDISPLAY_SPLIT
>     (1080), which leaves no DSPP for the second MST screen.
> 
>     This is a DPU topology issue rather than an MST one; MST just makes
>     three active CRTCs easy to reach. Locally, a CRTC that needs DSPPs
>     uses one LM up to max_mixer_width (2560) instead of
>     MAX_HDISPLAY_SPLIT, and the two MST screens then get LM 2 and LM 3.
>     This touches the same decision as Mahadevan's LM rework [3], which
>     drops max_mixer_width, so I have not sent it as a patch.
> 
>     Mahadevan, should a CRTC that needs DSPPs prefer a single LM
>     whenever the mode fits in one, on top of your rework?
> 
Yes, this issue will be solved in another series.
> 3. s2idle with both MST screens active hangs in resume. The console is
>     suspended; the printk ring in the RAM dump shows devices resuming,
>     nothing from DRM, and then "watchdog0: pretimeout event". The
>     rtcwake task is stuck in an AUX transfer in resume, while the MST
>     stream is re-enabled:
> 
>      wait_for_completion_timeout
>      msm_dp_aux_cmd_fifo_tx
>      msm_dp_aux_transfer
>      drm_dp_dpcd_access
>      drm_dp_dpcd_write
>      drm_dp_dpcd_write_data
>      drm_dp_dpcd_write_payload
>      drm_dp_create_payload_at_dfp
>      drm_dp_add_payload_part1
>      msm_dp_mst_stream_enable
>      dpu_encoder_mst_atomic_enable
>      drm_atomic_helper_commit_encoder_bridge_enable
>      drm_atomic_helper_commit_modeset_enables
>      ...
>      drm_atomic_helper_resume
>      drm_mode_config_helper_resume
>      msm_kms_pm_complete
>      dpm_complete
> 
>     Several kworkers wait for a modeset lock in
>     drm_self_refresh_helper_entry_work().
> 
>     At the hang active_stream_cnt is 0 but link_ready is 1, so
>     msm_dp_display_prepare_link() returns early and the payload write
>     goes over a link that system suspend has powered down
>     (aux->retry_cnt, the count of consecutive AUX failures, was 107).
>     While mst_active is set,
>     msm_dp_mst_stream_post_disable() does not unprepare the link after
>     the last stream, so nothing tears it down for system suspend.
> 
>     The series also does not call drm_dp_mst_topology_mgr_suspend() or
>     drm_dp_mst_topology_mgr_resume(); i915, nouveau and amdgpu call
>     them around their atomic suspend and resume.
> 
>     Locally, the DP system-suspend callback calls
>     drm_dp_mst_topology_mgr_suspend() and, when MST is active, tears
>     the link down through the unprepare path (clearing link_ready)
>     before pm_runtime_force_suspend(). On resume, after
>     pm_runtime_force_resume(), it re-inits the PHY and AUX and calls
>     drm_dp_mst_topology_mgr_resume(mgr, true); if that fails, it turns
>     MST off and sends a hotplug event. With that, 3 of 3 RTC-woken
>     s2idle cycles resumed with both screens on. After the third the
>     topology was rebuilt (the MST connectors came back under new
>     names). I can send this as a patch on top of the next version of
>     this series if you want it.
> 
Please feel free to send it. I tried to add these functions, but I 
didn't have enough time to fully test the code, so I removed them before 
sending the new version.
> Unplug and replug mostly works. When it failed (3 of 6 sequences),
> the hub had dropped HPD or stopped answering AUX right after the
> plug, and one or both screens stayed dark; the stock Android kernel
> shows similar failures with this monitor.
> 
Actually, link training is not always stable. It may be related to the 
dongle, and we need to improve it further.
> Not tested: daisy chain, 4K, audio over MST (no audio sink here).
> If it helps, I can test the next version of this series on this
> device.
> 
Thank you for all the testing and feedback. These are all real issues. 
Although we may not be able to fix all of them in the next release, your 
feedback is really helpful.
> [1] https://lore.kernel.org/all/20261024-hpd-irq-events-v8-0-6ee949e7a384@oss.qualcomm.com/
> [2] https://lore.kernel.org/all/20261108010724.4061-1-26rote@gmail.com/
> [3] https://lore.kernel.org/all/20261008-lm_fixes_final-v4-0-fa986071c3c1@oss.qualcomm.com/
> 
> Thanks,
> Joonhoe Kim