[PATCH v2 13/15] phy: starfive: Add jh7110-inno-hdmi-phy driver

Dominique Belhachemi domibel at debian.org
Sun Sep 6 14:16:08 PDT 2026


On Sun, Sep 6, 2026 at 11:19 AM Icenowy Zheng <uwu at icenowy.me> wrote:
>
> 在 2026-09-06日的 16:59 +0200,Maud Spierings写道:
> > On 9/6/26 07:39, Dominique Belhachemi wrote:
> > > On Sun, Aug 30, 2026 at 10:17 AM Maud Spierings
> > > <maud_spierings at murena.io <mailto:maud_spierings at murena.io>> wrote:
> > >
> > >     I was still having some glitching happening on the display, but
> > > I've
> > >     found the way to fix that, the question is what is actually
> > >     happening here.
> > >
> > >         0x29590020 <- 0x00000005
> > >     This one I have no idea, it is 0x00000009 with this patch
> > > series but
> > >     with the vendor kernel I get the value above. When I hook up my
> > >     external
> > >     display (regular 1440p) this becomes 0x0000000D on the vendor
> > > kernel.
> > >
> > >     But I can't find this register being written to anywhere there?
> > >
> > >
> > > Maybe this needs to be swapped?
> > >
> > > drivers/gpu/drm/bridge/inno-hdmi.c
> > >    -#define v_HSYNC_POLARITY(n)          ((n) << 3)
> > >    -#define v_VSYNC_POLARITY(n)          ((n) << 2)
> > >    +#define v_HSYNC_POLARITY(n)          ((n) << 2)
> > >    +#define v_VSYNC_POLARITY(n)          ((n) << 3)
>
> Very weirdly, the original definition here matches current mainline
> inno-hdmi.c, but the changed definition matches JH7110 vendor
> inno_hdmi.h [1].
>

The vendor code is correct and matches the RK3128 TRM.

HDMI_reg08
    Bit  Attr  Reset  Description
    3    RW    0x0    vs_polarity   VSYNC polarity   1'b0: Negative
1'b1: Positive
    2    RW    0x0    hs_polarity   HSYNC polarity   1'b0: Negative
1'b1: Positive

Nobody noticed this so far because in 720p/1080p both polarities are
positive, but Maud's 3:2 panel has differing H/V polarity.

Best
-Dominique



More information about the linux-riscv mailing list