On 5/14/26 17:27, Bin C0d3x wrote:
Hi,
I have a working USB-C DisplayPort + audio path for the RK3399
(RockPro64) on -CURRENT that I'd like to start landing. Looking for
a reviewer or two before I split this into Differential reviews.
Hardware: Pine64 RockPro64, FUSB302B Type-C controller (i2c), Cadence
MHDP DPTX block at 0xfec00000, RK3399 Type-C PHY, dw-hdmi for audio
codec endpoint, I2S2 (8-ch on-chip-only) feeding both HDMI and the
Cadence DP audio packetizer. Sink: XYM W156F1 portable monitor over
USB-C; verified 1920x1080 @ 60 Hz, link rate HBR (2.7 Gbps), 2 lanes,
plus stereo LPCM 48 kHz audio through panel speakers.
What's in the work (new drivers / subsystems):
sys/dev/iicbus/usb/fusb302.c
FUSB302B i2c driver: SRC/SNK PD policy state machine,
DP Alt Mode VDM (Discover/Enter/DP_Status), role discovery,
hard-reset, fault recovery. Modeled functionally on Linux's
drivers/usb/typec/tcpm/fusb302.c -- not a port, clean
re-implementation.
sys/sys/usbc/*
USB-PD policy state machine framework + TCPC abstraction so the
PD/VDM logic is driver-agnostic.
sys/arm64/rockchip/rk_typec_phy.c
RK3399 Type-C PHY bring-up for DP altmode (combo PHY mode
switch, lane swap, pin assignments C/D/E/F).
sys/arm64/rockchip/rk_cdn_dp.c
Cadence MHDP DPTX scaffold: firmware load, 19-stage bring-up,
AUX over mailbox, link training (CR+EQ both lanes at HBR),
DPCD, EDID readback, MSA/timing, audio packetizer with SDP
infoframe, DPMS sleep/wake via scanout swap.
sys/arm64/rockchip/rk_hdmi_codec_stub.c
Tiny audio_dai shim that claims rockchip,rk3399-dw-hdmi so
audio_soc's simple-audio-card codec phandle resolves -- enables
/dev/dsp0 over both HDMI and DP audio paths.
sys/arm64/rockchip/rk_gpio.c (PIC method fix)
pic_disable_intr/enable_intr/pre_ithread/post_ithread, missing
from the Rockchip GPIO PIC. Without them, level-sensitive
sources (FUSB302 INT_N) starve the system with ~210 kHz storms
during their ithread.
sys/dev/drm2/drm_fb_helper.c (small fix)
Don't strand on a safe-fallback fb after a late EDID arrives --
the cdn-dp panel EDID only becomes available after the 19-stage
bring-up, well after the kernel's first hotplug pass.
Status:
* fusb302 + PD policy SM: stable. Source + sink contracts work,
DP Alt Mode succeeds, retry/hard-reset paths exercised.
* cdn-dp: panel lit at 1920x1080@60 HBR. Audio decodes through
panel speakers via /dev/dsp0 with the rk_hdmi_codec_stub.
* Trace output is gated behind dev.fusb302.0.debug /
dev.rk_cdn_dp.0.debug (default 0), so default dmesg is quiet.
* Known open: transient panel artifacts ("black tears") during
USB-C boot bring-up. Source-side fully clean; appears framer-
side; cosmetic only.
Public reference:
https://github.com/b1nc0d3x/FBSD_DEV/tree/rkdev
That branch is a fork of freebsd/freebsd-src with ~30 commits on top.
I plan to split into separate Differential reviews:
1. rk_gpio PIC method fix (independent, useful on its own)
2. drm_fb_helper hotplug fix
3. USB-PD policy SM framework (sys/sys/usbc/)
4. fusb302 driver
5. rk_typec_phy
6. rk_cdn_dp (scaffold + bring-up)
7. rk_cdn_dp DP audio + rk_hdmi_codec_stub
8. RockPro64 DT overlays + module hookup
Each phase is self-contained and builds cleanly on the previous.
Would anyone with arm64 / DRM / USB-C familiarity be willing to look
at (1) and (2) first? They're the smallest and most clearly correct
bits. I can post Differentials as soon as a reviewer says go.
Thanks,
Kyle Crenshaw <[email protected]>
I did similar work but too gpl infected so I never published it. I can
test your work. Do you get any fusb302 interrupt on cold boot? Even the
RockChip kernel on linux did not..
Do you know my anxdp port from openbsd for the edp? the HW is in the
pinebook pro, which share the usb-c graphics with rockpro64. With a
minor u-boot change it works the same. So you should add support for the
pinebook pro as well. If you do not have the hw i can test.
Great work, congrats!
/jsm
