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

On 9/18/26 17:32, Joshua Peisach wrote:

On Thu Sep 17, 2026 at 1:22 PM EDT, Michal Wilczynski wrote:

quoted

On 9/16/26 02:45, Joshua Peisach wrote:

quoted

On Tue Sep 15, 2026 at 11:32 AM EDT, Michal Wilczynski wrote:

quoted

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.

Hmm have you also changed the DTB not just the kernel and the modules
(you can also built in everything).

Yes (I didn't built-in everything, but I did make sure the DTB was
copied and flash-kernel was run)

quoted

Also note modetest needs -M verisilicon.

"failed to open device 'versilicon' with busid '(null)': No such file
or directory"

quoted

If that is not it, could you send "dmesg | grep -iE
'verisilicon|inno|hdmi|vout'" and "ls /sys/class/drm/"?

the dmesg output:

[    0.090950] /soc/display-subsystem@29400000/hdmi@29590000/controller: Fixed dependency cycle(s) with /soc/display-subsystem@29400000/display@29400000
[    0.091029] /soc/display-subsystem@29400000/display@29400000: Fixed dependency cycle(s) with /soc/display-subsystem@29400000/hdmi@29590000/controller
[    0.104227] /hdmi-connector: Fixed dependency cycle(s) with /soc/display-subsystem@29400000/hdmi@29590000/controller
[    0.104272] /soc/display-subsystem@29400000/hdmi@29590000/controller: Fixed dependency cycle(s) with /hdmi-connector


/sys/class/drm only contains the file "version"

Typo - it is "verisilicon" you are missing the i.

But that is not the real problem: /sys/class/drm holding only "version"
means no DRM device registered at all and your dmesg shows no probe
output from any of the drivers, so they are not being loaded.

I would suspect something is missing from the .config.

Those are relevant options for this series:

CONFIG_DRM_VERISILICON_DC=y
CONFIG_CLK_STARFIVE_JH7110_VOUT=y
CONFIG_SOC_STARFIVE_JH7110_VOUT_SUBSYSTEM=y
CONFIG_SOC_STARFIVE_JH7110_HDMI_SUBSYSTEM=y
CONFIG_PHY_STARFIVE_JH7110_INNO_HDMI=y
CONFIG_DRM_STARFIVE_JH7110_INNO_HDMI=y

easiest to build them in.

Run "make olddefconfig" after editing .config - DRM_VERISILICON_DC
selects DRM_BRIDGE_CONNECTOR, DRM_DISPLAY_HELPER and DRM_GEM_DMA_HELPER,
and if those did not get pulled in the DC never registers. Also verify
after building how .config actually looks like.

With those options and correct dtb the drivers should probe correctly
and there would be a trace in dmesg.

-Josh

quoted

quoted

quoted

---
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.

I would recommend using b4 shazam instead

quoted

Best regards,

Best regards,
-- 
Michal Wilczynski [off-list ref]