Bug 107980 - (Tiled) MST display Dell UP3214Q only initialized very late
Summary: (Tiled) MST display Dell UP3214Q only initialized very late
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: Other All
: medium enhancement
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
Whiteboard: Triaged, ReadyForDev
Depends on:
Reported: 2018-09-18 15:39 UTC by Paul Menzel
Modified: 2019-11-29 17:52 UTC (History)
2 users (show)

See Also:
i915 platform: SKL
i915 features: display/DP MST

Linux 4.19-rc4+ (drm-tip) messages (1.02 MB, text/plain)
2018-09-18 15:39 UTC, Paul Menzel
no flags Details
Linux 5.1 messages (dmesg) (494.08 KB, text/plain)
2019-05-09 13:01 UTC, Paul Menzel
no flags Details

Description Paul Menzel 2018-09-18 15:39:37 UTC
Created attachment 141642 [details]
Linux 4.19-rc4+ (drm-tip) messages

Using the MST display Dell UP3214Q connected over DisplayPort, with at least Linux 4.14, Linux 4.18.6, and drm-tip, the early Linux messages are not shown on the screen.

Note, that the firmware of the Fujitsu system is not able to initialize the display, so neither the Fujitsu logo nor the GRUB menu is visible. (Legacy boot is used.)

Despite these issues, the early Intel driver should display something in fallback mode. Can this be done?

Please find the logs attached.
Comment 1 Chris Wilson 2018-09-20 10:00:44 UTC
A couple of angles to approach from:

1. We should try to capture the log for fbcon for eventual display even if no display is available at that time. However, fbcon/fbdev is really lower priority than seamless transition from boot to desktop.

2. Dramatically speed up DP-MST discovery.
Comment 2 Paul Menzel 2019-05-09 13:01:09 UTC
Created attachment 144206 [details]
Linux 5.1 messages (dmesg)

This still happens with Linux 5.1.

Display blank during firmware until GDM. `systemctl restart gdm` does *not* help. Plugging the cable from DP1 to DP2 and `systemctl restart gdm` activates monitor and GDM login screen is visible.

Can you see anything in the debug logs?
Comment 3 Ville Syrjala 2019-05-09 15:25:21 UTC
The first modeset happens at ~18 seconds. i915 probe started at ~17 seconds. So doens't look like probe being slow is the issue here.

I suspect the problem is these guys:
[   18.297317] [drm:drm_dp_dpcd_write_payload.isra.11 [drm_kms_helper]] status not set after read payload table status 0

So the display itself is maybe in some wonky state after the BIOS manhandled it. After the replug (at ~67 seconds) the display responds correctly to our gentle prodding and that error is no longer visible.

I think this may be due to the BIOS doing something odd, or it may have something to do with the fact that we don't have readout code for MST so we may not be shutting things down properly when taking over.
Comment 4 Martin Peres 2019-11-29 17:52:24 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/intel/issues/159.

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.