00:01 <inode> https://pastebin.com/KAmZVEiP

00:04 <inode> clk_summary: https://pastebin.com/CqMbtH2S

00:05 <inode> might not be related, but also unusual is the orphaned sclk_hdmi_cec

00:06 <inode> this is what the kernel has always said since i got hdmi output to scrape by, if i switch my monitor off (or my tv when i've had it connected):

00:07 <inode> https://pastebin.com/DnJMR928

00:08 <inode> but everything appears as normal once switched on again

00:19 <Kwiboo> http://ix.io/281B is clk_summary on my rock64 rk3328, it does not look like it have a special cec clock there, and I am unsure what hdmi kernel patches I currently have applied

00:29 <inode> the cache edid patches didn't seem to change anything that i can see from drm debug messages so far

00:30 <Kwiboo> the Not using 1920x1080 mode: STALE in your v2 log also looks interesting, I have hot seen STALE before, I need to dig and see when STALE is being reported

00:31 <Kwiboo> does the edid cache change anything for the modetest ? is 1920x1080 still not reported?

00:33 <Kwiboo> also can you test without video=HDMI-A-1:e, when connector->force is used the detect callback may not be called and the edid modes never gets added, I will do more force test on my end tomorrow

00:35 <inode> ok

00:36 <inode> https://pastebin.com/A17Ea6dk

00:36 <inode> i see the size (mm) value reported by modetest is now 0x0

00:39 <Kwiboo> and also the edid blob is empty, so a new edid read has failed

00:41 <inode> now without video=HDMI-A-1:e ... https://pastebin.com/ZvRCTGKd

00:41 <inode> the connector always ends up disconnected if i don't specify it on the command line

00:45 <Kwiboo> strange, it could be related to the cec issue, since it detects hdmi and can read edid during startup but later fails

00:52 <tuxd3v> does any one knows if its possible now to build uboot for rockpro64 ?

00:52 <tuxd3v> Does the dts /uboot supports is well?

00:52 <tuxd3v> some time ago I tried and I couldn't boot it up..

01:15 <Kwiboo> inode: https://github.com/rock64-android/kernel/blob/thzy_develop/arch/arm/boot/dts/rk322x-clocks.dtsi#L1046-L1054 seems to indicate that xin24m should be parent clock to cec, could the commented out mux indicate that mux is not working and in mainline need to force parent in dts

08:18 <inode> Kwiboo: that's interesting find, thank you - i'll try reparenting when i get back to the device

09:11 <Kwiboo> inode: it also looks like the old 3.10 device tree use rockchip,cec_enable=<0> to disable cec on rk322x, so you could also try with removing the cec clock from hdmi node and disable CONFIG_DRM_DW_HDMI_CEC and see if that makes any difference

09:14 <archetech> building my first kernel for rock64 on the board got a mainline how to ?

09:16 <archetech> certain source or repo ?

11:15 <archetech> ayufans 4.4 config and 5.4.13

21:14 <inode> Kwiboo: turns out the unhandled irq message remains even with the cec clock disassociated from the hdmi node and CONFIG_DRM_DW_HDMI_CEC disabled - i think i need to get kgdb up and running

21:15 <inode> not specifically for the unhandled irq problem, but to see what's going on with regard to the probed mode list being reduced

21:27 <Kwiboo> from logs it looked like it fails to detect it is connected and do not read / faild to read new edid

21:41 <inode> maybe the logic i borrowed from rockchip-linux to configure hpd and ddc is inadequate or requires additional changes for reading hpd state and adjusting the connector status correctly - similar to dw_hdmi_rk3328_read_hpd()

21:53 <Kwiboo> the old rkdevelop uboot do not do anything special for read_hpd, see https://github.com/Caesar-github/uboot/blob/rkdevelop/drivers/video/drm/dw_hdmi.c#L2529-L2544 it only has special case for rk3328

22:05 <inode> i'm also using dw_hdmi_phy_read_hpd as the value of the read_hpd member of rk3228_hdmi_phy_ops https://patchwork.kernel.org/patch/10956787/ ... but if i'm not mistaken the rk3328 seems to get the voltage level of the ddc pair changed depending on the connector status? https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c#L358..L367

22:11 <Kwiboo> I think so, it changes between 5v and 3.3v on rk3328 if I am not mistaken

22:14 <Kwiboo> I did a quick compare of 4.4 rk322x.dtsi and mainline rk322x.dtsi and there is a diff in hdmi node interrupts, the mainline only have 35 but 4.4 and mainline rk3328 have both 35 and 71

22:14 <Kwiboo> "interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;" vs "interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;"

22:15 <inode> i should try adding that again, or digging up old logs from this channel - i remember mmind00 mentioning something about 71 when i was poking around with hdmi here initially

22:17 <inode> https://freenode.irclog.whitequark.org/linux-rockchip/2019-05-23

22:20 <Kwiboo> 71 is listed as rki2c3_int for rk3328, so it sounds like it should be there

22:22 <Kwiboo> based on https://freenode.irclog.whitequark.org/linux-rockchip/2019-05-22: for soc_con6 ... bit4 is "hdmi_ddcscl & i2c3_scl", bit5 is "hdmi_ddcsda & i2c3_sda", bit6 is hdmi_hpd ... and the value is 1 for 3.3V and 0 for 5V