[PATCH v4 00/20] drm: starfive: jh7110: Enable display subsystem
Michal Wilczynski
m.wilczynski at samsung.com
Sun Sep 27 05:24:15 PDT 2026
On 9/18/26 17:32, Joshua Peisach wrote:
> On Thu Sep 17, 2026 at 1:22 PM EDT, Michal Wilczynski wrote:
>>
>>
>> On 9/16/26 02:45, Joshua Peisach wrote:
>>> 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.
>>
>> 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)
>
>> Also note modetest needs -M verisilicon.
>>
>
> "failed to open device 'versilicon' with busid '(null)': No such file
> or directory"
>
>
>> 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 at 29400000/hdmi at 29590000/controller: Fixed dependency cycle(s) with /soc/display-subsystem at 29400000/display at 29400000
> [ 0.091029] /soc/display-subsystem at 29400000/display at 29400000: Fixed dependency cycle(s) with /soc/display-subsystem at 29400000/hdmi at 29590000/controller
> [ 0.104227] /hdmi-connector: Fixed dependency cycle(s) with /soc/display-subsystem at 29400000/hdmi at 29590000/controller
> [ 0.104272] /soc/display-subsystem at 29400000/hdmi at 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
>
>>>
>>>> ---
>>>> 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
>>
>>>
>>
>> Best regards,
>
>
Best regards,
--
Michal Wilczynski <m.wilczynski at samsung.com>
More information about the linux-riscv
mailing list