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

[Nabige Aala <nabige.aala@oss.qualcomm.com>]

On 9/17/2026 11:57 PM, Oleg Keri wrote:
> 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.

Hi Oleg,

Thanks for testing and the detailed report.

You are right. The root cause is that in patch 4/9,
dp_mode_ignore_reverse was applied to the reverse variable itself,
which caused it to suppress not just the DP_PHY_MODE write but also
the PD_CTL lane power-down selection. For a 2-lane reversed plug,
PD_CTL was programming the wrong lane pair as active, while
qmp_v8_configure_dp_phy() was still using the raw orientation for
the driver-enable registers. The two were no longer in agreement,
causing the link training failure you observed.

The fix decouples the two: reverse is now always the raw cable
orientation, and dp_mode_ignore_reverse is applied only to the
DP_PHY_MODE write, which is the only register that actually needs
to be fixed to 0x5c for Glymur regardless of orientation:

-     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);

-     if (reverse)
+     if (reverse && !cfg->dp_mode_ignore_reverse)
               writel(0x4c, qmp->dp_dp_phy + QSERDES_DP_PHY_MODE);
       else
               writel(0x5c, qmp->dp_dp_phy + QSERDES_DP_PHY_MODE);

I have verified this on both 2-lane and 4-lane in both orientations.

Regarding dp_mode_ignore_reverse for 4-lane: I have confirmed with
the glymur HPG guide DP_PHY_MODE must always be 0x5c for Glymur
regardless of orientation. The flag exists solely to suppress the
0x4c write. I will add this fix in the next revision v5.


Thanks,

Nabige Aala

> Thanks,
> Oleg