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

[Krzysztof Kozlowski <krzk@kernel.org>]

On 02/10/2026 05:52, BG9OXA wrote:
> 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/3.0 plus DisplayPort altmode, two DP lanes)
>  - HDMI output, three MIPI CSI and two MIPI DSI 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: boot from SD and eMMC, gigabit Ethernet, the USB 2.0
> ports, the USB 3.0 Type-A port (UAS storage device, 5000 Mbps link,
> 309 MB/s), USB-C DisplayPort altmode, HDMI video and audio, ES8388 analog
> playback over the 3.5 mm jack (checked with music), the ADC keys, the IR
> receiver, the PWM fan and ramoops.  The M.2 socket is described following
> the vendor design; no suitable device was available here to exercise that
> link.  dtbs_check is clean for both patches.
> 
> Notes worth the reviewer's attention:
> 
>  * The codec is clocked through I2S0_8CH_MCLKOUT_TO_IO rather than the
>    internal I2S0_8CH_MCLKOUT mux that the other boards reference.  On
>    RK3588 the MCLK-to-IO routing is a gate in SYS_GRF SOC_CON6 which the
>    bootloader leaves closed, so nothing drives MCLK out to the codec;
>    pointing "clocks" at the _TO_IO clock makes the codec driver open that
>    gate at probe, while "assigned-clocks" stays on the internal mux to
>    keep the 12.288 MHz rate.  Verified on hardware: i2s0_8ch_mclkout_to_io
>    is enabled with the codec (1-0011) as its consumer, and playback works.
> 
>  * The codec compatible list is "everest,es8388", "everest,es8328", as
>    documented in everest,es8328.yaml and as used by the other boards with
>    this part.  The standalone ES8323 driver cannot instantiate a card on
>    this board at all, which is how the fitted part was confirmed.
> 
>  * Analog capture from the 3.5 mm TRRS jack (headset microphone) does not
>    work yet: the capture stream returns a constant idle pattern (0xFFFF)
>    although the analog bypass path works, and the DAPM routes and the ALSA
>    controls look correct.  This looks like the same ES8328 capture problem
>    that has been reported for other boards, so I kept it out of this
>    series.
> 
>  * 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 3.5 mm jack is fed from the codec outputs (LOUT1/ROUT1) and from the
>    headphone amplifier outputs, as in the vendor tree.  Describing only the
>    amplifier path was tried as well, and on this board that gives no output
>    at the jack at all (verified on hardware with a test tone and with music
>    playback), so both routes are kept.
> 
>  * The board has three MIPI CSI and two MIPI DSI connectors, but no camera
>    or panel is described here: those are plug-in modules.  Enabling the
>    CSI-2 receiver without a sensor attached makes the driver fail to find
>    its endpoint at probe (verified on hardware), so, as in the vendor
>    tree, camera and panel descriptions belong in overlays.
> 
>  * GbE: phy-mode is "rgmii-id".  As you explained, phy-mode describes the
>    PCB, and this PCB does not add RX/TX delays, so the delays have to come
>    from the PHY.  I went through where each delay is actually applied:
> 
>      - MAC side: none.  dwmac-rk takes the delay values from the DT only
>        for the plain "rgmii", "rgmii-rxid" and "rgmii-txid" modes; for
>        PHY_INTERFACE_MODE_RGMII_ID it calls set_to_rgmii(priv, 0, 0), so
>        the RGMII delay registers are written with zero.  (The driver still
>        logs "set tx_delay to 0x30"/"set rx_delay to 0x10" when the
>        properties are absent, but those values are only the parse-time
>        defaults and do not reach the GRF in this mode.)
> 
>      - PHY side: the delays.  The Motorcomm driver programs its internal
>        RGMII delay for RGMII_ID, using 1950 ps for both directions when
>        rx-internal-delay-ps / tx-internal-delay-ps are not specified,
>        which is its documented default for both directions.
> 
>     So with "rgmii-id" nothing is added twice.  Measured on hardware with
>     iperf3 at gigabit line rate: in one 900 second run, 96.8 GB transferred
>     at 924 Mbit/s with zero retransmissions; in a second run on the final
>     revision of the series, 300 seconds in each direction, 925 Mbit/s
>     transmit and 937 Mbit/s receive, with 114 and 23 retransmits out of
>     roughly 24 million segments each way (a few ppm).  rx_crc_errors and
>     the other error counters stay at zero in both runs.
> 
> This is my first patch to the Rockchip platform.  I am a Chinese amateur
> electronics 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 v6:
> - My oversight, sorry for the noise: when I switched phy-mode to "rgmii-id"
>   in v5 I forgot to update the commit message of patch 2/2 at the same time,
>   so the message still described the v3/v4 approach (delays applied on the
>   MAC side) while the code had moved to the PHY-side delays.  The message now
>   describes what the code does: the PHY adds the delays internally and the
>   MAC adds none, so nothing is applied twice.  The device tree is not touched
>   by this change; the compiled .dtb is byte-for-byte identical to the one in
>   v5 (verified).
> - Keep the headphone routing as in v5.  On this board the 3.5 mm jack needs
>   the direct codec output routes: describing only the amplifier path gives
>   no output at the jack, which I verified on hardware with a test tone and
>   with music playback.  So the parallel routes are intentional here and
>   were not changed.
> - Link to v5: https://lists.infradead.org/pipermail/linux-rockchip/2026-October/077620.html
> 
> Changes in v5:
> - Use phy-mode = "rgmii-id" and let the PHY add the RGMII delays, instead of
>   "rgmii" with the delay applied on the MAC side, as pointed out by Andrew
>   Lunn.  The MAC adds no delay in this mode, so nothing is applied twice;
>   see the GbE note above for the details and the measurements.
> - Move the Makefile entry so that the list stays in alphabetical order.
> - Rename the headphone amplifier node to the generic name "audio-amplifier";
>   the labels are unchanged, so no reference is affected.  The audio routing
>   itself is unchanged, see the note above.
> - Set the Type-C connector data-role to "host".  The XHCI controller is
>   host-only on this board (dr_mode = "host" and no usb-role-switch), and
>   the vendor DT lists "dual" only because the vendor configures that
>   controller as OTG.  The power role stays "dual", as the board can be
>   powered over Type-C.
> - Link to v4: https://lists.infradead.org/pipermail/linux-rockchip/2026-October/077616.html
> 
> Changes in v4:
> - Add the missing blank line between the include block and the root node.
> - Fix the node indentation in a few places.  That cleanup is whitespace only;
>   the compiled .dtb is unchanged by it (verified byte-for-byte).
> - Rename the Type-C controller node to the generic name "typec-port", as the
>   other boards using this part do, and drop its redundant status property.
> - Give the fixed regulator nodes the "regulator-" name prefix, as the other
>   boards do; the labels are unchanged, so no reference is affected.
> - Route the Type-C SuperSpeed lanes through the USBDP PHY, as the other
>   RK3588 boards do, so that the PHY does the orientation muxing.
> - Feed the headphone amplifier from one codec output pair only; that is what
>   the other ES8388 boards do.
> - Cc the people and lists reported by scripts/get_maintainer.pl.
> - Link to v3: https://lists.infradead.org/pipermail/linux-rockchip/2026-October/077611.html
> 


This looks a lot like LLM generated stuff. Don't. The easiest way to
annoy maintainers. We are not going to read long LLM-generated
paragraphs for trivial stuff, because trivial stuff should be explained
with one sentence.

Best regards,
Krzysztof