[PATCH v3 00/19] drm: starfive: jh7110: Enable display subsystem
Joshua Peisach
jpeisach at ubuntu.com
Fri Sep 4 08:13:05 PDT 2026
On Fri Sep 4, 2026 at 9:27 AM EDT, Michal Wilczynski wrote:
> This series enables the display subsystem on the StarFive JH7110.
>
> The dom_vout block holds the display controller (dc8200), the clock
> generator (voutcrg) and the HDMI IP, all inside PD_VOUT. The HDMI IP is
> a single register block containing both the controller and the PHY, and
> it has a circular clock dependency with voutcrg:
>
> - the HDMI controller needs pclk/mclk/bclk from voutcrg
> - voutcrg needs the pixel clock for its dc8200 pixel MUXes, and that
> clock is generated by the HDMI PHY
>
> The loop only exists if the HDMI block is treated as one device. The
> PHY's reference clock is xin24m, not a voutcrg output, so splitting the
> node into a parent plus phy and controller children gives deferred probe
> a linear order: hdmi-phy, then voutcrg, then hdmi-controller.
>
> The parent maps the register block and owns the regmap its two children
> share. Everything in the region sits behind one NoC port whose clock and
> reset gate access to it, inside PD_VOUT, so the vout subsystem node from
> the RFC is back and owns those for as long as any child exists.
>
> Patch 10 adds a .mode_valid platform op to inno-hdmi.
> inno_hdmi_bridge_mode_valid() checks the pixel clock against
> hdmi->refclk, but that clock only exists where a "ref" clock is
> described. The JH7110 gets its pixel clock from the PHY, so refclk is
> NULL and the check was skipped: unsupported modes were advertised, the
> modeset then "succeeded" because the atomic enable path cannot fail, and
> the display stayed blank.
>
> Patches 15-17 drop the PHY duplication from the RFC. The JH7110 has the
> same Innosilicon PHY as the RK3328, offset by 0x100 because it sits
> behind the controller in the shared register block. Patch 15 factors out
> the pre-PLL config format, table lookup, determine_rate, recalc_rate and
> the pre-PLL programming; patch 16 moves Rockchip onto it; patch 17 adds
> the JH7110 driver. Pixel clock tables, post-PLL and analog config stay
> SoC specific.
>
> Patch 16 should be a no-op for Rockchip - same writes, same order, same
> values - and RK3228, whose pre-PLL is at different addresses, keeps its
> own register code and shares only the lookup. I have no Rockchip
> hardware, so it is build tested only (arm and riscv). A Tested-by would
> help.
>
> The dc8200 driver, th1520 reset controller and inno-hdmi bridge that the
> RFC listed as prerequisites are all upstream now, so there are no
> out-of-tree dependencies.
>
> Testing
> =======
>
> Tested on a VisionFive 2 v1.3B using modetest.
>
> All 42 modes the sink advertises work, with nothing in dmesg. Pixel
> clocks run from 25.175 MHz (640x480 at 59.94) up to 297 MHz
> (4096x2160 at 30), including 3840x2160 and the full 1920x1080 and 1280x720
> rate families.
>
> The four modes the RFC reported as broken work now too: 2560x1440 at 59.95,
> 2048x1080 at 60.00, 2048x1080 at 24.00 and 720x400 at 70.08.
>
> Before patch 10, four of the advertised modes failed: 1680x1050 at 59.95
> (146.250 MHz), 1400x1050 at 59.98 (121.750), 1152x864 at 59.97 (81.768) and
> 1280x768 at 60.35 (80.140). Those pixel clocks are not in the PHY pre-PLL
> table, so clk_set_rate() returned -EINVAL and the screen stayed black
> while userspace saw a successful modeset. They are rejected in
> .mode_valid now; the other refresh rates of those resolutions still work.
>
> Every commit builds for riscv, and the Rockchip PHY also for arm.
>
> Notes
> =====
>
> The JH7110 has no central MAINTAINERS entry and maintainership is
> fragmented, so patch 19 adds one for the display subsystem and I am
> happy to help maintain it. The new PHY library lives under drivers/phy/,
> already covered by the generic PHY framework entry.
>
> checkpatch warns "does MAINTAINERS need updating?" on the patches adding
> files, because that entry comes in patch 19.
>
> Thanks to Icenowy Zheng for the dc8200 driver and for explaining how the
> SoC and the display pipeline fit together.
>
> Thanks also to Dominique Belhachemi, who got rid of the vout-subsystem
> wrapper and helped with the testing, to Maud Spierings for testing on a
> Framework 13 panel, and to Graham Markall for testing
> the JH7110 display patches independently and writing up the results:
> https://big-grey.co.uk/2026/01/26/testing-starfive-jh7110-display-controller-patches/
>
> Link to v1: https://lore.kernel.org/all/20251108-jh7110-clean-send-v1-0-06bf43bb76b1@samsung.com/
>
> ---
> Changes in v3:
> - Brought back the vout subsystem node and driver, now owning the NoC
> bus clock, its reset and PD_VOUT for the whole region, with dc8200,
> the HDMI block, the syscon and voutcrg as its children (Icenowy Zheng).
> - Fixed a hard hang when the bridge is built as a module: the PHY's
> .is_prepared read a register in the window gated by the controller's
> system clock, so clk_disable_unused() wedged the CPU before the
> controller had bound. The op is gone; the framework uses the software
> prepare count instead. (Marek Szyprowski)
> - The HDMI controller now programs the display mux in dom_vout_syscon
> from the port graph rather than inheriting whatever the bootloader
> left, with a phandle to the syscon (Icenowy Zheng).
> - The register access clock is named "pclk" to match the existing
> inno-hdmi binding, so the generic driver no longer picks up the pixel
> clock. Previously it held the pre-PLL powered from probe and sized the
> DDC divider from the wrong rate.
> - Dropped the clk suffixes and the single-entry -names properties from
> the bindings (Conor Dooley). mclk and bclk keep their names: per TRM
> 5.3 they are the HDMI audio clocks, not module and bus clocks, so the
> descriptions say that instead.
> - Replaced patternProperties with plain properties in the hdmi-subsystem
> binding (Conor Dooley).
> - dc8200 gets an SoC specific compatible, and inherits dma-noncoherent
> from the subsystem bus node, so it validates against verisilicon,dc.
> - Added the pre-PLL entry for the Framework 13 panel and fixed two
> devicetree whitespace nits (Maud Spierings).
> - select REGMAP_MMIO, CLK_SET_RATE_NO_REPARENT on the dc8200 pixel MUXes
> so clk_set_rate() cannot reroute them, and inno-hdmi register reads
> return 0 instead of stack garbage when regmap_read() fails.
> - phy: rockchip: dropped the local pre-PLL lookup wrapper and the 28 now
> unused RK3328 pre-PLL macros, and restored the VCO debug output, this
> time in the shared helper so both drivers get it (Jonas Karlman).
> - Rebased onto v7.3-rc1.
> - Link to v2: https://lore.kernel.org/r/20260828-jh7110-clean-send-v2-0-331680c8b9d1@samsung.com
>
> Changes since the RFC:
> - Dropped the vout-subsystem wrapper driver and its binding, along with
> the patch relaxing the voutcrg binding; genpd handles PD_VOUT per
> node.
> - Renamed the compatible to starfive,jh7110-hdmi-subsystem, dropping
> "mfd" as a Linux term (Conor Dooley).
> - Absolute $refs in the bindings, unused example labels dropped, and the
> examples deduplicated between parent and children (Conor Dooley).
> - Added the .mode_valid platform operation (patch 7).
> - Split the inno-hdmi rework into a mechanical probe/bind split (patch
> 4)
> and the regmap-from-parent change (patch 5). struct inno_hdmi is no
> longer exported; no platform glue dereferences it.
> - Replaced the duplicated PHY driver with a shared Innosilicon library
> and moved Rockchip onto it (patches 11-13).
> - Fixed pre-PLL lock detection, which masked the status read with the
> register address instead of the lock bit.
> - Fixed a pixel clock refcount underflow: enable returns early on
> failure while disable tore down unconditionally.
> - voutcrg patch reduced to adding CLK_SET_RATE_PARENT to the two dc8200
> pixel MUXes.
> - Rebased onto v7.2.
>
> ---
> Michal Wilczynski (19):
> dt-bindings: phy: Add starfive,jh7110-inno-hdmi-phy
> dt-bindings: display: bridge: Add starfive,jh7110-inno-hdmi-controller
> dt-bindings: mfd: Add starfive,jh7110-hdmi-subsystem
> dt-bindings: soc: starfive: Add starfive,jh7110-vout-syscon
> dt-bindings: soc: starfive: Add starfive,jh7110-vout-subsystem
> dt-bindings: display: verisilicon: Add starfive,jh7110-dc8200
> drm/bridge: inno-hdmi: Split probe out of bind
> drm/bridge: inno-hdmi: Allow the register map to come from a parent
> drm/bridge: inno-hdmi: Add .disable platform operation
> drm/bridge: inno-hdmi: Add .mode_valid platform operation
> soc: starfive: Add jh7110-hdmi-subsystem driver
> soc: starfive: Add jh7110-vout-subsystem driver
> clk: starfive: jh7110-vout: Allow pixel clock rate propagation
> drm/bridge: starfive: Add JH7110 HDMI controller driver
> phy: Add common Innosilicon HDMI PHY helpers
> phy: rockchip: inno-hdmi: Use the common Innosilicon PHY helpers
> phy: starfive: Add jh7110-inno-hdmi-phy driver
> riscv: dts: starfive: jh7110: Update DT for display subsystem
> MAINTAINERS: Add StarFive JH7110 display subsystem entry
>
> .../starfive,jh7110-inno-hdmi-controller.yaml | 121 +++++
> .../bindings/display/verisilicon,dc.yaml | 1 +
> .../mfd/starfive,jh7110-hdmi-subsystem.yaml | 95 ++++
> .../phy/starfive,jh7110-inno-hdmi-phy.yaml | 49 ++
> .../soc/starfive/starfive,jh7110-syscon.yaml | 6 +
> .../starfive/starfive,jh7110-vout-subsystem.yaml | 100 ++++
> MAINTAINERS | 13 +
> arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 121 ++++-
> arch/riscv/boot/dts/starfive/jh7110.dtsi | 102 +++-
> drivers/clk/starfive/clk-starfive-jh7110-vout.c | 6 +-
> drivers/gpu/drm/bridge/Kconfig | 11 +
> drivers/gpu/drm/bridge/Makefile | 1 +
> drivers/gpu/drm/bridge/inno-hdmi.c | 84 ++-
> drivers/gpu/drm/bridge/jh7110-inno-hdmi.c | 318 +++++++++++
> drivers/phy/Kconfig | 8 +
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-inno-hdmi.c | 298 +++++++++++
> drivers/phy/rockchip/Kconfig | 1 +
> drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 165 +-----
> drivers/phy/starfive/Kconfig | 20 +
> drivers/phy/starfive/Makefile | 1 +
> drivers/phy/starfive/phy-jh7110-inno-hdmi.c | 579 +++++++++++++++++++++
> drivers/soc/Kconfig | 1 +
> drivers/soc/Makefile | 1 +
> drivers/soc/starfive/Kconfig | 43 ++
> drivers/soc/starfive/Makefile | 3 +
> drivers/soc/starfive/jh7110-hdmi-subsystem.c | 74 +++
> drivers/soc/starfive/jh7110-vout-subsystem.c | 83 +++
> include/drm/bridge/inno_hdmi.h | 10 +-
> include/linux/phy/inno-hdmi-phy.h | 85 +++
> 30 files changed, 2227 insertions(+), 174 deletions(-)
> ---
> base-commit: cee9395acd8043be0644b25c34bfa86623f2b935
> change-id: 20251031-jh7110-clean-send-7d2242118026
>
> Best regards,
So as a kernel newbie, and someone who happens to have this device,
it's nice to see it here.
It looks good to me, just a few questions:
- One patch mentioned in a comment "the docs" - is there documentation
for the device?
- There are multiple pieces, like the hdmi and vout subsystem, and also
the inno helpers. Should those be separate patches? I honestly don't
have enough experience (or authority) to suggest doing so.
I thought this would be great as a possible driver I could do to learn
kernel dev.. looks like I was very wrong. Great work, and hopefully
in the future I get my hands on some device that needs a driver to be
written for it.
I'm at university, once my board gets mailed from home I'll be able to
test. For now,
Reviewed-by: Joshua Peisach <jpeisach at ubuntu.com>
More information about the linux-riscv
mailing list