07:36 <ahajda> Putti: please try disable devfreq

08:14 <Putti> ahajda, disabling devfreq seems to have solved the problem, so thank you! But why does it solve it? I wrote already a more detailed bug report about this here: https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/issues/24

08:16 <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)

08:22 <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

08:23 <Putti> ahajda, so the fix should be done in kernel?

08:25 <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

11:28 <krzk> Putti: yes, this should be fixed probably in the kernel...

11:28 <krzk> I think mszyprow was fixing this with: https://patchwork.kernel.org/patch/10861757/

11:29 <krzk> However I would like to see rather some more generic approach, based on QoS or other mechanism...

11:29 <mszyprow> krzk: my workaround was for mixer/hdmi path

11:29 <krzk> mszyprow: isn't this the same bus used?

11:29 <mszyprow> krzk: it looks that similar issue exists for fimd/lcd panel path

11:29 <Putti> ok

11:30 <krzk> anyway, there are two workarounds now - disable devfreq or limit/remove the OPPs so it will not scale down that much

11:31 <mszyprow> krzk: it looks that lcd0 bus should be 'fixed' the same way

11:33 <krzk> mszyprow: maybe we should just ask all downstream distros/kernels to disable the devfreq in their config :)

11:34 <krzk> srsly, it brought so many problems...

11:34 <mszyprow> well, we can start from exynos_defconfig ;)

11:36 <krzk> actually there it makes sense for testing so it will expose these issues...

11:37 <krzk> you know, devfreq is testing ready but since many years not production ready

14:50 <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/ ?

14:51 <mszyprow> dllud: linux-samsung-soc@vger.kernel.org

14:51 <dllud> thanks