Bug 110671 - Regression: DP outputs out of sync on dual-DP tiled 5k screen
Summary: Regression: DP outputs out of sync on dual-DP tiled 5k screen
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/AMDgpu (show other bugs)
Version: DRI git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
Depends on:
Reported: 2019-05-13 11:04 UTC by Tomas Bzatek
Modified: 2019-11-19 09:26 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:

dmesg drm.debug=0x1e (kernel 5.1.0-rc5-g9d6fea5744d6) (2.50 MB, text/plain)
2019-05-13 19:22 UTC, Tomas Bzatek
no flags Details
Xorg.0.log (kernel 5.1.0-rc5-g9d6fea5744d6) (41.09 KB, text/plain)
2019-05-13 19:23 UTC, Tomas Bzatek
no flags Details
dmesg drm.debug=0x1e (kernel 4.20.0-zen-g742adf1bca12-dirty) (648.95 KB, text/plain)
2019-05-13 19:38 UTC, Tomas Bzatek
no flags Details

Description Tomas Bzatek 2019-05-13 11:04:19 UTC
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?
Comment 1 Michel Dänzer 2019-05-13 13:25:16 UTC
Please attach the corresponding output of dmesg and Xorg log file.
Comment 2 Tomas Bzatek 2019-05-13 19:22:14 UTC
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"
Comment 3 Tomas Bzatek 2019-05-13 19:23:15 UTC
Created attachment 144251 [details]
Xorg.0.log (kernel 5.1.0-rc5-g9d6fea5744d6)
Comment 4 Tomas Bzatek 2019-05-13 19:38:14 UTC
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"
Comment 5 Denys 2019-05-18 12:31:24 UTC
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
Comment 6 Tomas Bzatek 2019-05-20 20:23:05 UTC
Manual bisect so far:

good 0f74e484912626 drm/amd/display: 3.2.15
bad  cf7d98d254e9ff drm/amd/display: 3.2.16
Comment 7 Tomas Bzatek 2019-05-20 21:12:26 UTC
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
Comment 8 Denys 2019-06-15 21:06:05 UTC
Still no luck with 5.1.10
Comment 9 Denys 2019-07-22 20:30:49 UTC
Broken in 5.3-rc1

Workaround to revert 5fc0cbfad4564856ee0f323d3f88a7cff19cc3f1 is still working.
Comment 10 Denys 2019-08-08 20:41:59 UTC
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.
Comment 11 Martin Peres 2019-11-19 09:26:15 UTC
-- 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.