SM8250 USB-C DP alt mode: DP AUX times out in reversed (CC2) cable orientation

SM8250 USB-C DP alt mode: DP AUX times out in reversed (CC2) cable orientation

[BurningHoryd]

Hi,

I'm chasing a DisplayPort-over-USB-C alt mode bug on an SM8250 (Retroid
Pocket 5) board and would appreciate a pointer, as it looks like it may
be in the nb7vpq904m redriver or the qmp-combo DP AUX path.

Hardware / software
-------------------
- SoC: SM8250, qcom,sm8250-qmp-usb3-dp-phy combo PHY (88e8000.phy)
- USB-C redriver: onnn,nb7vpq904m (i2c, typec mux/switch)
- External sink: VITURE Beast XR glasses, 4-lane DP-only (pin assignment
  C, TYPEC_DP_STATE_C), HBR2, 1920x1200@120
- Kernel: v7.2 base, plus three local qmp-combo patches that are the
  subject of a separate downstream review (keep usb_init_count across the
  DP-only mux switch / skip USB3 power on/off while already in DP-only /
  the residual pipe_clk-in-common timeout hunk). The AUX failure below
  reproduces with those applied; I have not been able to bisect against
  pristine v7.2 because plain v7.2 has an unrelated regression on this
  board (qcom_pmic_typec now requires connector/vbus-supply, which the
  board DT lacks, so DP alt mode never powers up at all without a
  separate DT fix).

Symptom
-------
Normal cable orientation: DP alt mode works perfectly - link trains,
1920x1200@120, stable.

Reversed cable orientation (Type-C orientation = reverse / CC2): DP never
comes up. The DP alt mode HPD notification reaches msm_dp
(msm_dp_bridge_hpd_notify status=1), msm_dp starts bring-up
(msm_dp_display_host_phy_init, phy_init OK), but the very first DPCD read
- SINK_COUNT at 0x200 in msm_dp_hpd_plug_handle - polls for ~4 seconds
and never gets a reply:

  [drm:msm_dp_hpd_plug_handle] Before, sink_count=0
  [drm:msm_dp_display_host_phy_init] core_init=1 phy_init=1
  ... ~4 s ...
  [drm:msm_dp_hpd_plug_handle] After, sink_count=0
  [drm:msm_dp_bridge_detect] aux link status: 0
  [drm:msm_dp_bridge_detect] failed to read caps

msm_dp then gives up and the connector stays disconnected. Link training
is never reached. Stock Android on the exact same hardware works in both
orientations, so this is a driver-side issue, not a board/silicon limit.

What I've verified (instrumented kernel, dev_info in the phy + nb7 set
paths)
------------------------------------------------------------------------
- It is NOT a state / refcount / mux ordering artifact: a clean
  reverse-first plug (fresh boot, reversed cable plugged before any
  normal plug) fails identically.
- On the reversed plug, in order:
  * qmp_combo_typec_switch_set(REVERSE) runs, qmp_combo_com_init(force)
    writes QPHY_V3_DP_COM_TYPEC_CTRL = SW_PORTSELECT_MUX|SW_PORTSELECT_VAL
    (0x3).
  * nb7vpq904m_set() runs for TYPEC_DP_STATE_C with reverse=1, writes
    AUX_CC_REG (0x09) = 0x1.
  * qmp_combo_typec_mux_set() does the DP-only transition, com_init(force)
    again (mode=DP_ONLY, TYPEC_CTRL=0x3) - this happens AFTER the nb7 DP
    config.
  * qmp_combo_dp_init() -> qmp_v4_dp_aux_init() runs.
  So the PHY and the redriver are both configured for reverse, in a sane
  order, before msm_dp attempts AUX. And AUX still times out.
- qmp-combo has no DP-AUX orientation register that I can find - AUX
  orientation on this design is entirely nb7vpq904m AUX_CC_REG.
- Inverting SW_PORTSELECT_VAL and/or nb7 AUX_CC (making the registers
  bit-identical to the working normal-orientation case) does not help -
  reverse still fails.
- Forcing repeated full qmp_combo_com_exit/com_init cycles during the
  DPCD poll window does not help.

