08:53 <inode> i am trying to get hdmi video output on the rk3229 device i'm playing with. so far, i have added a bunch of entries into rk322x.dtsi (vop, vop_mmu, hdmi, hdmi_phy, etc. with set status = "okay" for each in my rk3229-whatever.dts) based on my findings from kernel-develop-4.4.

08:54 <inode> i have probably got a few parameters incorrect, so far i have complaints about being unable to power down the PHY, and the PHY PLL failing to lock

08:55 <inode> although rockchip-drm has spawned a dri card device and a framebuffer if i look in /dev

08:55 <inode> https://pastebin.com/qWBPKBkc

08:56 <inode> lines 122 to 133 show messages about rockchip-vop, dwhdmi-rockchip, rockchip-drm initialization

08:57 <inode> the current cmdline is shown on line 26

08:59 <inode> ^ " storagemedia=emmc loader.timestamp=2018-07-12_15:15:42 hdmi.vic=-1 tve.format=-1 SecureBootCheckOk=0" is appended by u-boot - which is still stock, i haven't touched it

09:06 <inode> i cannot reproduce a particular panic i was seeing earlier about irq 35 being ignored (the first of two specified for the hdmi dtsi entry's interrupts list), but if i comment out irq 35 (/* <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>, */) and leave irq 71 entact then i see my monitor complain about the received mode being incorrect

09:07 <inode> and "dwhdmi-rockchip 200a0000.hdmi: PHY failed to power down" does not appear in the kernel messages

09:07 <inode> before removing irq 35 from the list, there was no signal received by the monitor

09:08 <inode> # echo 1 > /sys/class/graphics/fb0/blank

09:08 <inode> causes the monitor to report no signal

09:09 <inode> # echo 0 > /sys/class/graphics/fb0/blank

09:09 <inode> brings back the monitor's on screen warning about the current input timing being incorrect

09:09 <inode> and the kernel then says:

09:09 <inode> [ 342.210667] dwhdmi-rockchip 200a0000.hdmi: PHY PLL failed to lock

09:11 <inode> any ideas on what i could check?

09:30 <mmind00> inode: power-domains and regulators come to mind ... in any case, your irq 35 should be the irq to use while 71 is the "hdmi-wakeup-irq" that isn't used currently I think

09:31 <mmind00> inode: also, in the rockchip_drm files you could looks for the clk_set_rate calls and compare what it requests and actually gets (there should be clk_round_rate calls before that)

09:31 <mmind00> sometimes there are subtle bugs in the clock drivers for clocks that haven't been used so far

09:36 <inode> i noticed in clk-rk3228.c linux-5.1 has: GATE(ACLK_GPU, "aclk_gpu", "aclk_gpu_pre", 0, RK2928_CLKGATE_CON(13), 14, GFLAGS) - but for kernel-develop-4.4: s/RK2928_CLKGATE_CON(7)/

09:36 <inode> i assume the kernel-develop-4.4 is more likely to be correct?

10:23 <vicencb> inode: mmind00: this remembers me some hdmi issues that could be related to clocks

10:23 <vicencb> http://lists.infradead.org/pipermail/linux-rockchip/2018-February/019612.html

10:23 <vicencb> The first was fixed, the second and third are still active and there is a new one.

10:23 <vicencb> The new fourth issue is that when running a kernel that has been booted from kexec, flickering appears when more than half of the display is redrawn.

10:23 <vicencb> Regarding the second one: since audio was added i noticed that when the blue strip appears then the audio is muted.

10:25 <mmind00> inode: likely ... although aclk_gpu is the clock for mali-gpu and doesn't affect hdmi

10:27 <mmind00> vicencb: can you try with a most recent kernel, regarding the strip (number 2) ... there was a patch some weeks ago, which I guess should be in 5.3 merge-window now

10:28 <mmind00> vicencb: although I think in all cases I've seen it, it was more pink hue

10:28 <vicencb> mmind00: the color could not be exact

10:29 <vicencb> I've been running on master for some time, now at v5.1-10742-g35c99ffa20ed

10:29 <vicencb> and have to recognize that have not seen it for some time

10:30 <vicencb> as it was random, i supposed was lucky. But if it is fixed, the better!

10:31 <mmind00> vicencb: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d15d9fd02575ecfada92d42f655940c4f10af842 is the commit in question

10:33 <vicencb> mmind00: good

10:34 <vicencb> do you know anything about the HPD (hot plug detect) and the flickering? have you ever seen any of those?

10:35 <vicencb> regarding the HPD. It is only reproducible when the hdmi is off, but an update of Xorg removed the "xset dpms force off" function, but still reproducible with Sway.

11:13 <mmind00> vicencb: sadly nope ... my testing generally consists of "does it display a console", I don't really have a daily use of those

12:00 <vicencb> mmind00: ok, no worries