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

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

[BG9OXA]

Hi all,

This short series adds support for the ALIENTEK QuarkPi-CA2, an RK3588S
based single board computer.

Board summary:
 - Rockchip RK3588S (4x Cortex-A76 + 4x Cortex-A55), LPDDR4x
 - eMMC, microSD slot, M.2 socket (PCIe 2.0 x1)
 - Gigabit Ethernet, USB 3.0 Type-A, USB 2.0 Type-A ports and a USB-C
   port (USB 2.0 plus DisplayPort altmode)
 - HDMI output, MIPI DSI and MIPI CSI connectors
 - ES8388 analog codec with 3.5 mm jack, HUSB311 USB-C PD controller
 - 40-pin header, RK806 PMIC, IR receiver
 - No SPI-NOR; the vendor bootloader reads extlinux.conf from the SD/eMMC
   boot partition

Patch 1 documents the board in the Rockchip platform bindings, patch 2
adds the device tree itself (plus its Makefile entry).  The "alientek"
vendor prefix is already present in vendor-prefixes.yaml, so no vendor
prefix change is needed.

Tested on hardware with a 6.18 based kernel: boot from SD and eMMC,
gigabit Ethernet, both USB 2.0 ports, the USB 3.0 Type-A port (5000 Mbps
link), USB-C DisplayPort altmode, HDMI video and audio, ES8388 analog
audio, M.2 PCIe, ADC keys, the IR receiver and ramoops.

Notes worth the reviewer's attention:

 * The codec node keeps "clock-names = \"mclk\"" together with the
   I2S0_8CH_MCLKOUT_TO_IO clock.  Without that name the MCLK never reaches
   the codec pad and playback stays silent, even though every register,
   the DAPM paths and the ALSA controls look correct.  Verified on
   hardware both with and without the property.

 * The codec compatible list is "everest,es8323", "everest,es8388".  The
   second entry is not cosmetic: sound/soc/codecs/es8328-i2c.c matches only
   "everest,es8328" and "everest,es8388", so dropping it would leave the
   codec without a driver.  Keeping it produces two dtbs_check warnings,
   because an ES8323/ES8388 binding is not upstream yet and the node falls
   back to everest,es8316.yaml (the compatible list is "too long" and
   AVDD/DVDD/HPVDD/PVDD are unexpected).  Two mainline boards already use
   "everest,es8323" with the same gap (rk3588-firefly-itx-3588j,
   rk3588s-youyeetoo-r1), so it looks like a missing binding rather than a
   board issue.  I left the binding out of this series to keep the board
   port focused and will happily send it separately - please tell me which
   form you prefer.

 * The USB 3.0 Type-A port is wired to usb_host2_xhci through combphy2_psu;
   both are enabled here, as in the vendor BSP.  combphy2_psu is free on
   this board because the M.2 socket uses pcie2x1l2 (combphy0_ps).

 * The MIPI CSI camera pipeline is described, but does not stream yet: the
   sensor probes fine while the RK3588 VICAP/rkcif capture path is still
   incomplete upstream, so those nodes are included for completeness only.

This is my first patch to the Rockchip platform.  I am a Chinese hobbyist
(amateur radio callsign BG9OXA) working on this board in my spare time, so
please point out anything that does not follow the expected style.

Changes in v2:
- Fix the RK806 DVS1 pin configuration: dvs1-null-pins used
  "gpio_pwrctrl2" instead of "gpio_pwrctrl1", as reported by the
  sashiko review.
- Translate all device tree comments to English, and drop a stale
  comment that no longer matched the Type-C / USB3 nodes.  Comment
  changes only: the code is otherwise byte-for-byte identical to v1.

BG9OXA (2):
  dt-bindings: arm: rockchip: add ALIENTEK QuarkPi-CA2
  arm64: dts: rockchip: add ALIENTEK QuarkPi-CA2

 .../devicetree/bindings/arm/rockchip.yaml            |    5 +
 arch/arm64/boot/dts/rockchip/Makefile                |    1 +
 arch/arm64/boot/dts/rockchip/rk3588s-quarkpi-ca2.dts | 1608 +++++++++++++++++++
 3 files changed, 1614 insertions(+)

-- 
2.43.0

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

[Andrew Lunn]

On Sun, Sep 27, 2026 at 09:51:24PM +0800, BG9OXA wrote:

> Changes in v2:

How much time was there between v1 and v2? You need to give reviewers
time to actually do a review and point out issues.

At minimum, wait 24 hours, but ideally 2-3 work days, and allow the
discussion to come to a conclusion.

	   Andrew

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

[BG9OXA]

Hello Andrew,

Thank you for the review, and for the timing guidance - you are right, and my
apologies: v2 went out far too soon after v1. I will hold off on any further
revision until the discussion here has settled, and no sooner than 2-3 working
days. I have also disabled the automated reminder job that had been set up for
this series, so nothing can be resent on its own.

On the phy-mode point in 2/2: you are correct that the value should describe the
PCB, not work around a MAC-internal delay. The RGMII traces on this board are
ordinary length; I used "rgmii-rxid" only because that is what the vendor BSP
(and many Rockchip DTs) do. I will test plain "rgmii" on the hardware with the
current tx_delay/rx_delay values and follow up with the measured results (link
state, throughput, and error counters), and drop the rxid form if it is not
needed.

If you have a preferred way for Rockchip boards to express this - plain "rgmii"
with the delays in the MAC node, or the delay masked in the driver - please say
so and I will prepare it that way.

Two other things I should mention. The enable-active-high issue that sashiko
flagged in 2/2 is already fixed locally and will be included in the next
revision. And for transparency: I prepared this series with the help of AI
tooling, which did the language conversion and consistency checking of the DTS.
I review every line before it is sent, and I will be more careful from here on -
both about the review cadence and about validating the result against the
hardware.

Thanks again,
BG9OXA

Re: [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

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

[Andrew Lunn]

On Thu, Oct 01, 2026 at 09:17:01PM +0800, BG9OXA wrote:
> 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.

Did you read

https://elixir.bootlin.com/linux/v6.15/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L287

phy-mode describes the PCB. 'rgmii-id' says the PCB does not have
extra RX/TX delays. So 'rgmii-id' is correct here. Please spend some
time to understand what delays are being added where, and how you can
get to rgmii-id without any retransmissions.

   Andrew