The one thing that changes anything
-----------------------------------
I added a knob to override GEN_DEV_SETTINGS OP_MODE in the nb7
TYPEC_DP_STATE_C branch (it normally hard-codes
GEN_DEV_SET_OP_MODE_DP_4LANE):

  OP_MODE = DP_4LANE (2)      -> DPCD read: 0 successes (many tries)
  OP_MODE = DP_CC1   (1)      -> DPCD read: 0 successes
  OP_MODE = DP_CC2   (0)      -> DPCD read succeeds intermittently
                                 (~1 in 4 plugs, sink_count 0->1,
                                 connector goes connected briefly).
                                 Link training then fails, which is
                                 expected since DP_CC2 is a 2-lane
                                 op-mode and the source is driving 4.
  OP_MODE = 3, 4             -> 0 successes

DP_CC2 is the "flipped orientation" op-mode. It is the only setting that
ever gets an AUX transaction through in reversed orientation. That
strongly suggests the nb7vpq904m SBU/AUX switch is not being put into the
flipped routing for a 4-lane DP session - AUX_CC_REG alone does not seem
to do it in DP_4LANE op-mode - but I don't have the full NB7VPQ904M
register map to confirm (the public datasheets are image-only).

Questions
---------
1. Is nb7vpq904m's DP_4LANE path missing SBU/AUX orientation handling
   that the DP_CC1/DP_CC2 paths get implicitly from the op-mode? Should
   AUX_CC_REG be sufficient in DP_4LANE mode, or is another
   GEN_DEV_SETTINGS / AUX register bit needed for CC2?
2. Is there an SM8250 qmp-combo DP-AUX orientation step that mainline is
   missing (something the downstream PHY driver does for a reversed
   4-lane DP session)?
3. Any known-good reference for reversed-orientation 4-lane DP on an
   SM8250 + nb7vpq904m board?

I can share the full instrumented traces (normal vs reverse) and test the
register map if someone can point at the right bits. Happy to turn a fix
into a proper patch.

Thanks,
BurningHoryd

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: SM8250 USB-C DP alt mode: DP AUX times out in reversed (CC2) cable orientation

[Neil Armstrong]

