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

[Igor Paunovic <royalnet026@gmail.com>]

Hi Heiko,

Two of your four points I can say something concrete about.

On the cable being plugged in at boot: I see the same thing on an Orange
Pi 5 Plus, and it is the single thing that cost me the most time on this
hardware. The USB side comes up, the Type-C partner registers - your log
[1] shows typec_displayport binding cleanly at 23.9s - and the DRM
connector is still "disconnected" fifteen seconds later. That is what
happened on 16 of the 21 boots I have logged with the adapter attached;
on the other five the connector came up on its own inside that window.
So here it is the normal case rather than every single boot.

What gets it out of that state without touching the cable is a software
replug of the Type-C port controller - unbind and rebind the fusb302
driver:

  echo 6-0022 > /sys/bus/i2c/drivers/typec_fusb302/unbind
  echo 6-0022 > /sys/bus/i2c/drivers/typec_fusb302/bind

(the i2c address is board specific). After that the connector comes up
and the mode is set normally. I run this from a boot service. It has
fired on 16 boots and has never once failed: on 15 of them the log
records DP-1 going from disconnected to connected within three seconds,
and on the sixteenth the machine was powered off before any outcome was
written. The most recent one, from a boot tonight, is representative -
kernel start at 23:00:28, EDID override at 23:00:52, connector still
disconnected with the cable in at 23:01:07, unbind and rebind, connected
at 23:01:13.

Fair warning before you try it. The kernel I logged this on is a v7.2-rc6
Collabora rockchip-devel build that predates your v11 - it was built on 6
August at 00:00 CEST, so it carries the v9 generation of dw-dp - and it
is tainted by out-of-tree modules. On it the
unbind produces a WARN:

  WARNING: drivers/base/devres.c:1184 at devm_kfree+0xb8/0xd0

  devm_kfree+0xb8/0xd0 (P)
  tcpm_port_unregister_pd+0x70/0xc8 [tcpm]
  tcpm_unregister_port+0x70/0x178 [tcpm]
  devm_tcpm_unregister_port+0x1c/0x40 [tcpm]
  devm_action_release+0x20/0x48
  release_nodes+0x6c/0xc8
  devres_release_group+0x144/0x1a8
  i2c_device_remove+0x5c/0x130

I have it on 13 boots, most recently tonight; the rebind then works
regardless. My kernel is tainted by out-of-tree modules, and I have not
checked whether this is already known or fixed in usb-next, so please
treat it as a heads-up rather than as a bug report.

One timing detail, in case it applies to you: the Type-C partner does not
always show up promptly here. On most boots it is registered within about
twenty seconds, but on a minority of boots it takes far longer - the worst
one I have logged brackets it somewhere between 73 and 88 seconds after
kernel start. Anything that samples the connector state earlier than that
concludes the port is empty when it is not. I only have one USB-C dock to
test with, so I cannot say whether that delay is the board or the dock's
PD timing.

I called this an adapter problem in my earlier reply on this thread, and
your report makes me a good deal less sure of that. My assumption was
that it was firmware specific: this board runs the edk2-rk3588 UEFI port
(my build reports v1.1-13-g824e6c12), whose own support matrix lists
USB-C DisplayPort as only partially working - "No hot-plug detect & EDID.
Only works in one orientation of the Type-C port" - and lists the FUSB302
Type-C controller as not working, with no PD or TCPM driver in that tree
at all. So my working theory was that firmware leaves the PHY in a state
the driver does not reset. If you are seeing the same symptom on a
different board with different firmware, that theory does not hold and
this is something to fix rather than work around. What are you booting?

On ACLK_VOP: thank you for confirming the starvation. That is the first
report of it on hardware other than mine, and until now I had no way to
tell whether it was my adapter.

I do not think your garbling is a milder version of the same failure,
though. Here, at 750 MHz the picture became correct the moment the write
landed and stayed correct, with no POST_BUF_EMPTY logged for the 42
seconds that phase lasted; dropping back to 500 MHz brought the
corruption straight back. That run was on drm-misc-next dc2f9f7fed1a plus
your two series, built with CLOCK_ALLOW_WRITE_DEBUGFS so I could move the
rate at runtime. So on this board 750 MHz is a clean state and not a
marginal one - which also makes me doubt Alexey's reading that the
garbling is an artifact of overclocking the VOP2. At least it is not that
here.

The rest of what Alexey says looks like the right thing to check for your
case. It is worth seeing what pixel clock your 4K mode actually asks for
and what dclk it ends up with; on my side that same comparison is what
exposed a separate bug on this board, a video port left parented to a
dead PLL. One caveat when you compare against my numbers: my 4K120 link
runs YCbCr 4:2:0, which halves dclk, so the mode asks for 1188 MHz while
dclk sits at 594 MHz. If yours is 4:4:4 the numbers will not line up. If
you post the mode and the "setting dclk to rate=... result=..." line from
your log, I am happy to compare it against what this board does.

For reference, the ACLK thread is here; Cristian and Chaoyi have both
replied to it since:

  https://lore.kernel.org/all/20260808104240.13776-1-royalnet026@gmail.com/

Igor