Gly fix - #1746
Conversation
sauana
commented
Aug 25, 2026
…is initializing The Type-C mux switch guard only checked dp_powered_on, which is set in qmp_combo_dp_power_on(). However there is a race window between qmp_combo_dp_init() and qmp_combo_dp_power_on() during which dp_init_count is non-zero but dp_powered_on is still false. A Type-C orientation change arriving in this window would proceed with the mux switch while the DP PHY is mid-initialization, corrupting the PHY state. Extend the guard to also block the mux switch when dp_init_count is non-zero, covering the full period from dp_init through dp_power_on. link: https://lore.kernel.org/all/20260824-qcom-dp-typec-reconnect-fixes-v1-1-2825e5bf8a96@oss.qualcomm.com/ Signed-off-by: Saurabh Anand <saurabh.anand@oss.qualcomm.com>
…succeeds msm_dp_display_prepare_link() sets force_link_train = true before calling msm_dp_ctrl_on_link(). On success the flag was never cleared, so msm_dp_ctrl_prepare_stream_on() would unconditionally trigger a second link retrain even though the link was already trained. Clear force_link_train on the success path so that msm_dp_ctrl_prepare_stream_on() only retrains when the channel EQ check fails, as intended. Link:https://lore.kernel.org/all/20260824-qcom-dp-typec-reconnect-fixes-v1-2-2825e5bf8a96@oss.qualcomm.com/ Signed-off-by: Saurabh Anand <saurabh.anand@oss.qualcomm.com>
drm_dp_lttpr_count() returns 0 when no LTTPRs are detected and a negative value on error. The previous code passed the result directly to drm_dp_lttpr_init() without checking, which would call into the LTTPR transparency-mode setup with a zero or negative repeater count. Add an early return for lttpr_count <= 0 to skip the init entirely when there are no repeaters in the link, matching the expected usage of drm_dp_lttpr_init(). Link: https://lore.kernel.org/all/20260824-qcom-dp-typec-reconnect-fixes-v1-3-2825e5bf8a96@oss.qualcomm.com/ Signed-off-by: Saurabh Anand <saurabh.anand@oss.qualcomm.com>
…still plugged During a Type-C reconnect the AUX channel may report link-disconnected transiently while the physical cable is still present. The link training retry loop in msm_dp_ctrl_on_link() was aborting immediately on any msm_dp_aux_is_link_connected() failure, preventing the rate/lane downgrade path from running. When the display is known to be plugged (msm_dp_ctrl->plugged), an AUX link-disconnected status is likely a transient glitch rather than a true unplug. Allow the downgrade loop to continue in that case by requiring both conditions before breaking out of the retry loop: AUX reports disconnected and the display is not plugged. The plugged state is snapshotted from dp_display into msm_dp_ctrl just before msm_dp_ctrl_on_link() is called, so the retry loop has an accurate view of cable presence at the time link training started. Link: https://lore.kernel.org/all/20260824-qcom-dp-typec-reconnect-fixes-v1-4-2825e5bf8a96@oss.qualcomm.com/ Signed-off-by: Saurabh Anand <saurabh.anand@oss.qualcomm.com>
🔨 Build Failure Analysis — PR #1746PR: #1746
VerdictAll 3 merge conflicts are introduced by this PR when merging into the integration branch containing topic/tech/mm/drm. These are not compilation errors but integration conflicts. 📎 Detailed analysis: Full report |
🔨 Build Failure Analysis — PR #1746PR: #1746
VerdictAll 3 merge conflicts are introduced by this PR's changes conflicting with the existing 📎 Detailed analysis: Full report |
PR #1746 — validate-patchPR: #1746
Final Summary
|
PR #1746 — checker-log-analyzerPR: #1746
Detailed report: Full report
|