在 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/[email protected] > /). > > 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 > [email protected] > http://lists.infradead.org/mailman/listinfo/linux-riscv
