[PATCH v4 00/20] drm: starfive: jh7110: Enable display subsystem

[Joshua Peisach]

On Tue Sep 15, 2026 at 11:32 AM EDT, Michal Wilczynski wrote:
>
> Testing
> =======
>
> Tested on a VisionFive 2 v1.3B using modetest.

I.. got nothing. I did have to manually modprobe the modules, but
unless I am doing something wrong.. I didn't get anything and modetest
just gave -2.

> ---
> Michal Wilczynski (20):
>       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: display: verisilicon: Add starfive,jh7110-dc8200
>       dt-bindings: soc: starfive: Add starfive,jh7110-vout-subsystem
>       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
>       drm/bridge: inno-hdmi: Make the PHY configuration table optional
>       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       |   1 +
>  .../starfive/starfive,jh7110-vout-subsystem.yaml   | 218 ++++++++
>  MAINTAINERS                                        |  13 +
>  arch/riscv/boot/dts/starfive/jh7110-common.dtsi    | 121 ++++-
>  arch/riscv/boot/dts/starfive/jh7110.dtsi           | 105 +++-
>  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                 | 112 +++-
>  drivers/gpu/drm/bridge/jh7110-inno-hdmi.c          | 297 +++++++++++
>  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      | 168 +-----
>  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       |  73 +++
>  drivers/soc/starfive/jh7110-vout-subsystem.c       |  82 +++
>  include/drm/bridge/inno_hdmi.h                     |  10 +-
>  include/linux/phy/inno-hdmi-phy.h                  |  85 +++
>  30 files changed, 2337 insertions(+), 188 deletions(-)
> ---
> base-commit: fd73f4a6659897191fa0d40695fe370925dd3780
> change-id: 20251031-jh7110-clean-send-7d2242118026
>
> Best regards,

By the way, something weird happenined while I applied the patches
using git am. Somehow, some were out of order. The 10th patch
adding .mode_valid tried to be applied before .disable even though
in the series, the order is correctly set? git would obviously
fail because the .disable entry did not exist in the header, so I had
to manually put those in.

I guess it's possible that something went wrong here? I personally
pulled the mailbox from the lore.kernel.org mbox.gz file.