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
Status: NEW
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:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-05-13 11:04 UTC by Tomas Bzatek
Modified: 2019-08-08 20:48 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:


Attachments
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

Note You need to log in before you can comment on or make changes to this bug.
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.


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.