Bug 44309 - [IVB eDP] 3 pipe doesn't work with eDP monitor
[IVB eDP] 3 pipe doesn't work with eDP monitor
Status: VERIFIED FIXED
Product: DRI
Classification: Unclassified
Component: DRM/Intel
unspecified
Other All
: high major
Assigned To: Jesse Barnes
:
Depends on: 44305
Blocks: 44622
  Show dependency treegraph
 
Reported: 2011-12-29 23:29 UTC by Yi Sun
Modified: 2012-11-06 09:36 UTC (History)
7 users (show)

See Also:


Attachments
Make sure CPU eDP doesn't try to steal a PCH DPLL (1.11 KB, patch)
2012-04-05 16:49 UTC, Jesse Barnes
no flags Details | Splinter Review
IvyBridge 3 pipe dmesg(x-ivb12) (122.92 KB, text/plain)
2012-10-18 08:07 UTC, shui yangwei
no flags Details
eDP+HDMI+DP (116.60 KB, text/plain)
2012-11-01 08:18 UTC, shui yangwei
no flags Details
eDP+VGA+DP (116.31 KB, text/plain)
2012-11-01 08:19 UTC, shui yangwei
no flags Details
eDP+HDMI+VGA (101.32 KB, text/plain)
2012-11-01 08:23 UTC, shui yangwei
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yi Sun 2011-12-29 23:29:23 UTC
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.
Comment 1 Yi Sun 2011-12-30 17:24:20 UTC
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.
Comment 2 Jesse Barnes 2012-04-05 16:49:55 UTC
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.
Comment 3 Yi Sun 2012-04-05 23:40:05 UTC
(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.
Comment 4 Chris Wilson 2012-04-19 15:05:33 UTC
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)
Comment 5 Yi Sun 2012-04-25 20:33:30 UTC
(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.
Comment 6 Daniel Vetter 2012-04-26 01:05:07 UTC
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
Comment 7 Guang Yang 2012-04-27 00:19:02 UTC
(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.
Comment 8 Florian Mickler 2012-07-01 03:40:19 UTC
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
Comment 9 Florian Mickler 2012-07-03 10:36:48 UTC
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
Comment 10 shui yangwei 2012-10-18 08:07:24 UTC
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.
Comment 11 Chris Wilson 2012-10-18 08:13:21 UTC
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.
Comment 12 Yi Sun 2012-10-19 07:22:01 UTC
(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?
Comment 13 Gordon Jin 2012-10-19 08:11:51 UTC
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.
Comment 14 Chris Wilson 2012-10-19 08:30:57 UTC
My apologies, a CPU eDP doesn't require a PLL, so yes, CPU eDP + any 2 other displays should work.
Comment 15 Daniel Vetter 2012-10-31 12:33:13 UTC
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 ...
Comment 16 shui yangwei 2012-11-01 08:15:15 UTC
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.
Comment 17 shui yangwei 2012-11-01 08:18:53 UTC
Created attachment 69382 [details]
eDP+HDMI+DP
Comment 18 shui yangwei 2012-11-01 08:19:26 UTC
Created attachment 69383 [details]
eDP+VGA+DP
Comment 19 shui yangwei 2012-11-01 08:23:15 UTC
Created attachment 69384 [details]
eDP+HDMI+VGA
Comment 20 Daniel Vetter 2012-11-01 09:03:04 UTC
>       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
Comment 21 Yi Sun 2012-11-06 07:17:21 UTC
(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.
Comment 22 Yi Sun 2012-11-06 07:18:40 UTC
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>
Comment 23 Daniel Vetter 2012-11-06 09:30:33 UTC
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.