Hello Igor,

On Tue, Aug 04, 2026 at 03:56:40PM +0200, Igor Paunovic wrote:
> You wrote in the cover letter that parts of this are untested, and asked for
> comments on the out-of-band hotplug callback.  I have been running this series
> on real hardware, so here is a report from the USB-C DP AltMode side.
> 
> Tested-by: Igor Paunovic <royalnet026@gmail.com> # RK3588, Orange Pi 5 Plus, USB-C DP AltMode

Thanks. I've just send v10. I expect this to still work, but since
quite some patches changed I did not carry this over.

> Hardware and base
> -----------------
> 
>   Board:  Orange Pi 5 Plus (RK3588)
>   Kernel: v7.2-rc6 + rockchip-devel, pinned at 8c70065a3207, which carries
>           this series at v9 - including 03/22 "Fix error handling in
>           dw_dp_link_enable()", so this is v9 and not an earlier respin.
>           No local changes on top of any dw-dp patch.
>   PHY:    your rockchip-usbdp v13 series, from the same branch
>   Sink:   4K120-capable display, reached both directly and through a USB-C
>           dock, DP AltMode over the Type-C port
> 
> Results
> -------
> 
> USB-C DP AltMode works.  I get 4K120 on the Type-C output, which on this board
> is a third display output that mainline does not otherwise light up at all.
> The mode comes up at dclk 594 MHz, which is what 4:2:0 should give at that
> resolution (two pixels per clock), and it survives a live modeset - I can go
> from 60 Hz to 120 Hz on a running desktop without unplugging the cable and
> without dropping to a black screen.
> 
> That last part is the change I want to highlight.  On my previous kernel, based
> on v7.0 without this series and without the usbdp rework, touching the cable
> while the link was up was something I had to actively avoid, and a live 60->120
> modeset gave me a black screen that needed a hard reset to recover from.  Both
> of those are gone here.  Whatever the combination of the follow-up bridge work
> and the PHY re-init on orientation change is doing, from where I sit it is the
> difference between "usable" and "do not touch".
> 
> I have not exercised the DP audio path (22/22) yet, and I have no board with a
> native DP connector or an HDMI bridge downstream, so I cannot say anything
> about the code path you flagged as untested.

heh, that's the most interesting ones regarding testing as I haven't
tested the related paths in the driver. USB-C AltMode should be more
or less the same on all RK3588/RK3576 boards.

> On the out-of-band HPD callback
> -------------------------------
> 
> You asked for comments, and I have a data point rather than a design opinion.
> 
> On this board the AUX channel is dead at boot until something kicks the Type-C
> port controller.  The cause is on the firmware side rather than yours: the
> board boots through EDK2, which has no TCPM, so it hands Linux a PHY that was
> never brought into a sane state and a port controller that has never
> negotiated.  Nothing on the DP side can discover the sink until fusb302 is
> poked, after which the link comes up normally and stays up.

That's needs to happen anyways independent of the boot process,
since USB-C can be hot-plugged :)

> I mention it because it is exactly the shape of event your callback is for: the
> hotplug information arrives from outside the DP block, late, and the DP side had
> no way of knowing.  A separate callback rather than reusing hotplug_notify seems
> right to me for that reason - the two really are different sources, and only one
> of them is something the DP block could ever have observed itself.  I cannot
> tell you whether there is a cleaner mechanism, but I can tell you that the
> separation matches how the hardware actually behaves here.

I'm well aware how the hardware works. That does not necessarily
require a separate notifier, though. But the existing one does not
work anyways as it does not distinguish the information source. That
could be changed of course (but with quite some churn involved).

> One neighbouring finding
> ------------------------
> 
> While bringing this up I hit a bug that is not in your series but sits right
> next to it, so it may be useful to you and to Cristian.
> 
> On RK3588, VP2's dclk was parented to the HDMI PHY clock.  When the HDMI PHY is
> not powered - which is the normal case if you are only driving the Type-C
> output - that parent is dead, and DP gets no usable pixel clock: nothing above
> 640x480 comes up.  Re-parenting VP2's dclk to V0PLL in DT fixes it, and that is
> what the 4K120 above is running on.
> 
> I see Cristian's "Consolidate HDMI PHY PLL clock parent switch" (v3 09/14 of the
> DW HDMI QP YUV series) touches the same parent-switch logic from the driver
> side.  I have not yet worked out whether that series makes the DT change
> unnecessary, or whether the two are complementary.  I will work that out before
> I send anything, but I would rather flag it here than have two people discover
> it separately.
> 
> Happy to run any specific case you want covered, or to retest on later
> revisions.

Thanks.

> Thanks for the series - it turns a port that did nothing on mainline into my
> main display output.

Great. It's obviously too late for 7.3 now, but I hope to get all of
this upstream in 7.4. It would be a nice start into 2027 :)

Greetings,

-- Sebastian