<Putti>
I have played with the device now for about 10 minutes and no corruption. Usually it comes withing couple minutes. (my point is just that maybe for some other reason the corruption didn't yet appear this time)
<ahajda>
There are multiple issues with devfreq and clocks, devfreq too aggresively lowers display clock frequencies, as a result DMA transfers of overlays are too slow and result in screen corruption
<Putti>
ahajda, so the fix should be done in kernel?
<Putti>
I can write a bug report somewhere and gather more information about this if needed but I'm still a beginner with graphics so I would need some help to actually do any code changes to fix this
afaerber has quit [Remote host closed the connection]
<krzk>
Putti: yes, this should be fixed probably in the kernel...
<krzk>
However I would like to see rather some more generic approach, based on QoS or other mechanism...
<mszyprow>
krzk: my workaround was for mixer/hdmi path
<krzk>
mszyprow: isn't this the same bus used?
<mszyprow>
krzk: it looks that similar issue exists for fimd/lcd panel path
<Putti>
ok
<krzk>
anyway, there are two workarounds now - disable devfreq or limit/remove the OPPs so it will not scale down that much
<mszyprow>
krzk: it looks that lcd0 bus should be 'fixed' the same way
<krzk>
mszyprow: maybe we should just ask all downstream distros/kernels to disable the devfreq in their config :)
<krzk>
srsly, it brought so many problems...
<mszyprow>
well, we can start from exynos_defconfig ;)
<krzk>
actually there it makes sense for testing so it will expose these issues...
<krzk>
you know, devfreq is testing ready but since many years not production ready
dllud has joined #linux-exynos
genii has joined #linux-exynos
GrimKriegor has joined #linux-exynos
<dllud>
Hi krzk and mszyprow, thanks for the help with the bug that Putti report. I am taking a look at it too. Where do you think it's best to keep a record of it: linux-exynos mailing list or https://bugzilla.kernel.org/ ?