On Sun Aug 9, 2026 at 9:14 PM CST, Cody Kang via B4 Relay wrote:
This series adds display support for the SpacemiT K3 [2], a RISC-V SoC:
a new DRM driver, a new PHY driver and three new bindings.
The display path is three blocks deep:
Saturn DPU -> Innosilicon DP/eDP controller -> Innosilicon DP PHY
In v2, two major improvements:
- Module unload is now robust.
- The bindings now require the controller's output port (port@1).
The rest of the v2 changes please see below, with details in each patch's
changelog.
Sashiko AI review contributed total review comments: 57 items, which I
accepted: 14 items.
v2 repeated the full v1 test matrix on both boards, in built-in and
modular configurations, plus the new module load/unload rounds.
The v1 cover letter follows below, unchanged, to provide some backgroud
(I can remove them from cover letter in next version):
The Saturn DPU is SpacemiT's own display processing unit. It has a private
address translation unit and a command-list composer that replays a batch
of register writes when a flush is latched. It exposes one CRTC with one
primary plane. The K3 instantiates two DPUs, one per display path.
The DPU driver arrives as five staged patches to keep each one a
reasonable size. The driver only becomes buildable with that last patch.
Bisect safe.
The DP/eDP controller and its PHY are Innosilicon IP, also two instances
of each. An instance behaves as embedded DisplayPort or as external
DisplayPort purely according to what its output port is wired to, so the
bindings do not distinguish them. The PHY's registers are interleaved
with the controller's inside one MMIO window, which is why it is
described as a child node and shares the controller's regmap.
The pixel clock is generated by the DP PHY's PLL, and the SoC's APMU
pixel-clock mux takes that PLL as an input. Rather than let the display
driver reach into PHY registers, the PHY registers its PLL as a clock
provider and the APMU mux is parented to it through the clock framework.
That is what patches 2, 4, 5 and 6 are for, and it is also what keeps the
APMU and the DP/eDP controller out of a devicetree provider cycle.
As a first posting of the K3 display subsystem, this patchset supports:
a single primary plane per CRTC, linear RGB scanout (no plane scaling,
rotation, YUV or writeback). It does not support DSI, DSC or DP audio,
and link rates are capped at HBR2.
Based on drm-misc-next at commit 5b9af25f2d0b ("accel/ivpu: Remove
unnecessary min_t()/max_t() usage"), v7.2-rc2 based.
Testing this series needs a SpacemiT u-boot carrying display support
[1]. SpacemiT expects to add that support into an official u-boot
release in August 2026.
Tested on two K3 boards:
- Pico-ITX: an eDP panel and an external DisplayPort monitor.
- CoM260-IFX: DisplayPort only, no eDP.
Note: The eDP panel DTS enablement is not part of this series; a separate
series will follow showing how eDP can be verified.
What was run on both boards, with modetest from libdrm and with kmscube:
- modetest -s, looped over 1920x1080, 1280x720 and 3840x2160
on DisplayPort and 2560x1600 on eDP
- kmscube, on each head and on both at once
- hot-plug and sink swap on the DisplayPort connector
Hi Cody,
Tested the series on a K3 Pico-ITX (mainline v7.3-rc2 + these patches,
display drivers built in). On the DisplayPort output:
- modetest -s: 1920x1080 and 1280x720 OK (native 2560x1440 as well);
3840x2160 not tested: my monitor has no such mode.
- kmscube: OK.
- hot-plug: unplug/replug detected, output re-enables fine.
Tested with the stock vendor U-Boot (2022.10); DP works fine with it.
Tested-by: Ze Huang <redacted>