On 9/7/26 00:52, BurningHoryd wrote:
> Hi,
> 
> I'm chasing a DisplayPort-over-USB-C alt mode bug on an SM8250 (Retroid
> Pocket 5) board and would appreciate a pointer, as it looks like it may
> be in the nb7vpq904m redriver or the qmp-combo DP AUX path.
> 
> Hardware / software
> -------------------
> - SoC: SM8250, qcom,sm8250-qmp-usb3-dp-phy combo PHY (88e8000.phy)
> - USB-C redriver: onnn,nb7vpq904m (i2c, typec mux/switch)
> - External sink: VITURE Beast XR glasses, 4-lane DP-only (pin assignment
>    C, TYPEC_DP_STATE_C), HBR2, 1920x1200@120
> - Kernel: v7.2 base, plus three local qmp-combo patches that are the
>    subject of a separate downstream review (keep usb_init_count across the
>    DP-only mux switch / skip USB3 power on/off while already in DP-only /
>    the residual pipe_clk-in-common timeout hunk). The AUX failure below
>    reproduces with those applied; I have not been able to bisect against
>    pristine v7.2 because plain v7.2 has an unrelated regression on this
>    board (qcom_pmic_typec now requires connector/vbus-supply, which the
>    board DT lacks, so DP alt mode never powers up at all without a
>    separate DT fix).
> 
> Symptom
> -------
> Normal cable orientation: DP alt mode works perfectly - link trains,
> 1920x1200@120, stable.
> 
> Reversed cable orientation (Type-C orientation = reverse / CC2): DP never
> comes up. The DP alt mode HPD notification reaches msm_dp
> (msm_dp_bridge_hpd_notify status=1), msm_dp starts bring-up
> (msm_dp_display_host_phy_init, phy_init OK), but the very first DPCD read
> - SINK_COUNT at 0x200 in msm_dp_hpd_plug_handle - polls for ~4 seconds
> and never gets a reply:
> 
>    [drm:msm_dp_hpd_plug_handle] Before, sink_count=0
>    [drm:msm_dp_display_host_phy_init] core_init=1 phy_init=1
>    ... ~4 s ...
>    [drm:msm_dp_hpd_plug_handle] After, sink_count=0
>    [drm:msm_dp_bridge_detect] aux link status: 0
>    [drm:msm_dp_bridge_detect] failed to read caps
> 
> msm_dp then gives up and the connector stays disconnected. Link training
> is never reached. Stock Android on the exact same hardware works in both
> orientations, so this is a driver-side issue, not a board/silicon limit.
> 
> What I've verified (instrumented kernel, dev_info in the phy + nb7 set
> paths)
> ------------------------------------------------------------------------
> - It is NOT a state / refcount / mux ordering artifact: a clean
>    reverse-first plug (fresh boot, reversed cable plugged before any
>    normal plug) fails identically.
> - On the reversed plug, in order:
>    * qmp_combo_typec_switch_set(REVERSE) runs, qmp_combo_com_init(force)
>      writes QPHY_V3_DP_COM_TYPEC_CTRL = SW_PORTSELECT_MUX|SW_PORTSELECT_VAL
>      (0x3).
>    * nb7vpq904m_set() runs for TYPEC_DP_STATE_C with reverse=1, writes
>      AUX_CC_REG (0x09) = 0x1.
>    * qmp_combo_typec_mux_set() does the DP-only transition, com_init(force)
>      again (mode=DP_ONLY, TYPEC_CTRL=0x3) - this happens AFTER the nb7 DP
>      config.
>    * qmp_combo_dp_init() -> qmp_v4_dp_aux_init() runs.
>    So the PHY and the redriver are both configured for reverse, in a sane
>    order, before msm_dp attempts AUX. And AUX still times out.
> - qmp-combo has no DP-AUX orientation register that I can find - AUX
>    orientation on this design is entirely nb7vpq904m AUX_CC_REG.
> - Inverting SW_PORTSELECT_VAL and/or nb7 AUX_CC (making the registers
>    bit-identical to the working normal-orientation case) does not help -
>    reverse still fails.
> - Forcing repeated full qmp_combo_com_exit/com_init cycles during the
>    DPCD poll window does not help.
> 
> The one thing that changes anything
> -----------------------------------
> I added a knob to override GEN_DEV_SETTINGS OP_MODE in the nb7
> TYPEC_DP_STATE_C branch (it normally hard-codes
> GEN_DEV_SET_OP_MODE_DP_4LANE):
> 
>    OP_MODE = DP_4LANE (2)      -> DPCD read: 0 successes (many tries)
>    OP_MODE = DP_CC1   (1)      -> DPCD read: 0 successes
>    OP_MODE = DP_CC2   (0)      -> DPCD read succeeds intermittently
>                                   (~1 in 4 plugs, sink_count 0->1,
>                                   connector goes connected briefly).
>                                   Link training then fails, which is
>                                   expected since DP_CC2 is a 2-lane
>                                   op-mode and the source is driving 4.
>    OP_MODE = 3, 4             -> 0 successes
> 
> DP_CC2 is the "flipped orientation" op-mode. It is the only setting that
> ever gets an AUX transaction through in reversed orientation. That
> strongly suggests the nb7vpq904m SBU/AUX switch is not being put into the
> flipped routing for a 4-lane DP session - AUX_CC_REG alone does not seem
> to do it in DP_4LANE op-mode - but I don't have the full NB7VPQ904M
> register map to confirm (the public datasheets are image-only).
> 
> Questions
> ---------
> 1. Is nb7vpq904m's DP_4LANE path missing SBU/AUX orientation handling
>     that the DP_CC1/DP_CC2 paths get implicitly from the op-mode? Should
>     AUX_CC_REG be sufficient in DP_4LANE mode, or is another
>     GEN_DEV_SETTINGS / AUX register bit needed for CC2?
> 2. Is there an SM8250 qmp-combo DP-AUX orientation step that mainline is
>     missing (something the downstream PHY driver does for a reversed
>     4-lane DP session)?
> 3. Any known-good reference for reversed-orientation 4-lane DP on an
>     SM8250 + nb7vpq904m board?

