| Bug ID | 110671 |
|---|---|
| Summary | Regression: DP outputs out of sync on dual-DP tiled 5k screen |
| Product | DRI |
| Version | DRI git |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | DRM/AMDgpu |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | bugs@bzatek.net |
With kernel 5.1.1 I get corrupted image on my Dell UP2715K scr= een (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 t= o Radeon Pro WX2100 (Polaris 12). This used to be actually working reliably in kernel 4.20.0, yesterday I fir= ed up kernel 5.1.1 and only got garbage on my screen. Also tested drm-tip kern= el that includes drm-next-5.2 branch from the agd5f repo (https://patchw= ork.freedesktop.org/patch/304430/) - same issue. I haven't got time to bisect the change yet, I was hoping you could point m= e to a possible commit that broke this. By any chance, do you AMD guys have a 5k tiled screen inhouse for testing?
| What | Removed | Added |
|---|---|---|
| CC | nicholas.kazlauskas@amd.com |
Please attach the corresponding output of dmesg and Xorg log f= ile.
| What | Removed | Added |
|---|---|---|
| CC | bugs@bzatek.net |
Created attachment 144250 [details]
dmesg drm.debug=3D0x1e (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=3D0x1e (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=3D105651
| What | Removed | Added |
|---|---|---|
| See Also | https://bugs.freedesktop.org/show_bug.cgi?id=3D105651 |
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
Broken in 5.3-rc1 Workaround to revert 5fc0cbfad4564856ee0f323d3f88a7cff19cc3f1 is still work= ing.
Just added some debug to rc3 and tried to check what happens(i= n context of 5fc0cbfad4564856ee0f323d3f88a7cff19cc3f1). So in program_timing_sync() there is preparing of groups of pipes for sync.= =20 And looks like(in my case) pipe_set[j]->plane_state is always true,=20 and all elements > 0 is removed from the pipe_set in this case,=20 hence group_size =3D=3D 1 and dc->hwss.enable_timing_synchronization() n= ewer called. Contrary with old check !pipe_set[j]->stream_res.tg->funcs->is_blanked(pipe_set[j]->str= eam_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.
| What | Removed | Added |
|---|---|---|
| See Also | https://bugs.freedesktop.org/show_bug.cgi?id=3D101633 |
| What | Removed | Added |
|---|---|---|
| Resolution | --- | MOVED |
| Status | NEW | RESOLVED |
-- 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.