在 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 ([email protected]) 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: > > [email protected], > > [email protected], [email protected] and [email protected]. > > > > Before patch 11, four of the advertised modes failed: > > [email protected] > > (146.250 MHz), [email protected] (121.750), [email protected] (81.768) > > and > > [email protected] (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/[email protected]/ > > > > --- > > 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/[email protected] > > > > 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/[email protected] > > > > 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/[email protected] > > > > 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,
