[PATCH v5 00/21] drm: starfive: jh7110: Enable display subsystem
Icenowy Zheng
zhengxingda at iscas.ac.cn
Tue Sep 29 08:02:10 PDT 2026
在 2026-09-29二的 22:54 +0800，Icenowy Zheng写道：
> 在 2026-09-29二的 12:30 +0200，Michal Wilczynski写道：
> > This series enables the display subsystem on the StarFive JH7110.
> >
> > Merging: the series splits by subsystem, there is no build
> > dependency
> > between the blocks, and each block lands in the tree that already
> > owns
> > those files:
> >
> > drm-misc 1, 3, 6, 8-13, 16
> > drivers/gpu/drm/bridge/, include/drm/bridge/ and the display
> > bindings. Patch 1 is an inno-hdmi fix with a Fixes: tag; it
> > applies
> > to Rockchip as much as to StarFive and is independent of the
> > rest,
> > so it can go on its own.
> >
> > linux-phy (Vinod) 2, 17-19
> > drivers/phy/, include/linux/phy/ and bindings/phy/, all covered
> > by
> > the GENERIC PHY FRAMEWORK entry.
> >
> > Conor's tree 4, 5, 7, 14-15, 20
> > bindings/soc/starfive/ (STARFIVE SOC DRIVERS),
> > arch/riscv/boot/dts/starfive/ (STARFIVE DEVICETREES), and
> > drivers/soc/starfive/, which this series creates.
> >
> > - 21
> > MAINTAINERS.
> >
> > There are no out-of-tree dependencies: the dc8200 driver, the
> > th1520
> > reset controller and the inno-hdmi bridge that the RFC listed as
> > prerequisites are all upstream now.
> >
> > One in-tree dependency: the clk patch that was 14/20 in v4 has been
> > applied by Brian Masney so it is dropped here. The DT patch needs
> > it
> > at
> > runtime for the pixel MUXes to follow the PHY, so this series wants
> > that
> > commit present.
Oh I forgot to pick this patch, which is
af384d6e0573b416a7a28e0ab6300d797cae369d in linux-next.
Sorry for the disturbance.
Thanks,
Icenowy
> >
> > 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 11 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 12 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 17-19 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 17
> > factors
> > out
> > the pre-PLL config format, table lookup, determine_rate,
> > recalc_rate
> > and
> > the pre-PLL programming; patch 18 moves Rockchip onto it; patch 19
> > adds
> > the JH7110 driver. Pixel clock tables, post-PLL and analog config
> > stay
> > SoC specific.
> >
> > Patch 18 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.
> >
>
> I got a weird regression with the v5 revision of this patchset:
>
> With a MS2130 capture card, /sys/class/drm/card0-HDMI-A-1/modes now
> only lists 4096x2160 and 3840x2160 modes. All lower resolutions modes
> disappeared (including the preferred 1280x720 74.25M standard mode).
>
> The edid-decode result of this capture card is listed below:
>
> ```
> edid-decode (hex):
>
> 00 ff ff ff ff ff ff 00 21 57 36 18 bd e9 02 00
> 25 1d 01 03 80 35 1d 78 22 ee 91 a3 54 4c 99 26
> 0f 50 54 21 0f 00 81 00 81 40 81 80 90 40 95 00
> 01 01 a9 40 b3 00 01 1d 00 72 51 d0 1e 20 6e 28
> 55 00 0f 48 42 00 00 1e 0e 1f 00 80 51 00 1e 30
> 40 80 37 00 0f 48 42 00 00 1c 00 00 00 10 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc
> 00 4d 41 43 52 4f 53 49 4c 49 43 4f 4e 0a 01 19
>
> 02 03 37 f1 55 02 11 13 84 1f 10 03 12 06 15 07
> 16 05 14 5e 5f 63 64 20 21 22 23 09 7f 07 83 01
> 00 00 6e 03 0c 00 10 00 00 3c 20 00 80 01 02 03
> 04 e5 0e 61 60 65 66 66 21 50 b0 51 00 1b 30 40
> 70 36 00 0f 48 42 00 00 1e 66 21 56 aa 51 00 1e
> 30 46 8f 33 00 0f 48 42 00 00 1e 8c 0a d0 8a 20
> e0 2d 10 10 3e 96 00 10 09 00 00 00 18 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 49
>
> ----------------
>
> Block 0, Base EDID:
> EDID Structure Version & Revision: 1.3
> Vendor & Product Identification:
> Manufacturer: HJW
> Model: 6198
> Serial Number: 190909
> Made in: week 37 of 2019
> Basic Display Parameters & Features:
> Digital display
> Maximum image size: 53 cm x 29 cm
> Gamma: 2.20
> DPMS levels: Off
> Monochrome or grayscale display
> First detailed timing is the preferred timing
> Color Characteristics:
> Red : 0.6396, 0.3300
> Green: 0.2998, 0.5996
> Blue : 0.1503, 0.0595
> White: 0.3125, 0.3291
> Established Timings I & II:
> DMT 0x04: 640x480 59.940476 Hz 4:3 31.469 kHz
> 25.175000 MHz
> DMT 0x09: 800x600 60.316541 Hz 4:3 37.879 kHz
> 40.000000 MHz
> DMT 0x10: 1024x768 60.003840 Hz 4:3 48.363 kHz
> 65.000000 MHz
> DMT 0x11: 1024x768 70.069359 Hz 4:3 56.476 kHz
> 75.000000 MHz
> DMT 0x12: 1024x768 75.028582 Hz 4:3 60.023 kHz
> 78.750000 MHz
> DMT 0x24: 1280x1024 75.024675 Hz 5:4 79.976 kHz
> 135.000000 MHz
> Standard Timings:
> DMT 0x1c: 1280x800 59.810326 Hz 16:10 49.702 kHz
> 83.500000 MHz
> DMT 0x20: 1280x960 60.000000 Hz 4:3 60.000 kHz
> 108.000000 MHz
> DMT 0x23: 1280x1024 60.019740 Hz 5:4 63.981 kHz
> 108.000000 MHz
> DMT 0x2a: 1400x1050 59.978442 Hz 4:3 65.317 kHz
> 121.750000 MHz
> DMT 0x2f: 1440x900 59.887445 Hz 16:10 55.935 kHz
> 106.500000 MHz
> DMT 0x33: 1600x1200 60.000000 Hz 4:3 75.000 kHz
> 162.000000 MHz
> DMT 0x3a: 1680x1050 59.954250 Hz 16:10 65.290 kHz
> 146.250000 MHz
> Detailed Timing Descriptors:
> DTD 1: 1280x720 60.000000 Hz 16:9 45.000 kHz
> 74.250000
> MHz (1039 mm x 584 mm)
> Hfront 110 Hsync 40 Hback 220 Hpol P
> Vfront 5 Vsync 5 Vback 20 Vpol P
> DTD 2: 1280x768 59.870228 Hz 5:3 47.776 kHz
> 79.500000
> MHz (1039 mm x 584 mm)
> Hfront 64 Hsync 128 Hback 192 Hpol N
> Vfront 3 Vsync 7 Vback 20 Vpol P
> Dummy Descriptor:
> Display Product Name: 'MACROSILICON'
> Extension blocks: 1
> Checksum: 0x19
>
> ----------------
>
> Block 1, CTA-861 Extension Block:
> Revision: 3
> Underscans IT Video Formats by default
> Basic audio support
> Supports YCbCr 4:4:4
> Supports YCbCr 4:2:2
> Native detailed modes: 1
> Video Data Block:
> VIC 2: 720x480 59.940060 Hz 4:3 31.469 kHz
> 27.000000 MHz
> VIC 17: 720x576 50.000000 Hz 4:3 31.250 kHz
> 27.000000 MHz
> VIC 19: 1280x720 50.000000 Hz 16:9 37.500 kHz
> 74.250000 MHz
> VIC 4: 1280x720 60.000000 Hz 16:9 45.000 kHz
> 74.250000 MHz (native)
> VIC 31: 1920x1080 50.000000 Hz 16:9 56.250 kHz
> 148.500000 MHz
> VIC 16: 1920x1080 60.000000 Hz 16:9 67.500 kHz
> 148.500000 MHz
> VIC 3: 720x480 59.940060 Hz 16:9 31.469 kHz
> 27.000000 MHz
> VIC 18: 720x576 50.000000 Hz 16:9 31.250 kHz
> 27.000000 MHz
> VIC 6: 1440x480i 59.940060 Hz 4:3 15.734 kHz
> 27.000000 MHz
> VIC 21: 1440x576i 50.000000 Hz 4:3 15.625 kHz
> 27.000000 MHz
> VIC 7: 1440x480i 59.940060 Hz 16:9 15.734 kHz
> 27.000000 MHz
> VIC 22: 1440x576i 50.000000 Hz 16:9 15.625 kHz
> 27.000000 MHz
> VIC 5: 1920x1080i 60.000000 Hz 16:9 33.750 kHz
> 74.250000 MHz
> VIC 20: 1920x1080i 50.000000 Hz 16:9 28.125 kHz
> 74.250000 MHz
> VIC 94: 3840x2160 25.000000 Hz 16:9 56.250 kHz
> 297.000000 MHz
> VIC 95: 3840x2160 30.000000 Hz 16:9 67.500 kHz
> 297.000000 MHz
> VIC 99: 4096x2160 25.000000 Hz 256:135 56.250 kHz
> 297.000000 MHz
> VIC 100: 4096x2160 30.000000 Hz 256:135 67.500 kHz
> 297.000000 MHz
> VIC 32: 1920x1080 24.000000 Hz 16:9 27.000 kHz
> 74.250000 MHz
> VIC 33: 1920x1080 25.000000 Hz 16:9 28.125 kHz
> 74.250000 MHz
> VIC 34: 1920x1080 30.000000 Hz 16:9 33.750 kHz
> 74.250000 MHz
> Audio Data Block:
> Linear PCM:
> Max channels: 2
> Supported sample rates (kHz): 192 176.4 96 88.2 48 44.1 32
> Supported sample sizes (bits): 24 20 16
> Speaker Allocation Data Block:
> FL/FR - Front Left/Right
> Vendor-Specific Data Block (HDMI), OUI 00-0C-03:
> Source physical address: 1.0.0.0
> Maximum TMDS clock: 300 MHz
> Extended HDMI video details:
> HDMI VICs:
> HDMI VIC 1: 3840x2160 30.000000 Hz 16:9 67.500 kHz
> 297.000000 MHz
> HDMI VIC 2: 3840x2160 25.000000 Hz 16:9 56.250 kHz
> 297.000000 MHz
> HDMI VIC 3: 3840x2160 24.000000 Hz 16:9 54.000 kHz
> 297.000000 MHz
> HDMI VIC 4: 4096x2160 24.000000 Hz 256:135 54.000 kHz
> 297.000000 MHz
> YCbCr 4:2:0 Video Data Block:
> VIC 97: 3840x2160 60.000000 Hz 16:9 135.000 kHz
> 594.000000 MHz
> VIC 96: 3840x2160 50.000000 Hz 16:9 112.500 kHz
> 594.000000 MHz
> VIC 101: 4096x2160 50.000000 Hz 256:135 112.500 kHz
> 594.000000 MHz
> VIC 102: 4096x2160 60.000000 Hz 256:135 135.000 kHz
> 594.000000 MHz
> Detailed Timing Descriptors:
> DTD 3: 1360x768 60.015162 Hz 85:48 47.712 kHz
> 85.500000
> MHz (1039 mm x 584 mm)
> Hfront 64 Hsync 112 Hback 256 Hpol P
> Vfront 3 Vsync 6 Vback 18 Vpol P
> DTD 4: 1366x768 59.789541 Hz 683:384 47.712 kHz
> 85.500000
> MHz (1039 mm x 584 mm)
> Hfront 70 Hsync 143 Hback 213 Hpol P
> Vfront 3 Vsync 3 Vback 24 Vpol P
> DTD 5: 720x480 59.940060 Hz 3:2 31.469 kHz
> 27.000000
> MHz (16 mm x 9 mm)
> Hfront 16 Hsync 62 Hback 60 Hpol N
> Vfront 9 Vsync 6 Vback 30 Vpol N
> Checksum: 0x49 Unused space in Extension Block: 18 bytes
> ```
>
> Thanks,
> Icenowy
>
> > 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 11, 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.
> >
> > 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.
> >
> > Notes
> > =====
> >
> > The JH7110 has no central MAINTAINERS entry and maintainership is
> > fragmented, so patch 21 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 21.
> >
> > 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 v5:
> > - Rebased onto v7.3-rc5.
> > - Dropped the clk patch, applied as af384d6e0573.
> > - New patch 13 makes the HDMI_SYS_CTRL register clock source
> > selectable
> > per platform, and the JH7110 selects the TMDS clock. The driver
> > drove
> > the register interface from the system clock for everyone, and a
> > Framework 13 panel flickers continuously that way (Maud
> > Spierings).
> > Rockchip keeps the system clock, so this is a no-op there. This
> > was
> > listed as a known limitation in v4.
> > - New patch 1 fixes v_HSYNC_POLARITY and v_VSYNC_POLARITY, which
> > have
> > been swapped in inno-hdmi since the driver was merged. The
> > hardware
> > puts HSYNC in bit 2 and VSYNC in bit 3, and the driver had them
> > the
> > other way round. Almost all CEA modes drive both syncs with the
> > same
> > polarity, so the two writes are indistinguishable and the bug
> > only
> > shows on a mode whose polarities differ - a band of black rows at
> > the
> > top of the screen, vsync_end - vsync_start + 1 rows tall.
> > Reported
> > independently by Dominique Belhachemi, Maud Spierings and Byron
> > Stanoszek, and confirmed against the RK3128 TRM by Icenowy Zheng,
> > so
> > this is a Rockchip fix too.
> > - Added a 201 MHz entry to the JH7110 pre-PLL table for a 2560x1440
> > mode Byron Stanoszek runs on a Dell U2711. It is derived the same
> > way
> > as the neighbouring entries (fbdiv 134, /16, VCO 3.216 GHz) but I
> > have
> > no sink that asks for it, so it is untested on my hardware.
> > - Moved the hdmi-subsystem binding from bindings/mfd/ to
> > bindings/soc/starfive/, next to the vout-subsystem binding and
> > matching
> > its driver in drivers/soc/starfive/. The mfd/ path was left over
> > from
> > when the driver was called hdmi-mfd; nothing in the series is an
> > MFD
> > device, and it meant one isolated binding patch would have had to
> > go
> > through the MFD tree on its own.
> > - The commit message for "Split probe out of bind" claimed a
> > matching
> > inno_hdmi_remove(); no such function exists, so the claim is
> > gone.
> > - Dropped Joshua Peisach's Reviewed-by from the PHY driver patch as
> > well,
> > since that patch changed in v5.
> > - Dropped Joshua Peisach's Reviewed-by from the binding patches; he
> > said
> > he is not reviewing DT (Krzysztof Kozlowski). It is kept on the
> > driver
> > patches he did look at.
> > - Removed a probe-time clk_set_rate() from the PHY driver. It
> > programmed
> > a default rate, and .set_rate writes PHY registers that live in
> > the
> > window gated by the controller's system clock - a clock the PHY
> > cannot
> > hold without creating a probe cycle with voutcrg.
> > - Link to v4:
> > https://lore.kernel.org/r/20260915-jh7110-clean-send-v4-0-f0e4fd6f2cc8@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 (21):
> > drm/bridge: inno-hdmi: fix swapped HSYNC and VSYNC polarity
> > dt-bindings: phy: Add starfive,jh7110-inno-hdmi-phy
> > dt-bindings: display: bridge: Add starfive,jh7110-inno-hdmi-
> > controller
> > dt-bindings: soc: starfive: 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
> > drm/bridge: inno-hdmi: Make the register clock source
> > selectable
> > soc: starfive: Add jh7110-hdmi-subsystem driver
> > soc: starfive: Add jh7110-vout-subsystem driver
> > 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 +
> > .../phy/starfive,jh7110-inno-hdmi-phy.yaml | 49 ++
> > .../starfive/starfive,jh7110-hdmi-subsystem.yaml | 95 ++++
> > .../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/gpu/drm/bridge/Kconfig | 11 +
> > drivers/gpu/drm/bridge/Makefile | 1 +
> > drivers/gpu/drm/bridge/inno-hdmi.c | 120 ++++-
> > drivers/gpu/drm/bridge/jh7110-inno-hdmi.c | 298
> > +++++++++++
> > 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 | 582
> > +++++++++++++++++++++
> > 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 | 12 +-
> > include/linux/phy/inno-hdmi-phy.h | 85 +++
> > 29 files changed, 2344 insertions(+), 189 deletions(-)
> > ---
> > base-commit: 72d3fcf802c45d00b300f25b848a93c3a2bd7c7e
> > change-id: 20251031-jh7110-clean-send-7d2242118026
> > prerequisite-patch-id: f0e814166bef9f12a11c54de07203b17bd97a027
> >
> > Best regards,
More information about the Linux-rockchip
mailing list