Re:_USB-C_DisplayPort_+_audio_bring-up_on_RK3399_(Roc kPro64)_—_looking_for_reviewers

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  <B1nc0d3x@gmail.com>
> 
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