System Environment: -------------------------- Arch: x86_64 Platform: IvyBridge Libdrm: Libdrm: (master)2.4.29-3-gef20301a11afae50bfe127002913dbd0b81ddccc Kernel: (drm-intel-next)097354eb14fa94d31a09c64d640643f58e4a5a9a Bug detailed description: ------------------------- As my understanding, the IvyBridge platform should support "eDP + 2 any displays" combinations. But till now, none of the "eDP + 2 any displays" 3 pipe modes work on IvyBridge.
This issue seems to be partly influenced by bug 44305. If we boot the machine with all 3 displays(eDP + 2HDMI), it would work. But the other combination such as eDP+DP+HDMI or eDP+VGA+any still doesn't. When connect to three monitors in above case, we get the CTRCs information with "testdisplay -i" is as following: CRTCs: id fb pos size 3 29 (0,0) (0x0) 1366x768 60 1366 1398 1422 1426 768 771 775 806 0x9 0x48 69000 4 29 (0,0) (0x0) 1024x768 75 1024 1040 1136 1312 768 769 772 800 0x5 0x40 78800 5 0 (0,0) (0x0) 0 0 0 0 0 0 0 0 0 0x0 0x0 0 And the error information "*ERROR* failed to set mode on [CRTC:5]" while plug in the 3th monitor.
Created attachment 59552 [details] [review] Make sure CPU eDP doesn't try to steal a PCH DPLL Can you verify this works for you? It allows me to set 3 different modes on eDP, DP, and VGA.
(In reply to comment #2) > Created attachment 59552 [details] [review] [review] > Make sure CPU eDP doesn't try to steal a PCH DPLL > > Can you verify this works for you? It allows me to set 3 different modes on > eDP, DP, and VGA. Cool, I tried all the 3 pipes combinations we have about eDP, eDP +VGA+HDMI, eDP+VGA+DP and eDP+HDMI+DP. All of them work well.
drm-intel-next-queued: commit b98e5240b362e702355ffedba05aeb589dfbcbe2 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Fri Apr 13 18:24:38 2012 +0100 drm/i915: manage PCH PLLs separately from pipes PCH PLLs aren't required for outputs on the CPU, so we shouldn't just treat them as part of the pipe. So split the code out and manage PCH PLLs separately, allocating them when needed or trying to re-use existing PCH PLL setups when the timings match. v2: add num_pch_pll field to dev_priv (Daniel) don't NULL the pch_pll pointer in disable or DPMS will fail (Jesse) put register offsets in pll struct (Chris) v3: Decouple enable/disable of PLLs from get/put. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44309 Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> (up to v2) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v3)
(In reply to comment #4) > drm-intel-next-queued: > > commit b98e5240b362e702355ffedba05aeb589dfbcbe2 > Author: Jesse Barnes <jbarnes@virtuousgeek.org> > Date: Fri Apr 13 18:24:38 2012 +0100 > > drm/i915: manage PCH PLLs separately from pipes > > PCH PLLs aren't required for outputs on the CPU, so we shouldn't just > treat them as part of the pipe. > > So split the code out and manage PCH PLLs separately, allocating them > when needed or trying to re-use existing PCH PLL setups when the timings > match. > > v2: add num_pch_pll field to dev_priv (Daniel) > don't NULL the pch_pll pointer in disable or DPMS will fail (Jesse) > put register offsets in pll struct (Chris) > > v3: Decouple enable/disable of PLLs from get/put. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44309 > Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> (up to v2) > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v3) Since this patch caused the regression and was reverted from the -next-queued, open this bug until the updated patch is pushed. The issue still happens on -testing branch.
New patch merged into -queued as commit 13543c06febe0b2bcce64e611db74369e986977f Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Fri Apr 20 17:11:53 2012 +0100 drm/i915: manage PCH PLLs separately from pipes
(In reply to comment #6) > New patch merged into -queued as > commit 13543c06febe0b2bcce64e611db74369e986977f > Author: Jesse Barnes <jbarnes@virtuousgeek.org> > Date: Fri Apr 20 17:11:53 2012 +0100 > drm/i915: manage PCH PLLs separately from pipes Hi daniel, I try the kernel including the commit:13543c06febe0b2bcce64e611db74369e986977f which commit is: Kernel: (drm-intel-next-queued)ff16d20bb71556ec110b4d51efdb4f678619b256 I tried some 3 pipes combinations scch as :eDP +VGA+HDMI, eDP+VGA+DP ,eDP+HDMI+DP and eDP+2 HDMI,only eDP+2 HDMI can work well.
A patch referencing this bug report has been merged in Linux v3.5-rc1: commit ee7b9f93fd96a72e5d09e2b44024c11880873c6b Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Fri Apr 20 17:11:53 2012 +0100 drm/i915: manage PCH PLLs separately from pipes
A patch referencing a commit referencing this bug report has been merged in Linux v3.5-rc1: commit 98b6bd998ae057611d2bc040ace1fc847f575b84 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun May 20 20:00:25 2012 +0200 drm/i915: IBX has a fixed pch pll to pch pipe mapping
Created attachment 68750 [details] IvyBridge 3 pipe dmesg(x-ivb12) (In reply to comment #7) > (In reply to comment #6) > > New patch merged into -queued as > > commit 13543c06febe0b2bcce64e611db74369e986977f > > Author: Jesse Barnes <jbarnes@virtuousgeek.org> > > Date: Fri Apr 20 17:11:53 2012 +0100 > > drm/i915: manage PCH PLLs separately from pipes > > Hi daniel, I try the kernel including the > commit:13543c06febe0b2bcce64e611db74369e986977f > which commit is: > Kernel: (drm-intel-next-queued)ff16d20bb71556ec110b4d51efdb4f678619b256 > I tried some 3 pipes combinations scch as :eDP +VGA+HDMI, > eDP+VGA+DP ,eDP+HDMI+DP and eDP+2 HDMI,only eDP+2 HDMI can work well. I retry this issue on kernel you mentioned. I think you have misread the sentence forward:"eDP +VGA+HDMI,eDP+VGA+DP ,eDP+HDMI+DP and eDP+2 HDMI,only eDP+2 HDMI can work well." It means all of the combination, only eDP+2 HDMI can work well, all the other failed. I retest it like below: System Environment: -------------------------- Arch: x86_64 Platform: IvyBridge Kernel: (drm-intel-next-queued)ee7b9f93fd96a72e5d09e2b44024c11880873c6b Some additional commit info: Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Fri Apr 20 17:11:53 2012 +0100 Bug detailed description: ------------------------- 3 pipe, DP can't light up. dmesg is attached.
Ok, with those combinations we expect eDP VGA+HDMI: fail eDP+VGA+DP: fail eDP+HDMI+DP: may work, most likely fail eDP+2 HDMI: work as the encoders must be shareable on the same CRTC and running at exactly the same mode.
(In reply to comment #11) > Ok, with those combinations we expect eDP VGA+HDMI: fail eDP+VGA+DP: fail > eDP+HDMI+DP: may work, most likely fail eDP+2 HDMI: work as the encoders > must be shareable on the same CRTC and running at exactly the same mode. Hi Chris, But the combinations eDP+VGA+HDMI, eDP+VGA+DP and eDP+DP+HDMI do work with Jesse's patch(mentioned in comment #2). I just re-tested that patch. But the commit 13543c06febe0b2bcce64e611db74369e986977f which Daniel merged the patch to the -next-queued doesn't work. I reset the -next-queued to the following commit, then applied the patch. All the combinations eDP+2 any (3 combinations in all) work well. But the commit which Daniel merged doesn't work. commit 0136db586c028f71e7cc21cc183064ff0d5919c8 Author: Ben Widawsky <ben@bwidawsk.net> Date: Tue Apr 10 21:17:01 2012 -0700 drm/i915: rc6 in sysfs Or you meant that those VGA related combinations can be enabled, but we don't do that for some reason?
I've been always expecting "eDP + 2 any" working on IVB, just like http://intellinuxgraphics.org/2012.02.html says: "◦Driver will support one eDP (embedded display port) display and two any displays. " reopening.
My apologies, a CPU eDP doesn't require a PLL, so yes, CPU eDP + any 2 other displays should work.
Please retest on latest -queued. If it's still broken, please disable all non-eDP outputs, move the eDP output to crtc 2 (e.g. xrandr --output eDP1 --auto --crtc 2 in X) and then enable the outputs again. If that works (with eDP on crtc 2) I have some patches currently under review which should help ...
Kernel: (drm-intel-next-queued)8a4b1d103e7198766b2e0734b74a9cb63f58c4ce description: We do this test on machine(x-ivb12) before, but now it is lent to others. Now we test on another one(x-ivb13). The details are as following: boot system with eDP only, and then hot-plug in two pipe (HDMI/VGA/DP), all the three pipes work well. But if we boot system with 3 pipes, all the combinations didn't work well: eDP + VGA + HDMI : eDP BIOS can't light up from booting. eDP + VGA + DP : DP and eDP can't light up, from BIOS. eDP + HDMI + DP: DP can't light up. Dmesg attached with 3pipes combination as their names.
Created attachment 69382 [details] eDP+HDMI+DP
Created attachment 69383 [details] eDP+VGA+DP
Created attachment 69384 [details] eDP+HDMI+VGA
> eDP + VGA + HDMI : eDP BIOS can't light up from booting. > eDP + VGA + DP : DP and eDP can't light up, from BIOS. These two here are expected to fail: When enabling both fdi link B (2nd pipe) and fdi link C (3rd pipe) we only have half as much bandwidth available as when just using fdi link B. The mode (2560x1600) on DP is simply too big for the 3rd pipe. It depends upon the exact mode, but the limit is usually around 1920x1080. Like I've said, you can work around this by fixing the low-res mode of eDP to the 3rd pipe (--crtc 2), please test that. > eDP + HDMI + DP: DP can't light up. Hm, this one here should work I think. Can you please test the for-QA branch from my private repo? It contains fixes for fdi B/C links. http://cgit.freedesktop.org/~danvet/drm/log/?h=for-QA
(In reply to comment #20) > > eDP + VGA + HDMI : eDP BIOS can't light up from booting. > > eDP + VGA + DP : DP and eDP can't light up, from BIOS. > > These two here are expected to fail: When enabling both fdi link B (2nd > pipe) and fdi link C (3rd pipe) we only have half as much bandwidth > available as when just using fdi link B. The mode (2560x1600) on DP is > simply too big for the 3rd pipe. > > It depends upon the exact mode, but the limit is usually around 1920x1080. > > Like I've said, you can work around this by fixing the low-res mode of eDP > to the 3rd pipe (--crtc 2), please test that. > > > eDP + HDMI + DP: DP can't light up. > > Hm, this one here should work I think. Can you please test the for-QA branch > from my private repo? It contains fixes for fdi B/C links. > > http://cgit.freedesktop.org/~danvet/drm/log/?h=for-QA Hi Daniel, As you said, we re-tested this issue with two same external displays and max mode 1920x1080. The issue disappeared. All the eDP + 2any combinations work well, including eDP+VGA+HDMI, eDP+VGA+DP and eDP+HDMI+DP. So, I think we can close this bug. As to the fdi B/C links issue, we are blocked to test it by a black screen issue. We'll file a new bug to track that.
The version of kernel we used is: commit a7902ac548190654c58e2491ff8646701772caa8 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Mon Oct 15 15:51:42 2012 -0300 drm/i915: set the correct function pointers for Haswell DP This is the final remaining piece of Haswell DP enablement. After this patch, just calling intel_dp_init on any port will make DP work. We still do not do this because we're currently initializing HDMI on all the ports, so if we replace intel_hdmi_init with intel_dp_init, we will break HDMI, and we can't call both because they share the same registers. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ok, I think this one here is fixed, it's a simple hw restriction - 3 pipe is not possible in the original configuration. For the black screen issue, yes, please file a new bug.
Closing old verified.
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.