glymur eDP PHY (v8): link trains only at HBR3, all lower rates fail

glymur eDP PHY (v8): link trains only at HBR3, all lower rates fail

[Jesse Casco]

Hi Abel,

On an ASUS Zenbook A16 (UX3607OA, Snapdragon X2 Elite Extreme) the internal
eDP panel never comes up on mainline. It is the link rate: the v8 eDP PHY
appears to bring up a usable link only at HBR3.

Tested on linux-next next-20260713, next-20260803 and next-20260807, where
phy-qcom-edp.c is byte-identical -- so not a recent regression, and the May
2026 series (eDP low-vdiff LDO config, unified swing/pre-emphasis tables,
eDP/DP mode switch) is present in the tree tested here. The sweep below is
from next-20260803; the machine has since run next-20260807 as its daily
driver, where HBR3 still trains every boot.

PHY: phy@faac00, "qcom,glymur-dp-phy". Panel: SDC ATNA60HR07-0.

Rate sweep. Same kernel, same DTB, same PHY driver; only the requested link
rate forced (one line in msm_dp_panel_read_dpcd(), msm rebuilt as a module
between boots). Four lanes throughout, which the sink and the DT both allow:

  link rate     clock recovery (TPS1)   equalization (TPS2/3)   result
  1620 (RBR)    FAIL -110               -                       no link
  2700 (HBR)    FAIL -110               -                       no link
  5400 (HBR2)   pass                    FAIL -110               no link
  8100 (HBR3)   pass                    pass                    panel lights

HBR3 trains on the first attempt, every boot. At HBR2 clock recovery succeeds
and the sink then requests voltage swing 0 / pre-emphasis 1 on all four lanes
and never reports EQ done, through the full retry budget, with the driver
programming exactly what is asked each time. At HBR and RBR clock recovery
itself never completes.

Why the panel never comes up: the sink advertises HBR2 as its maximum, so msm
correctly selects the one rate that half-works.

  DPCD 0x001 MAX_LINK_RATE           = 0x00
  DPCD 0x00e TRAINING_AUX_RD_INTERVAL= 0x84   (ext receiver caps present)
  DPCD 0x2201 ext MAX_LINK_RATE      = 0x14   (HBR2)
  DPCD 0x010..0x01f SUPPORTED_LINK_RATES = 1.62 / 2.70 / 5.40 Gbps, no more
  DPCD 0x002 MAX_LANE_COUNT          = 0xc4   (4 lanes, TPS3, enhanced framing)

That advertised maximum does not close against the panel's own preferred
timing: 2880x1800 @ 120.000169 Hz, pixel clock 709.633 MHz, EDID declaring 10
bits per primary colour.

  10 bpc -> 21.29 Gbps   HBR2 4-lane = 17.28 Gbps  123%  does not fit
                         HBR3 4-lane = 25.92 Gbps   82%  fits
   8 bpc -> 17.03 Gbps   HBR2                      98.6% fits, barely

So at the depth it advertises, this panel's preferred mode cannot be carried
by the maximum link rate it advertises. It currently runs at HBR3, four lanes,
output_bpc 10, no DSC. I have not read the panel's DSC capability registers,
so I cannot rule out that HBR2 plus DSC is the intended combination -- if so,
that would explain the advertised maximum and I would be glad to be corrected.

Forcing the link above that advertised maximum is what our local tree does,
and it is why this laptop has a display at all -- but it is not a fix, which
is why I am reporting rather than sending a patch.

One observation, as a question rather than a claim: of all the revisions,
qcom_edp_com_configure_pll_v8() is the only one in which HBR2 has no PLL
programming of its own --

  rate   v4 hsclk_sel/dec_start   v6            v8 (glymur)
  1620   0x5 / 0x69               0x5 / 0x34    0x5 / 0x34
  2700   0x3 / 0x69               0x3 / 0x34    0x3 / 0x34
  5400   0x1 / 0x8c               0x1 / 0x46    0x2 / 0x4f  <- falls into 8100
  8100   0x0 / 0x69               0x0 / 0x34    0x2 / 0x4f

DP_PHY_VCO_DIV does differ between the two (0x02 vs 0x01), but
qcom_edp_set_vco_div() uses it to derive the pixel clock rather than the
serial rate. Is the shared case intentional for v8, and if not, are the
correct v8 HBR2 values available? It would not explain the RBR and HBR
failures, whose cases are distinct, so I may be looking at the wrong thing.

Ruled out by experiment here:
 - the device tree: our board file and the merged upstream one fail
   identically; link-frequencies allows 1.62/2.7/5.4/8.1 in both
 - the drivers/gpu/drm/msm/dp rework between next-20260713 and next-20260803:
   an rc6 kernel built with the 0713 dp/ directory fails the same way

Separately: when eDP training fails, msm_dp_display_atomic_disable() pushes
the idle pattern into a link that was never enabled, and on glymur that
resets the SoC. I am sending a patch for that to the msm list alongside this
report.

Happy to run any test here and capture logs over netconsole -- a retail
machine with no firmware unlock, but I can rebuild and reboot it freely.

Thanks for the glymur PHY support -- everything else in it works here.

Jesse Casco

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