Summary: | [BSW] replug HDMI/DP cable does not light up screen sometimes | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | DRI | Reporter: | Jeff Zheng <jeff.zheng> | ||||||||||||
Component: | DRM/Intel | Assignee: | Ville Syrjala <ville.syrjala> | ||||||||||||
Status: | CLOSED WORKSFORME | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||||||||
Severity: | major | ||||||||||||||
Priority: | high | CC: | christophe.prigent, intel-gfx-bugs, mika.kahola, vivekanandhanx.jayagurunathan | ||||||||||||
Version: | unspecified | ||||||||||||||
Hardware: | Other | ||||||||||||||
OS: | All | ||||||||||||||
See Also: | https://bugs.freedesktop.org/show_bug.cgi?id=89008 | ||||||||||||||
Whiteboard: | |||||||||||||||
i915 platform: | BSW/CHT | i915 features: | display/DP, display/HDMI, display/Other | ||||||||||||
Attachments: |
|
Description
Jeff Zheng
2015-03-06 09:35:45 UTC
exists on drm-intel-testing-2015-03-27 with DP monitor ASUS PA238Q exists on drm-intel-testing-2015-04-10 with DP monitor ASUS PA238Q I can very easily reproduce this issue with Dell U2311Hb DP monitor on drm-intel-testing-2015-04-23: 1. Boot with DP connected 2. xinit 3. plug out and then plugin DP cable. Exists on drm-intel-testing-2015-05-08 This seems to be a duplicate to #89668. Are you able to replicate this problem if you upgrade VBIOS to V69 as in bug #89668? This issue still exists with V69 BIOS This issue is reproducing with below stack kernel-Eywa-4.1.0-rc3 Bios ver: 68.1 Ksc: 1.08 Dp monitor: Dell U2410 HDMI monitor: Acer S220HQL Created attachment 115898 [details] [review] HPD storm detection and limitation Please try out this HPD detection and storm prevention patch. I don't have any means to replicate this issue and test if this patch would work or not so please give it a go and report back with dmesg log. Created attachment 116038 [details]
dmesg log with Mika's patch
Exists on drm-intel-testing-2015-05-22.
After apply MiKa's patch to f0b5e3c6b1ecc9b297c3b2ee5da9ae4fe8d5c795, this issue still exists.
I think this is just another case of hotplug not working while the pipe-a power well is down (which happens when all displays get turned off). See bug 89008 for some extra details. We could try to keep the power wells on by using the module option 'i915.disable_power_well=0' and check the outcome. Check status from NEEDINFO to New. conselvan2, what information did you want when you changed status to NEEDINFO, or just a typo? (In reply to Jeff Zheng from comment #12) > Check status from NEEDINFO to New. > > conselvan2, what information did you want when you changed status to > NEEDINFO, or just a typo? See comment 11. Please test with i915.disable_power_well=0 in the kernel command line. Created attachment 116342 [details]
dmesg with i915.disable_power_well=0
This dmesg is generated with:
1. Boot with both eDP and DP connected
2. xinit &
3. unplug DP
4. Plug in DP cable, DP monitor is black screen.
(In reply to Jeff Zheng from comment #14) > Created attachment 116342 [details] > dmesg with i915.disable_power_well=0 > > This dmesg is generated with: > 1. Boot with both eDP and DP connected > 2. xinit & > 3. unplug DP > 4. Plug in DP cable, DP monitor is black screen. You have no userspace to react to the HPDs so the link remains up even if the cable gets disconnected. I suppose there are two options a) the sink went into D3, although IIRC this would be against the spec (sink is required to enter D0 on full HPD). b) the sink just doesn't feel that the link is up and running. Can't recall if there's anything in the spec about what should happen on the sink end when the cable is disconnected. So while the test scenario is a bit bogus it would be interesting to see what the sink is thinking in this case. I'll attach a debug patch for that... Created attachment 117765 [details] [review] [PATCH] debug sink state on long hpd Would be interesting to see what this patch says when the cable is reconnected. Bug scrub Rami, Could you check with last setup? Thanks For this scenario: 1. Boot with both eDP and DP connected 2. startx 3. unplug DP and then plugin DP Result: it work For this scenario: 1. Boot with only eDP 2. startx 3. plugin DP Result: DP monitor is black screen Hi Ville, The patch is already applied. It is still reproduced see Rami's steps. (In reply to Rami from comment #19) > For this scenario: > 1. Boot with both eDP and DP connected > 2. startx > 3. unplug DP and then plugin DP > Result: it work > > For this scenario: > 1. Boot with only eDP > 2. startx > 3. plugin DP > Result: DP monitor is black screen Do you have an xrandr client running (eg. some desktop environment) that would enable the new monitor (and potentially resize the screen)? If not, then it's not a bug, just the way things are designed to work. In fact it is not reproduced with kernel 4.4-rc2 and Ubuntu 15. Platform: Braswell M CPU : Intel(R) Celeron N3060 1.60GHz @ 1.6 GHz (family: 6, model: 76 stepping: 4) SoC : BSW D0 QDF : K6XC CRB : BRASWELL RVP Fab2 Mandatory Reworks : All Feature Reworks: F28, F32, F33, F35, F37 Optional reworks : O-01a; O-02, O-03 Software BIOS : BRAS.X64.B088.R00.1510270350 TXE FW : 2.0.0.2093 Ksc : 1.08 Linux : Ubuntu 15.04 64 bits BIOS : SKLSE2R1.R00.B104.B01.1511110114 ME FW : 11.0.0.1191 Ksc (EC FW): 1.20 Kernel 4.4.0-rc2 nighlty 9e096bc from git://anongit.freedesktop.org/drm-intel commit 9e096bc5a20d1d8122740136ab6c584afd4cb913 Author: Imre Deak <imre.deak@intel.com> Date: Mon Nov 23 17:11:06 2015 +0200 drm-intel-nightly: 2015y-11m-23d-15h-10m-47s UTC integration manifest Mesa 11.0.5 from http://cgit.freedesktop.org/mesa/mesa/ xf86-video-intel - 2.99.917 from http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/ Libdrm - 2.4.65 from http://cgit.freedesktop.org/mesa/drm/ Libva - 1.6.1 from http://cgit.freedesktop.org/libva/ vaapi intel-driver - 1.6.1 from http://cgit.freedesktop.org/vaapi/intel-driver Cairo - 1.14.2 from http://cgit.freedesktop.org/cairo Xorg Xserver - 1.17.2 from http://cgit.freedesktop.org/xorg/xserver Monitors: Asus PB238Q (DP) and LG 25UM55 (HDMI) Closed |
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.