[PATCH v2 0/2] arm64: dts: rockchip: add ALIENTEK QuarkPi-CA2

[BG9OXA]

Hello Andrew,

Following up on the phy-mode point, with the measurements I promised.

I ran three 15-minute runs at full rate in both directions on this board
(rk_gmac-dwmac + YT8531 PHY, iperf3, 900 s per direction), rebooting
between runs so each configuration was fresh:

  mode          tx_delay   rx_delay   board->host    host->board   retrans
  rgmii-rxid    0x2f       0x00       922 Mbit/s     939 Mbit/s    0
  rgmii         0x2f       0x00       922 Mbit/s     939 Mbit/s    0
  rgmii-id      0x00       0x00       918 Mbit/s     939 Mbit/s    224

The MAC error counters (rx/tx errors and drops) stayed at zero in all
three runs, and the link came up at 1000 Mb/s Full duplex every time.

So plain "rgmii" with the delay added on the MAC side behaves exactly
like the rxid form, and the "rgmii-id" run - where both sides add the
delay - is the only one that shows retransmissions. That matches your
point that only one side should add the delay. I have changed 2/2 to
phy-mode = "rgmii" and dropped the rxid form: the RGMII traces on this
board are ordinary length, so nothing in the PCB asks for an extra RX
delay.

While reworking it I also addressed the two things sashiko raised: the
enable-active-high property is now present, and the codec node no longer
carries a clock-names property, which everest,es8328.yaml does not allow.
The codec compatible list is "everest,es8388", "everest,es8328", as that
binding documents, and dtbs_check is clean for the node.

I also removed a stray phy-supply from u2phy0_otg, the USB 2.0 PHY of the
USB-C OTG port.  That rail is the Type-C VBUS and belongs to the TCPC;
with the PHY holding it enabled as well, VBUS was powered from boot and
the port never finished a source attach, so DisplayPort altmode never
came up.  The full change list is in the v3 cover letter.

Thanks again for the careful review - the phy-mode explanation in
particular was worth the rework.

BG9OXA