This means the nb7vpq904m is _not_ responsible for the AUX swapping, other
boards have the wcd9395 or the fsa4480 in the middle to use the AUX line
for the USB-C Alternate Audio support, and does the swap.

Could you check in the vendor tree if there's any reference to those ?

Neil

> 
> I can share the full instrumented traces (normal vs reverse) and test the
> register map if someone can point at the right bits. Happy to turn a fix
> into a proper patch.
> 
> Thanks,
> BurningHoryd


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: SM8250 USB-C DP alt mode: DP AUX times out in reversed (CC2) cable orientation

[BurningHoryd]

On 9/7/26 08:40, Neil Armstrong wrote:
> This means the nb7vpq904m is _not_ responsible for the AUX swapping, other
> boards have the wcd9395 or the fsa4480 in the middle to use the AUX line
> for the USB-C Alternate Audio support, and does the swap.
>
> Could you check in the vendor tree if there's any reference to those ?

Checked Retroid's downstream Android DT for this board. There is an
FSA4480, plus a GPIO AUX switch, and my mainline port models neither.

1. fsa4480@43, on the same I2C controller as the redriver:

     i2c@884000 {
         fsa4480@43 {
             compatible = "qcom,fsa4480-i2c";
             reg = <0x43>;
         };
         redriver@1c {                 /* nb7vpq904m equivalent */
             compatible = "onnn,redriver";
             status = "disabled";
         };
     };

   The only node that references it is the ASoC machine driver
   (qcom,kona-asoc-snd, via "fsa4480-i2c-handle") - so downstream it is
   used for the USB-C analog-audio / MBHC SBU routing, not by the DP
   driver. The codec is a wcd9385, no USBSS block, so no wcd9395 here.

2. The downstream DP driver does its own AUX orientation over GPIO:

     &dp_display {
         qcom,dp-gpio-aux-switch;
         qcom,aux-sel-gpio    = <&tlmm 8  0>;
         qcom,aux-en-gpio     = <&tlmm 9  0>;
         qcom,usbplug-cc-gpio = <&tlmm 65 0>;
     };

   TLMM 9 there is the same pin my mainline DT currently hands to the
   nb7vpq904m as "enable-gpios", so that assignment is likely wrong, and
   TLMM 8 (the orientation select) is not wired up in my port at all.

3. The redriver (onnn,redriver @ 0x1c, same I2C address as the
   nb7vpq904m on my board) is left status = "disabled" downstream.

So the SBU / DP-AUX orientation switch on this board looks like a
discrete GPIO-controlled analog mux (TLMM 8 select, TLMM 9 enable), and
my port is missing it - I modeled the I2C redriver as the
orientation-switch instead, which is why poking its AUX_CC_REG did
nothing and only the DP_CC2 (pair-swapping, 2-lane) op-mode ever got an
AUX transaction through in reverse.

Does this look like a job for gpio-sbu-mux
(drivers/usb/typec/mux/gpio-sbu-mux.c) - a node with
select-gpios = <&tlmm 8>, enable-gpios = <&tlmm 9>, orientation-switch +
mode-switch, wired to the connector - with the nb7vpq904m kept as
retimer-switch only (or dropped, since downstream disables it)? Or is
the FSA4480 in the DP AUX path as well, making fsa,fsa4480 the right
orientation-switch to add?

I'll wire up gpio-sbu-mux and come back with reverse/normal traces
unless that's the wrong direction.

Thanks,
BurningHoryd

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: SM8250 USB-C DP alt mode: DP AUX times out in reversed (CC2) cable orientation

[Neil Armstrong]

