[PATCH v4 4/9] phy: qualcomm: qmp-combo: Add hardware-specific DP PHY config fields

[Oleg Keri]

Hi Nabige,

On Tue, Sep 08, 2026, Nabige Aala wrote:
> Update qmp_combo_configure_dp_mode() to honor dp_mode_ignore_reverse,
> so Glymur can bypass TypeC orientation-based lane reversal.

This breaks 2-lane DP with a reversed plug on a Lenovo Yoga Slim 7x
Gen 11 (Glymur), with the whole v4 series on next-20260916.

With dp_mode_ignore_reverse set, qmp_combo_configure_dp_mode() always
programs the normal side (DP_PHY_MODE 0x5c, lane 2/3 power bits in
DP_PHY_PD_CTL), while qmp_v8_configure_dp_phy() still follows the real
orientation and enables TXA for a reversed plug. With fewer than four
lanes the two no longer match.

On a 2-lane DP + USB3 dock (HBR2, one LTTPR) the reversed plug passes
clock recovery and then never reaches channel EQ: the LTTPR reports
CR_DONE on both lanes but never EQ_DONE or SYMBOL_LOCKED, walks its
pre-emphasis request up to level 3 at swing level 0, and then clock
recovery is lost. All four attempts end the same way:

  [drm:msm_dp_ctrl_link_train_1_2] *ERROR* link training #2 on phy 1 failed. ret=-110
  [drm:msm_dp_ctrl_setup_main_link] *ERROR* link training of LTTPR(s) failed. ret=-110
  [drm:msm_dp_display_atomic_enable] *ERROR* Failed link training (rc=-104)

The same dock trains at once with the plug the other way round. UCSI
and pmic_glink_altmode report the same orientation in both cases, so
the orientation itself is right.

Ignoring the orientation only when all four lanes carry DP fixes it
here, both orientations train:

-	bool reverse = (qmp->orientation == TYPEC_ORIENTATION_REVERSE) &&
-		       !cfg->dp_mode_ignore_reverse;
 	const struct phy_configure_opts_dp *dp_opts = &qmp->dp_opts;
+	bool reverse = (qmp->orientation == TYPEC_ORIENTATION_REVERSE) &&
+		       !(cfg->dp_mode_ignore_reverse && dp_opts->lanes == 4);

I have no 4-lane sink to check whether 0x5c is really needed for a
reversed 4-lane link; could you say what the flag is for?

Separately, on 7/9: LN0/LN1_DRV_LVL is now looked up from v/p levels,
but only in qmp_v8_configure_dp_clocks(), i.e. at power-on when both
are zero. Level changes during training go through configure_dp_tx(),
which does not touch these registers, so they stay at the [0][0] entry
(0x02 at HBR2) where the old code had 0x1f. I can test a v5 on this
machine.

Thanks,
Oleg