Re: [PATCH v4 00/20] drm: starfive: jh7110: Enable display subsystem

[Byron Stanoszek <gandalf@winds.org>]

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