Bug 107980

Summary: (Tiled) MST display Dell UP3214Q only initialized very late
Product: DRI Reporter: Paul Menzel <pmenzel+bugs.freedesktop.org>
Component: DRM/IntelAssignee: Intel GFX Bugs mailing list <intel-gfx-bugs>
Status: RESOLVED MOVED QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: enhancement    
Priority: medium CC: intel-gfx-bugs, pmenzel+bugs.freedesktop.org
Version: DRI git   
Hardware: Other   
OS: All   
Whiteboard: Triaged, ReadyForDev
i915 platform: SKL i915 features: display/DP MST
Attachments:
Description Flags
Linux 4.19-rc4+ (drm-tip) messages
none
Linux 5.1 messages (dmesg) none

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.