On 9/7/26 18:26, BurningHoryd wrote:
> On 9/7/26 08:40, Neil Armstrong wrote:
>> This means the nb7vpq904m is _not_ responsible for the AUX swapping, other
>> boards have the wcd9395 or the fsa4480 in the middle to use the AUX line
>> for the USB-C Alternate Audio support, and does the swap.
>>
>> Could you check in the vendor tree if there's any reference to those ?
> 
> Checked Retroid's downstream Android DT for this board. There is an
> FSA4480, plus a GPIO AUX switch, and my mainline port models neither.
> 
> 1. fsa4480@43, on the same I2C controller as the redriver:
> 
>       i2c@884000 {
>           fsa4480@43 {
>               compatible = "qcom,fsa4480-i2c";
>               reg = <0x43>;
>           };
>           redriver@1c {                 /* nb7vpq904m equivalent */
>               compatible = "onnn,redriver";
>               status = "disabled";
>           };
>       };
> 
>     The only node that references it is the ASoC machine driver
>     (qcom,kona-asoc-snd, via "fsa4480-i2c-handle") - so downstream it is
>     used for the USB-C analog-audio / MBHC SBU routing, not by the DP
>     driver. The codec is a wcd9385, no USBSS block, so no wcd9395 here.
> 
> 2. The downstream DP driver does its own AUX orientation over GPIO:
> 
>       &dp_display {
>           qcom,dp-gpio-aux-switch;
>           qcom,aux-sel-gpio    = <&tlmm 8  0>;
>           qcom,aux-en-gpio     = <&tlmm 9  0>;
>           qcom,usbplug-cc-gpio = <&tlmm 65 0>;
>       };
> 
>     TLMM 9 there is the same pin my mainline DT currently hands to the
>     nb7vpq904m as "enable-gpios", so that assignment is likely wrong, and
>     TLMM 8 (the orientation select) is not wired up in my port at all.
> 
> 3. The redriver (onnn,redriver @ 0x1c, same I2C address as the
>     nb7vpq904m on my board) is left status = "disabled" downstream.
> 
> So the SBU / DP-AUX orientation switch on this board looks like a
> discrete GPIO-controlled analog mux (TLMM 8 select, TLMM 9 enable), and
> my port is missing it - I modeled the I2C redriver as the
> orientation-switch instead, which is why poking its AUX_CC_REG did
> nothing and only the DP_CC2 (pair-swapping, 2-lane) op-mode ever got an
> AUX transaction through in reverse.
> 
> Does this look like a job for gpio-sbu-mux
> (drivers/usb/typec/mux/gpio-sbu-mux.c) - a node with
> select-gpios = <&tlmm 8>, enable-gpios = <&tlmm 9>, orientation-switch +
> mode-switch, wired to the connector - with the nb7vpq904m kept as
> retimer-switch only (or dropped, since downstream disables it)? Or is
> the FSA4480 in the DP AUX path as well, making fsa,fsa4480 the right
> orientation-switch to add?

Yes if it's a discrete SBU mux, gpio-sbu-mux was designed for that, and
keep the nb7vpq904m and just drop the SBU link to the redriver and replace
it with a link to the SBU mux instead.

Neil

> 
> I'll wire up gpio-sbu-mux and come back with reverse/normal traces
> unless that's the wrong direction.
> 
> Thanks,
> BurningHoryd


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: SM8250 USB-C DP alt mode: DP AUX times out in reversed (CC2) cable orientation

[BurningHoryd]

On 9/7/26 18:35, Neil Armstrong wrote:
> Yes if it's a discrete SBU mux, gpio-sbu-mux was designed for that, and
> keep the nb7vpq904m and just drop the SBU link to the redriver and replace
> it with a link to the SBU mux instead.

That fixed it. A gpio-sbu-mux node on TLMM 8 (select) / TLMM 9 (enable),
the connector's SBU graph endpoint moved from the nb7vpq904m to it, and
the nb7vpq904m's enable-gpios dropped (TLMM 9 is the mux enable, not the
redriver enable). nb7vpq904m stays as the SS retimer-switch.

Reversed orientation now brings DP up reliably - one normal plug and
three reversed re-plugs, all four train to 4 lanes and stay connected,
no more DPCD read timeout. Normal orientation is unchanged.

This board (Retroid Pocket 5) isn't upstream yet, so the fix lands
downstream for now, but thanks a lot for the quick pointer - "nb7vpq904m
alone doesn't switch SBU" was exactly the piece I was missing.

BurningHoryd

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy