Bug 107980 - (Tiled) MST display Dell UP3214Q only initialized very late
Summary: (Tiled) MST display Dell UP3214Q only initialized very late
Status: NEW
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
URL:
Whiteboard: Triaged, ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2018-09-18 15:39 UTC by Paul Menzel
Modified: 2019-05-09 15:25 UTC (History)
2 users (show)

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


Attachments
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

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


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.