phy: qcom: qmp-combo: Glymur USB Gen2 fails on one port (chip rev 2.0)

[Burke Cates]

Hi,

Could someone at Qualcomm check the Glymur USB43DP USB tables
(glymur_usb43dp_*, introduced by 5b289913959b "phy: qualcomm:
qmp-combo: Update QMP PHY with Glymur settings") against the
supported production settings for chip revision 2.0 and later, and
post updated tables if needed? Is revision-specific or per-port
tuning expected?

In short: on a retail ASUS Zenbook A16, USB Gen2 fails to enumerate
on one of its two Type-C ports with the mainline tables, while
Windows runs Gen2 on that port, and local changes to the Gen2
receiver/lane and common PLL settings make it enumerate. I'd be happy
to test proposed settings on both ports and report enumeration, DP
and suspend/resume results. Details follow.

The machine is a retail ASUS Zenbook A16 (UX3607OA, Snapdragon X2
Elite Extreme, SoC ID 662, revision 2.0, BIOS UX3607OA.312):

  C1 (left, rear/display-adjacent): Gen1 and Gen2 enumerate
  C2 (left, front/user-adjacent):   Gen1 works; Gen2 fails

The tested Gen2 device is a Realtek RTL8159 10G NIC. Two different
C-C cables reproduce the C2 problem. The same adapter enumerates at
Gen2 on C1 and on the Type-A port. Linux applies the same USB tables
to both Type-C combo PHYs.

On C2 the adapter either enumerates at Gen2 and resets/disconnects,
or never enumerates, looping on -71 ("Device not responding to setup
address"). For context, this October 22 excerpt is from the earlier
flapping case, before UCSI was started in the initrd:

  [  307.056050] r8152-cfgselector 6-1: reset SuperSpeed Plus Gen 2x1 USB device number 3 using xhci-hcd
  [  307.136539] r8152-cfgselector 6-1: can't restore configuration #1 (error=-71)
  [  307.136705] r8152 6-1:1.0 enu1: Get ether addr fail
  [  307.651093] r8152-cfgselector 6-1: USB disconnect, device number 3

The failure also reproduced with UCSI running in the initrd. In an
October 24 A/B, keeping the cable and orientation the same, the
unchanged USB tables failed to enumerate on C2 with the -71 setup
address loop. Local changes in the Gen2 receiver/lane and common PLL
settings made it enumerate at 10000M, with no -71 in that capture.
Windows programs different values on this hardware. The A/B suggests
a settings issue but does not establish which programming is correct
for production hardware.

With those local changes, C2 enumerated at Gen2 with both cables,
in both orientations and after s2idle. C1 still enumerated at Gen2;
DP still trained four lanes at HBR on both Type-C ports. I haven't
isolated which part of the settings change is necessary.

This is an enumeration result, not a throughput or complete NIC fix.
On the changed kernel the RTL8159 still fails to get Ethernet carrier
on both C1 and C2, and cfgselector resets recur. That is being tracked
separately; I have no Linux iperf result with the PHY changes.

Under Windows the same NIC negotiates Gen2 on C2 (USBView: "Device
Bus Speed: SuperSpeedPlus") and carries about 5 Gbit/s each way in
iperf3 (about 6.5 Gbit/s in total bidirectionally), so the port and
cable are fine at Gen2 there.

These tests used v7.3-rc5 with out-of-tree Glymur platform/board
patches, including DP PHY support. They were not on an unmodified
mainline kernel.