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
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.