System Environment ================= Board : APL RVP2 QXB9 DDR3 CPU : BROXTON-P A0 QDF: QXB9 Bios : APLK_IFWI_X64_R_2016_02_4_00_SPI_RVP2_119 KSC : APL_KSC_v01_04.10_21_2015 Bug detailed description =================== If boot up APL with HDMI and DP cable not connected to monitor, the monitor does not display after connect the DP/HDMI cable.moreover While doing Cold plug, Insert HDMI and Boot the target – We are seeing Quarter display + Dint see Mouse and Keyboard working Properly – If we move the mouse, I see Flickering on the edp screen Expected Result ============= While connect HDMI or DP it should give display without any issue Actual Result =========== If boot up APL with HDMI and DP cable not connected to monitor, the monitor does not display after connect the DP/HDMI cable and at cold plug seeing Quarter display + Dint see Mouse and Keyboard working Properly
Please provide a dmesg log booting with drm.debug=14.
Please provide a drm.debug=14 dmesg log both booting with display connected (resulting in correct modeset) and booting without the display being connected.
Created attachment 121638 [details] With_HDMI/DP DMESG LOGS
Created attachment 121639 [details] without_HDMI_DP Hi , FInd both attachments with and without HDMI / DP connected with modeset=drm.debug=0x14 thanks Qaiser
(In reply to Mohammad Qaiser Siddiqui from comment #4) > Created attachment 121639 [details] > without_HDMI_DP > > Hi , FInd both attachments with and without HDMI / DP connected with > modeset=drm.debug=0x14 > > thanks > Qaiser Thanks. "With_HDMI/DP DMESG LOGS" is missing the beginning part about booting, which is the interesting part. Could you provide one with that included?
Created attachment 121643 [details] logs with HDMI / DP connected Hi , please find attach logs with HDMI /DP connected .
(In reply to Mohammad Qaiser Siddiqui from comment #6) > Created attachment 121643 [details] > logs with HDMI / DP connected > > Hi , please find attach logs with HDMI /DP connected . This is still missing the beginning, the first line in your log is ~10 minutes after boot: Feb 10 12:00:40 apl kernel: [ 692.450762] [drm:drm_atomic_state_init] Allocated atomic state ffff88007762dc00 Please capture the log by running 'dmesg' right after booting.
Created attachment 121668 [details] logs with connected HDMI / DP Hi , please find attach logs with drm.debug=14 moreover i have set max size of buffer level . Thanks Mohammad Qaiser
(In reply to Mohammad Qaiser Siddiqui from comment #8) > Created attachment 121668 [details] > logs with connected HDMI / DP > > Hi , please find attach logs with drm.debug=14 > moreover i have set max size of buffer level . Hm, I can only see the eDP output being active. Did I understand correctly that you have an active output if the monitor is plugged when you boot (even if you see flicker and only quarter of the screen)? Is it an HDMI or DP monitor that you have connected? Can you also provide the output of xrandr?
Created attachment 121677 [details] syslog and xrandr log for triple display pipe Hi Deak, We do see some sort of flickering in both HDMI and DP. Presently i have connected the HDMI and DP both in the APL motherboard. Port details are below HDMI - DDIO DP/HDMI 2.0 combo. DP - DDIO DP/HDMI combo. eDP - Default eDP port. Attached logs are, 1. syslog_with_triple_pipe_2_11_2016.log 2. xrandr_with_triple_pipe_2_11_2016.log Zipping the logs as they are big in size. Vijay
Hi team Can you please update Bug status for flickering issue with HDMI and DP . Still issue is there logs with HDMI and DP connected are provided by Vijay on last comment . Thanks Mohammad Qaiser
There are several things that could be at play here. First off, since we're looking at BXT-P A0, then DDI1 (Port C) cannot be used. If you're plugging monitors in on that port, then the lack of a routed HPD signal to that port will prevent hot plugs from working correctly. Secondly, until LSPCON gets into the kernel DDI0 (Port B) is also not going to behave reliably. I strongly recommend moving to B0 silicon for all external monitor testing, and even then I wouldn't get super excited about it until the LSPCON patches land. One other curious thing I saw: Feb 11 08:36:51 apl kernel: [53111.664336] [drm:intel_dp_compute_config] DP link computation with max lane count 2 max bw 270000 pixel clock 138780KHz Feb 11 08:36:51 apl kernel: [53111.664359] [drm:intel_dp_compute_config] DP link bw 0a rate select 00 lane count 2 clock 270000 bpp 24 Feb 11 08:36:51 apl kernel: [53111.664366] [drm:intel_dp_compute_config] DP link bw required 333072 available 432000 Does the APL panel only support two lanes of DP? I'm also seeing that we're only training at HBR1. Is CDCLK being set in the BIOS, and if so to what value? On SKL+ the CDCLK setting has a direct bearing on how fast the ports can run. In any event, please retest ensuring that CDCLK is set to maximum and then let's see if at least eDP works without flickering in this scenario.
Could you try the following two patches to see if the flickering goes away?: https://lists.freedesktop.org/archives/intel-gfx/2016-April/091296.html https://lists.freedesktop.org/archives/intel-gfx/2016-April/091309.html
Hi Qaiser, We confirmed the patches fix the flickering. As your bug is about several issues (hotplug + "Quarter display" + flickering), I propose you check them with the patches and report them in separated bugs if you still reproduce them. Also review Jim Bride's comment which gives useful information. Thanks.
Increasing priority due to current platform experience impact
(In reply to cprigent from comment #14) > Hi Qaiser, > We confirmed the patches fix the flickering. The patches to fix the flickering have been merged. > As your bug is about several issues (hotplug + "Quarter display" + > flickering), I propose you check them with the patches and report them in > separated bugs if you still reproduce them. Agreed. This bug is too conflated. I'm closing this one because we've fixed the flickering issue. Please test drm-intel-nightly, and file new bugs, one per each issue, if the other issues are still present. Thanks.
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.