02:06 <macromorgan> let's see now... the offending clock is dclk_vopb_frac

02:17 <macromorgan> in 5.14 it's being requested to be set at 17000999, whereas the parent is 17000000. When we divide 17000999 by 17000000 we get zero and then subtract one gives us -1. This gives us 64 from the output of fls_long. Our fd->mwidth is 16. We shift 17000999 to the left by 48 bits (64-16) and we get the stupid large number of 7649082492112076800

02:18 <macromorgan> so that's where the number is coming from

02:50 <macromorgan> ...and fixed. Note that I probably want mmind00 or someone to push this up, since I think the fix will affect literally EVERY rockchip SoC with a VOP, and I don't know what the implications of that are. Long story short it's the assumption made on this line here that causes the issue: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/rockchip/rockchip_drm_vop.c

02:50 <macromorgan> #n1177

02:50 <macromorgan> err... https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/rockchip/rockchip_drm_vop.c#n1177

02:51 <macromorgan> if we delete the + 999 from this line the issue is resolved: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/rockchip/rockchip_drm_vop.c#n1196

02:55 <pgwipeout[m]> Very nice.

11:16 <diederik> Could this be relevant/related: https://github.com/LibreELEC/LibreELEC.tv/blob/master/projects/Rockchip/patches/linux/default/linux-0002-rockchip-from-list.patch#L55 ?

11:55 <pgwipeout[m]> I think that patch is related to the pll in the phy.

12:11 <diederik> I thought about as it seems to round a clock value to a round number which was also mentioned in the 'action plan'

12:33 <pgwipeout[m]> Yeah, that's definitely the internal hdmi pll. Though it is basing off the input clock to it.