Re: [PATCH v9 00/22] Synopsys DisplayPort Controller improvements for Rockchip platforms

[Igor Paunovic <royalnet026@gmail.com>]

Hi Sebastian,

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

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.

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.

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.

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 for the series - it turns a port that did nothing on mainline into my
main display output.

Igor

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip