With kernel 5.1.1 I get corrupted image on my Dell UP2715K screen (again). The symptomps are similar to the ones in bug 98461 (see also attachment 127570 [details]). In my theory this is caused by the two DisplayPort outputs not being in sync - the screen needs both tiles to be in sync (i.e. scanlines to match) to make a composite final image. The Dell UP2715K monitor has two DP 1.2 inputs, two tiles expecting 2560x2880@60Hz modes (as exposed in EDID/DisplayInfo data). Connected to Radeon Pro WX2100 (Polaris 12). This used to be actually working reliably in kernel 4.20.0, yesterday I fired up kernel 5.1.1 and only got garbage on my screen. Also tested drm-tip kernel that includes drm-next-5.2 branch from the agd5f repo (https://patchwork.freedesktop.org/patch/304430/) - same issue. I haven't got time to bisect the change yet, I was hoping you could point me to a possible commit that broke this. By any chance, do you AMD guys have a 5k tiled screen inhouse for testing?
Please attach the corresponding output of dmesg and Xorg log file.
Created attachment 144250 [details] dmesg drm.debug=0x1e (kernel 5.1.0-rc5-g9d6fea5744d6) This is drm-next-5.2 branch, head 9d6fea5744d6798353f "drm/amdgpu/psp: move psp version specific function pointers to early_init"
Created attachment 144251 [details] Xorg.0.log (kernel 5.1.0-rc5-g9d6fea5744d6)
Created attachment 144252 [details] dmesg drm.debug=0x1e (kernel 4.20.0-zen-g742adf1bca12-dirty) For the record, this is a custom 4.20.0 kernel that is proven realiable. Basically agd5f drm-next-4.21 branch at 674e78acae0dfb4beb5613 "drm/amd/display: Add fast path for cursor plane updates"
Have same issue on Vega FE + Dell UP2715K. Also it may be related to this bug: https://bugs.freedesktop.org/show_bug.cgi?id=105651
Manual bisect so far: good 0f74e484912626 drm/amd/display: 3.2.15 bad cf7d98d254e9ff drm/amd/display: 3.2.16
The offending commit is commit 5fc0cbfad4564856ee0f323d3f88a7cff19cc3f1 Author: Wenjing Liu <Wenjing.Liu@amd.com> Date: Fri Jan 18 18:19:51 2019 -0500 drm/amd/display: determine if a pipe is synced by plane state
Still no luck with 5.1.10
Broken in 5.3-rc1 Workaround to revert 5fc0cbfad4564856ee0f323d3f88a7cff19cc3f1 is still working.
Just added some debug to rc3 and tried to check what happens(in context of 5fc0cbfad4564856ee0f323d3f88a7cff19cc3f1). So in program_timing_sync() there is preparing of groups of pipes for sync. And looks like(in my case) pipe_set[j]->plane_state is always true, and all elements > 0 is removed from the pipe_set in this case, hence group_size == 1 and dc->hwss.enable_timing_synchronization() newer called. Contrary with old check !pipe_set[j]->stream_res.tg->funcs->is_blanked(pipe_set[j]->stream_res.tg) is always false and we have our sync. Maybe it should be !pipe_set[j]->plane_state instead of pipe_set[j]->plane_state ? I applied this change to my 5.3.0-rc3 build and so far everything looks ok. I do not understand the purpose of is_blanked or plane_state, maybe with mst hubs or other stuff it may be a different story, but in my simple config it looks like just a typo.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/781.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.