Hello Icenowy, Maud, Dominique, On 9/7/2026 2:55 PM, Icenowy Zheng wrote: > 在 2026-09-07一的 08:02 +0200，Maud Spierings写道： >> Hi Dominique and Icenowy, >> >> On 9/7/26 06:01, Icenowy Zheng wrote: >>> 在 2026-09-06日的 17:16 -0400，Dominique Belhachemi写道： >>>> On Sun, Sep 6, 2026 at 11:19 AM Icenowy Zheng <[email protected]> >>>> 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 >>>>>>> < >>>>>>> [email protected] <mailto:[email protected]>> >>>>>>> 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. >>> >>> Thanks for the tips on documentation, and I verified this. >>> >>> It seems that Rockchip people made this always wrong, even with >>> their >>> pre-DRM display driver... [1] >>> >>> BTW I checked the Innosilicon dGPU driver code, and its >>> g3_ne_hdmi.h >>> source file also contains the definition of BIT(3) as VSYNC. (It's >>> quite weird that most logic of that driver is in some .o_shipped >>> blob, >>> but fortunately the g3 logic might be too new to be closed down) >>> >>> Thanks, >>> Icenowy >>> >>> [1] >>> https://github.com/rockchip-linux/kernel/blob/release-4.4/drivers/video/rockchip/hdmi/rockchip-hdmiv1/rockchip_hdmiv1_hw.h#L161 >>> >>>> >>>> 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 >> >> This also solves the devmem behaviour I saw, or well, doesn't realy >> explain it but does show what is actually happening. As Icenowy noted >> (maybe that was on telegram only?) the inno-hdmi regs are 8bit >> instead >> of 32 bit. >> >> What is actually happening is: >> >> devmem 0x29590000 b reads 0x29590000 as expected >> but >> devmem 0x29590004 b reads 0x29590001 >> devmem 0x29590008 b reads 0x29590002 >> .... >> devmem 0x29590020 b reads 0x29590008 >> >> For some reason the addressing is weird? >> >> With this change, the assigned clock change and removing the >> v_REG_CLK_INV | v_REG_CLK_SOURCE_SYS write to HDMI_SYS_CTRL, the >> display >> comes up from the start as it should! > > Well I checked the RK3128 TRM for these two bits, and their field > descriptions are -- "reserved". > > What can I react... >
You can take a look at the TRM of the RK61X[0]. I think it contains the register descriptions you're looking for :) [0]: https://dl.radxa.com/rock/docs/hw/ds/Rockchip%20RK61X%20TRM%20V1.3.1.pdf -- Best, Chaoyi
