Re: [PATCH v11 00/21] Synopsys DisplayPort Controller improvements for Rockchip platforms

Igor Paunovic <[email protected]>
Newsgroups org.infradead.lists.linux-arm-kernel,org.freedesktop.lists.dri-devel,org.infradead.lists.linux-rockchip,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
Hi Sebastian,

The Tested-by tag is at the bottom.  Short version: v11 works here on
an Orange Pi 5 Plus over USB-C DP AltMode.  It needs your usbdp v13
series underneath to probe at all, and above 2560x1440@144 it needs a
VOP2 ACLK change that has nothing to do with your patches.

One caveat first, so that the next paragraph is not misread: dp0 is
disabled in the mainline RK3588 DTS, so none of this is reachable on
an untouched tree.  I enable it with a local board DT patch.

With dp0 enabled but without usbdp v13, dw-dp never finishes probing.
It stops at "failed to get follow-up bridge" (dw-dp.c), because
mainline phy-rockchip-usbdp has no drm_aux_bridge_register() at all;
that call arrives with usbdp v13 patch 16/35 ("phy: rockchip: usbdp:
Register DP aux bridge").  The component bind then never completes, so
both HDMI outputs stay dark as well - the symptom is much wider than
the cause, which cost me a boot to work out.

Hardware: Samsung Odyssey G70B behind a USB-C to HDMI 2.1 protocol
converter.  DPCD extended revision 1.4, the link trains at HBR2 x4,
VSC SDP colorimetry is supported.  The converter ships a malformed
EDID, so a boot script feeds a corrected one through the debugfs
edid_override and kicks fusb302 once; without that the 4K modes are
dropped and AUX stays dead.  Both are adapter problems, not driver
ones.

What I saw:

  - DP-1 comes up connected, the EDID reads through the converter,
    the link trains, and KWin drives the output.
  - At the stock VOP2 ACLK rate, modes up to 2560x1440@144 are clean.
    I left the machine at [email protected] for more than eight hours
    with no DRM or VOP2 errors.
  - 3840x2160@120 comes up, but the picture is unusable until the
    VOP2 ACLK is raised.  With it raised the picture is correct
    immediately.

That last point is a platform issue rather than a dw-dp one, so I have
sent it as its own thread to dri-devel and linux-rockchip with you on
Cc: "drm/rockchip: vop2: ACLK_VOP pinned at 500 MHz starves DP 4K120
on RK3588".

Two small things I noticed while I was in there:

Kconfig: ROCKCHIP_DW_DP selects nothing, and DRM_DW_DP does not select
DRM_BRIDGE_CONNECTOR either, while ROCKCHIP_ANALOGIX_DP,
ROCKCHIP_CDN_DP, ROCKCHIP_DW_HDMI_QP, ROCKCHIP_LVDS and ROCKCHIP_RGB
all do.  Since dw_dp-rockchip.c calls drm_bridge_connector_init(), a
configuration with only ROCKCHIP_DW_DP enabled fails to link.  This
predates your series; I am happy to send the one-liner if you agree it
is worth fixing.

sound-dai-cells: the dt-bindings patch in this series ("dt-bindings:
display: rockchip: dw-dp: Fix sound DAI cells") notes that the
mainline rk3588 DTS still sets 0 and will be fixed up separately.  Is
that DTS patch already queued somewhere?  I would rather not duplicate
it.

DP audio: it does work here, but on my rockchip-devel based daily
kernel, which carries the v9 generation of the audio patch - a
simple-audio-card with cpu &spdif_tx2 and codec <&dp0 1>, picked up by
PipeWire unaided, playing over the same cable as the video.  I have
not retested audio on the v11 tree, so the tag below covers video
only.

Tested on drm-misc-next of 2026-08-07 (dc2f9f7fed1a) with this series,
usbdp v13, two local board DT patches (enable DP AltMode on the USB-C
connector; pin DCLK_VOP2 to V0PLL), and a one-line local change to
clk.c so that I could set clock rates from debugfs.

Thanks for the series.

Tested-by: Igor Paunovic <[email protected]>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.