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

[Joonhoe Kim <26rote@gmail.com>]

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.

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?

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.

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.

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.

[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