.../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(-)
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.
Patch 11 makes the inno-hdmi PHY configuration table optional. The
JH7110 drives its PHY through a separate driver, so the table only ever
existed to get past a probe time check, and the register writes it fed
belong to the integrated PHY the JH7110 does not have.
Patches 16-18 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 16 factors out
the pre-PLL config format, table lookup, determine_rate, recalc_rate and
the pre-PLL programming; patch 17 moves Rockchip onto it; patch 18 adds
the JH7110 driver. Pixel clock tables, post-PLL and analog config stay
SoC specific.
Patch 17 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@59.94) up to 297 MHz
(4096x2160@30), including 3840x2160 and the full 1920x1080 and 1280x720
rate families.
The four modes the RFC reported as broken work now too: 2560x1440@59.95,
2048x1080@60.00, 2048x1080@24.00 and 720x400@70.08.
Before patch 10, four of the advertised modes failed: 1680x1050@59.95
(146.250 MHz), 1400x1050@59.98 (121.750), 1152x864@59.97 (81.768) and
1280x768@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.
The mux the HDMI controller programs in dom_vout_syscon has a DP and a
DPI branch, and the DT wires the DPI one, so the DP branch was checked
separately by moving the input endpoint to the DC8200's DP output on a
throwaway branch. SYSCFG_4 reads 0x4c0b0000 instead of 0x0c0b0000, the
output is identical to the DPI path and all 42 modes set. Sweeping
VOUT_HDMI_DP_YUV_MODE over its four values with a mode held shows only
RGB giving a correct picture, as documented.
Every commit builds for riscv, and the Rockchip PHY also for arm.
Known limitation
================
The Framework 13 (fml13v01) panel needs one more change that is not in
here: dropping v_REG_CLK_INV | v_REG_CLK_SOURCE_SYS from the
HDMI_SYS_CTRL write in inno_hdmi_init_hw(), without which it flickers
(Maud Spierings). Those bits are set unconditionally for every user of
the generic driver, so changing them is outside the scope of this
series. Input from the inno-hdmi maintainers, or from anyone with a
datasheet that says when they apply, would be welcome.
Notes
=====
The JH7110 has no central MAINTAINERS entry and maintainership is
fragmented, so patch 20 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 20.
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 v4:
- New patch 11 makes the inno-hdmi PHY configuration table optional, so
the JH7110 controller can drop the dummy two entry table it carried
only to satisfy the probe time check, along with the integrated PHY
register writes that table fed (Icenowy Zheng). That table was also
acting as an upper bound: inno_hdmi_find_phy_config() runs before the
platform .mode_valid and returns early, so its 297 MHz sentinel
rejected every mode above that even though the PHY pre-PLL table has a
594 MHz entry. Nothing here advertises such a mode, so it was latent.
- Fixed a v3 regression: CLK_SET_RATE_NO_REPARENT stops clk_set_rate()
from reparenting the dc8200 pixel MUXes, so they kept whatever the
bootloader had selected and the display stayed black on boards where
that was not the HDMI PHY. They get assigned-clock-parents now (Maud
Spierings, Dominique Belhachemi).
- vout-subsystem binding: describe the children by compatible instead of
$ref, as qcom,sm8750-mdss does, and show the whole subsystem with all
four children in the example (Krzysztof Kozlowski).
- Dropped the vout-syscon example from starfive,jh7110-syscon.yaml, it
is part of the vout subsystem example now (Krzysztof Kozlowski).
- Renamed the xin24m node to xin24m-clock (Krzysztof Kozlowski).
- Fixed the HDMI HPD pinmux: it drove the pin high (GPOUT_HIGH with the
output enabled) while also reading it as the hotplug input, so HPD
could only ever read asserted. It is an input now.
- jh7110-inno-hdmi: dropped a regmap lookup whose result was never used;
inno_hdmi_probe() fetches the parent regmap itself. The commit message
claimed otherwise and is corrected.
- phy: rockchip: dropped two now unused RK3328 spread spectrum macros
the v3 cleanup missed. The register write itself moved to the shared
helper and is unchanged, so Chaoyi's Reviewed-by is carried over.
- inno-hdmi: the hotplug handler dereferenced bridge.dev unconditionally.
Splitting probe out of bind moved the interrupt request to probe, so
an HPD event before the DRM master attaches the bridge would oops.
Guarded.
- Dropped the <linux/mod_devicetable.h> includes (Uwe Kleine-König).
- jh7110-inno-hdmi: __free(device_node) for the graph lookups, and
dropped the redundant negative check on clk_round_rate() (Chaoyi Chen).
- phy: rockchip: dropped the recalc_rate debug print that the shared
helper already emits (Chaoyi Chen).
- Rebased onto v7.3-rc3.
- Link to v3: https://lore.kernel.org/r/20260904-jh7110-clean-send-v3-0-484f9ae72715@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 (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,
--
Michal Wilczynski <m.wilczynski@samsung.com>
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.
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). Also note modetest needs -M verisilicon. If that is not it, could you send "dmesg | grep -iE 'verisilicon|inno|hdmi|vout'" and "ls /sys/class/drm/"? > >> --- >> 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, -- Michal Wilczynski <m.wilczynski@samsung.com>
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@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" -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,
On Tue, 15 Sep 2026, Michal Wilczynski wrote: > This series enables the display subsystem on the StarFive JH7110. Hi Michal, I tested your v4 patch series on my VisionFive2 1.3B with kernel 7.3-rc3 today and it works very well, except for 2 issues. Note, to make the screen refresh properly, I am using the noncoherent cache fixes from https://github.com/ganboing-jh7110/linux/commits/ganboing-jh7110-cache-fix-v1/ (specifically commits 3683d97, ef93e2c, 277db0b, and 26ce3e6) in addition to your patch. Issue 1: I have a Dell U2711 monitor which has limited HDMI 1.3 capability, so I invented my own Xorg mode to get a good frame rate: "2560x1440_40.22" 162.00 2560 2608 2640 2720 1440 1443 1448 1481 +hsync -vsync With this mode and your new driver, I started getting rows of black pixels flickering in the upper-left corner of my LCD screen. These weren't there back when I was running the same mode under the Keith Zhao driver from StarFive (drm/verisilicon v5 plus a bunch of patches for dma cache coherency) (https://patchwork.kernel.org/project/dri-devel/cover/20241120061848.196754-1-keith.zhao@starfivetech.com/). The glitches I saw suggested the sync polarity was being set incorrectly; the number of glitched rows was exactly the vsync pulse width plus 1 (i.e. "1440 1443 1448 1481" produced 6 bad rows, "1440 1443 1456 1481" produced 14, "1440 1441 1442 1481" produced 2, and so forth). I did a register dump between the two drivers and found that, although the DC8200 HSYNC and VSYNC registers were identical between the two versions, the hsync and vsync bits on the inno hdmi tx were swapped between the two. When I manually set the VIDEO_TIMING_CTL register from 0x09 to 0x05 (matching the output of Keith's driver), the glitches went away. Keith Zhao driver: === DC8200 display 0 === DC PANEL_CONFIG 0x1418 = 0x00001111 DC HSIZE 0x1430 = 0x0AA00A00 DC HSYNC 0x1438 = 0x45280A30 DC VSIZE 0x1440 = 0x05C905A0 DC VSYNC 0x1448 = 0xC2D405A3 DC DPI_CONFIG 0x14B8 = 0x00000005 DC FB_CONFIG 0x1518 = 0x14000000 DC FB_ADDRESS 0x1400 = 0x71200000 DC FB_STRIDE 0x1408 = 0x00002800 DC FB_SIZE 0x1810 = 0x02D00A00 DC FB_CONFIG_EX 0x1CC0 = 0x00002000 DC PANEL_START 0x1CCC = 0x00000001 DC DP_CONFIG 0x1CD0 = 0x0000000A DC FB_WATER_MARK 0x1CE8 = 0x00000000 DC PANEL_CONFIG_EX 0x2518 = 0x00000000 === INNO HDMI TX video timing === HDMI VIDEO_TIMING_CTL 0x08 = 0x05 HDMI EXT_HTOTAL_L 0x09 = 0xA0 HDMI EXT_HTOTAL_H 0x0A = 0x0A HDMI EXT_HBLANK_L 0x0B = 0xA0 HDMI EXT_HBLANK_H 0x0C = 0x00 HDMI EXT_HDELAY_L 0x0D = 0x70 HDMI EXT_HDELAY_H 0x0E = 0x00 HDMI EXT_HDURATION_L 0x0F = 0x20 HDMI EXT_HDURATION_H 0x10 = 0x00 HDMI EXT_VTOTAL_L 0x11 = 0xC9 HDMI EXT_VTOTAL_H 0x12 = 0x05 HDMI EXT_VBLANK 0x13 = 0x29 HDMI EXT_VDELAY 0x14 = 0x26 HDMI EXT_VDURATION 0x15 = 0x05 Your driver (showing only the changed values): DC DP_CONFIG 0x1CD0 = 0x00000000 DC PANEL_CONFIG_EX 0x2518 = 0x00000001 HDMI VIDEO_TIMING_CTL 0x08 = 0x09 Specifically the bit#s are different between the two drivers: inno_hdmi-starfive.h (Keith Zhao): inno-hdmi.c (generic): v_HSYNC_POLARITY_SF(n) ((n) << 2) v_HSYNC_POLARITY bit 3 v_VSYNC_POLARITY_SF(n) ((n) << 3) v_VSYNC_POLARITY bit 2 "_SF" suggests this change is specific to StarFive. The correct positions are HSYNC=bit 2 and VSYNC=bit 3 for the JH7110. I'm guessing that your 42-mode test passed because most CEA modes are +hsync +vsync, and this wouldn't show any difference if the two bits were transposed. Once the sync polarity is sorted, I'd be happy to give a Tested-by: on the series. -- Issue 2: This is more a feature request than an issue. Originally, I tried running this Xorg modeline, which worked well under Keith's driver: "2560x1440_49.90" 201.00 2560 2608 2640 2720 1440 1443 1448 1481 +hsync -vsync However, your driver would not accept this pixel clock. I then noticed you have a pre-PLL table of fixed clocks. Is there any chance you can change the code to compute the pre-PLL on the fly like how Keith does it, rather than use a table? Thanks for all your great work! Best regards, -Byron
在 2026-09-20日的 02:09 -0400,Byron Stanoszek写道: > On Tue, 15 Sep 2026, Michal Wilczynski wrote: > > > This series enables the display subsystem on the StarFive JH7110. > > Hi Michal, > > I tested your v4 patch series on my VisionFive2 1.3B with kernel 7.3- > rc3 today > and it works very well, except for 2 issues. Note, to make the screen > refresh > properly, I am using the noncoherent cache fixes from > https://github.com/ganboing-jh7110/linux/commits/ganboing-jh7110-cache-fix-v1/ > (specifically commits 3683d97, ef93e2c, 277db0b, and 26ce3e6) in > addition to > your patch. > > Issue 1: I have a Dell U2711 monitor which has limited HDMI 1.3 > capability, so > I invented my own Xorg mode to get a good frame rate: > > "2560x1440_40.22" 162.00 2560 2608 2640 2720 1440 1443 1448 1481 > +hsync -vsync > > With this mode and your new driver, I started getting rows of black > pixels > flickering in the upper-left corner of my LCD screen. These weren't > there back > when I was running the same mode under the Keith Zhao driver from > StarFive > (drm/verisilicon v5 plus a bunch of patches for dma cache coherency) > ( > https://patchwork.kernel.org/project/dri-devel/cover/20241120061848.196754-1-keith.zhao@starfivetech.com > /). > > The glitches I saw suggested the sync polarity was being set > incorrectly; the > number of glitched rows was exactly the vsync pulse width plus 1 > (i.e. > "1440 1443 1448 1481" produced 6 bad rows, "1440 1443 1456 1481" > produced 14, > "1440 1441 1442 1481" produced 2, and so forth). > > I did a register dump between the two drivers and found that, > although the > DC8200 HSYNC and VSYNC registers were identical between the two > versions, the > hsync and vsync bits on the inno hdmi tx were swapped between the > two. When I > manually set the VIDEO_TIMING_CTL register from 0x09 to 0x05 > (matching the > output of Keith's driver), the glitches went away. > > Keith Zhao driver: > > === DC8200 display 0 === > DC PANEL_CONFIG 0x1418 = 0x00001111 > DC HSIZE 0x1430 = 0x0AA00A00 > DC HSYNC 0x1438 = 0x45280A30 > DC VSIZE 0x1440 = 0x05C905A0 > DC VSYNC 0x1448 = 0xC2D405A3 > DC DPI_CONFIG 0x14B8 = 0x00000005 > DC FB_CONFIG 0x1518 = 0x14000000 > DC FB_ADDRESS 0x1400 = 0x71200000 > DC FB_STRIDE 0x1408 = 0x00002800 > DC FB_SIZE 0x1810 = 0x02D00A00 > DC FB_CONFIG_EX 0x1CC0 = 0x00002000 > DC PANEL_START 0x1CCC = 0x00000001 > DC DP_CONFIG 0x1CD0 = 0x0000000A > DC FB_WATER_MARK 0x1CE8 = 0x00000000 > DC PANEL_CONFIG_EX 0x2518 = 0x00000000 > > === INNO HDMI TX video timing === > HDMI VIDEO_TIMING_CTL 0x08 = 0x05 > HDMI EXT_HTOTAL_L 0x09 = 0xA0 > HDMI EXT_HTOTAL_H 0x0A = 0x0A > HDMI EXT_HBLANK_L 0x0B = 0xA0 > HDMI EXT_HBLANK_H 0x0C = 0x00 > HDMI EXT_HDELAY_L 0x0D = 0x70 > HDMI EXT_HDELAY_H 0x0E = 0x00 > HDMI EXT_HDURATION_L 0x0F = 0x20 > HDMI EXT_HDURATION_H 0x10 = 0x00 > HDMI EXT_VTOTAL_L 0x11 = 0xC9 > HDMI EXT_VTOTAL_H 0x12 = 0x05 > HDMI EXT_VBLANK 0x13 = 0x29 > HDMI EXT_VDELAY 0x14 = 0x26 > HDMI EXT_VDURATION 0x15 = 0x05 > > Your driver (showing only the changed values): > > DC DP_CONFIG 0x1CD0 = 0x00000000 > DC PANEL_CONFIG_EX 0x2518 = 0x00000001 > HDMI VIDEO_TIMING_CTL 0x08 = 0x09 > > Specifically the bit#s are different between the two drivers: > > inno_hdmi-starfive.h (Keith Zhao): inno-hdmi.c (generic): > v_HSYNC_POLARITY_SF(n) ((n) << 2) v_HSYNC_POLARITY bit 3 > v_VSYNC_POLARITY_SF(n) ((n) << 3) v_VSYNC_POLARITY bit 2 > > "_SF" suggests this change is specific to StarFive. The correct > positions are > HSYNC=bit 2 and VSYNC=bit 3 for the JH7110. In fact it's not SF specific, [1] pg.13 (full manual page 979) also shows the same for RK. It could be an error from Rockchip developers since the beginning. [1] https://github.com/DeciHD/rockchip_docs/blob/main/rk3128/TRM-chapter-24-hdmi-tx.pdf Thanks, Icenowy > > I'm guessing that your 42-mode test passed because most CEA modes are > +hsync > +vsync, and this wouldn't show any difference if the two bits were > transposed. > > Once the sync polarity is sorted, I'd be happy to give a Tested-by: > on the > series. > > -- > > Issue 2: This is more a feature request than an issue. Originally, I > tried > running this Xorg modeline, which worked well under Keith's driver: > > "2560x1440_49.90" 201.00 2560 2608 2640 2720 1440 1443 1448 1481 > +hsync -vsync > > However, your driver would not accept this pixel clock. I then > noticed you have > a pre-PLL table of fixed clocks. Is there any chance you can change > the code to > compute the pre-PLL on the fly like how Keith does it, rather than > use a table? > > Thanks for all your great work! > > Best regards, > -Byron > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
© 2016 - 2026 Red Hat, Inc.