Bug 49402

Summary: [snb dp dongle] DP-to-dual-HDMI (link_train issue?)
Product: DRI Reporter: Wolf <whtolkien>
Component: DRM/IntelAssignee: Jani Nikula <jani.nikula>
Status: CLOSED FIXED QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: normal    
Priority: medium CC: ben, bugs, chris, daniel, freedesktop.org, jani.nikula, jbarnes, stgraber
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
dmesg with Dell U2711 native Displayport monitor - works!
none
dmesg with Zotac 'displayport-to-dual-hdmi' adapter - screens stay blank.
none
dmesg with Siig 'displayport-to-single-hdmi' adapter - works.
none
xrandr --verbose for broken 'Displayport-to-dual-hdmi' setup
none
xrandr --verbose for working native Displayport monitor.
none
Screenshot of Displaysettings in Ubuntu - looks good, but Displayport screen stays blank!
none
Possible fix
none
drm/i915: don't write training pattern set if it doesn't change
none
drm/i915/dp: do not write DP_TRAINING_PATTERN_SET all the time none

Description Wolf 2012-05-02 13:26:32 UTC
Created attachment 60931 [details]
dmesg with Dell U2711 native Displayport monitor - works!

Hello,

I have tried this on a Lenovo T410 with Intel HD2000 graphics and on a Lenovo T420s with Intel HD3000 graphics: both were running a fresh installation of Ubuntu 12.04 and the results were identical:

I have three different Displayport devices to test this with:

a) A Dell U2711 monitor with a 'true' Displayport input. Works!
b) A Siig 'Displayport-to-HDMI' adapter connected to a Dell U2312 monitor. Works!
c) A Zotac 'Displayport-to-dual-HDMI' adapter connected to two Dell U2312 monitors. This does not work - the screens stay blank!

FYI, the Zotac adapter pretty much does 'cinerama' in hardware. It takes the two attached HD monitors and presents a single 3840x1080 screen on the Displayport. It works great under Windows (and needs no special driver), but not with Linux. 

I am attaching dmesg logs for all three scenarios above from a powerup with drm.debug=0xe kernel parameter. 

I can't claim that I understand everything that's going on, but by comparing the logs, it seems to me that the problem is with the link training of the Zotac adapter. 

Any help would be greatly appreciated - if it's required, I'm more than happy to send the Zotac adapter to a developer for debugging. 

Thanks a lot!

Wolf
Comment 1 Wolf 2012-05-02 13:28:42 UTC
Created attachment 60932 [details]
dmesg with Zotac 'displayport-to-dual-hdmi' adapter - screens stay blank.
Comment 2 Wolf 2012-05-02 13:29:53 UTC
Created attachment 60933 [details]
dmesg with Siig 'displayport-to-single-hdmi' adapter - works.
Comment 3 Chris Wilson 2012-05-02 13:34:04 UTC
This is a might strange modeline:

[   10.542088] [drm:drm_mode_debug_printmodeline], Modeline 44:"3840x1080" 60 277540 3840 3928 3972 4120 1080 1084 1089 1125 0x48 0x5

Can you please attach a xrandr --verbose with the broken/working config?

Also some more diagnostics are available from http://cgit.freedesktop.org/~danvet/drm-intel #drm-intel-next-queued
Comment 4 Wolf 2012-05-02 13:49:15 UTC
The unusual 3840x1080 resolution is to be expected. 

Look for 'link_train' in the dmesg log with the Zotac adapter. Looks odd to me. 

I'm providing the xrandr output as requested - also a screenshot of the Ubuntu Displaysettings with the Zotac adapter. It looks exactly as it should - except that the screen stays blank.
Comment 5 Wolf 2012-05-02 13:49:50 UTC
Created attachment 60937 [details]
xrandr --verbose for broken 'Displayport-to-dual-hdmi' setup
Comment 6 Wolf 2012-05-02 13:50:17 UTC
Created attachment 60938 [details]
xrandr --verbose for working native Displayport monitor.
Comment 7 Wolf 2012-05-02 13:51:10 UTC
Created attachment 60939 [details]
Screenshot of Displaysettings in Ubuntu - looks good, but Displayport screen stays blank!
Comment 8 Jesse Barnes 2012-05-02 14:36:07 UTC
So things work in Windows on that same machine?  Our HDMI has clock limits so I didn't think it would support modes that high, but maybe it's using DP to signal to the dongle, then converts internally to HDMI?

Ok yeah, the xrandr confirms that.  So we ought to be able to drive 3840x1080 on DP just fine...
Comment 9 Wolf 2012-05-02 14:47:29 UTC
Yes, it works with Windows 7 on that very same machine. And yes, it is using DP to signal between the computer and the dongle. The dongle then converts the signal into two regular 1920x1080 HDMI signals while presenting a single 3840x1080 screen on the DP side. 

Quite ingenious actually - as I said, it's Xinerama done in hardware!
Comment 10 Wolf 2012-05-02 14:51:37 UTC
This is what strikes me as strange:

dmesg with the working 'native' DP monitor:


[    5.127097] [drm:intel_dp_start_link_train], training pattern 1 signal levels 00000000
[    5.127810] [drm:intel_dp_start_link_train], clock recovery OK


dmesg with the broken 'dp-to-dual-hdmi' adapter:


[    4.900133] [drm:intel_dp_start_link_train], training pattern 1 signal levels 00000000
[    4.900948] [drm:intel_dp_start_link_train], training pattern 1 signal levels 00000000
[    4.901763] [drm:intel_dp_start_link_train], training pattern 1 signal levels 00000000
[    4.902578] [drm:intel_dp_start_link_train], training pattern 1 signal levels 00000000
[    4.903392] [drm:intel_dp_start_link_train], training pattern 1 signal levels 00000000
[    4.904207] [drm:intel_dp_start_link_train], training pattern 1 signal levels 00000000
[    4.905021] [drm:intel_dp_start_link_train], too many voltage retries, give up
Comment 11 Stéphane Graber 2012-09-05 20:07:18 UTC
Is there any progress being made on this or anything I can provide/test to help?

I just received a similar adapter today and get the same behaviour. xrandr reports the 1920x1080 or 3840x1080 depending on if I have just one or two monitors plugged in the adapter, but both remain off.

Connecting a single adapter using a standard DP => HDMI adapter works fine.

I'm testing on Ubuntu 12.10 with xserver-xorg-video-intel 2:2.20.3-0ubuntu1 and a 3.5.0-13-generic kernel. That's on a Lenovo x230 with an HD4000.
Comment 12 Jani Nikula 2012-10-24 09:47:23 UTC
(In reply to comment #11)
> Is there any progress being made on this or anything I can provide/test to
> help?

I have a ZOTAC mini-DisplayPort to Dual HDMI Adaptor ZT-MDP2HD, and I can reproduce the problem. Taking bug.
Comment 13 Chris Wilson 2012-12-12 16:21:56 UTC
New kernel (3.7), time to test. Thanks!
Comment 14 Wolf 2012-12-13 03:34:26 UTC
Unfortunately still no success for me... Same as before, screens stay blank.
Comment 15 Wolf 2013-02-06 18:46:32 UTC
Hello Jani,

did you have a chance to look at this already? Unfortunately it seems there hasn't been any progress so far.
Comment 16 Michael 2013-04-04 20:48:46 UTC
Same for me. Two LG IPS235 panels (1920x1080) connected via HDMI to the Zotac ZT-MDP2HD.
Hardware is a Lenovo X1 carbon with:
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)
(via Intel(R) Core(TM) i5-3427U CPU @ 1.80GHz)

xrandr --verbose is here: https://nblr.de/xrandr-verbose-zotac-x1

Kernel is Ubuntu/Mint 3.5.0-26-generic

Works like a charm and out of the box with current intel hd4000 video drivers in Windows 7.
Comment 17 Ville Syrjala 2013-04-16 09:50:53 UTC
I tried a few random things for this on IVB.

- tried to send the training pattern and training lane set with one aux write instead of two.
- tried to disable enhanced framing
- tried to force some voltage swing/pre-emphasis values
- tried with 6 bpc so that we'd get 1.62 links speed instead of 2.7
- tried to send post cursor2 traning values in case that would trick the sink into cooperation

Unfortunately none of that helped.

The BIOS produces a picture with the dongle, so I tried to compare some of the register values. The main differences I saw were that the BIOS uses auto training for FDI, some of the M/N values were different, and of course the BIOS also has panel fitter active since it's using a 720x400 resolution.
Comment 18 Jesse Barnes 2013-04-16 16:14:58 UTC
On Tue, 16 Apr 2013 09:50:53 +0000
bugzilla-daemon@freedesktop.org wrote:

> https://bugs.freedesktop.org/show_bug.cgi?id=49402
> 
> --- Comment #17 from Ville Syrjala <ville.syrjala@linux.intel.com> ---
> I tried a few random things for this on IVB.
> 
> - tried to send the training pattern and training lane set with one aux write
> instead of two.
> - tried to disable enhanced framing
> - tried to force some voltage swing/pre-emphasis values
> - tried with 6 bpc so that we'd get 1.62 links speed instead of 2.7
> - tried to send post cursor2 traning values in case that would trick the sink
> into cooperation
> 
> Unfortunately none of that helped.
> 
> The BIOS produces a picture with the dongle, so I tried to compare some of the
> register values. The main differences I saw were that the BIOS uses auto
> training for FDI, some of the M/N values were different, and of course the BIOS
> also has panel fitter active since it's using a 720x400 resolution.

The m/n values could definitely be a factor.  Maybe our DP values are
slightly off and causing some skew in the dongle?
Comment 19 Ville Syrjala 2013-04-22 13:17:32 UTC
(In reply to comment #18)
> On Tue, 16 Apr 2013 09:50:53 +0000
> bugzilla-daemon@freedesktop.org wrote:
> 
> > https://bugs.freedesktop.org/show_bug.cgi?id=49402
> > 
> > --- Comment #17 from Ville Syrjala <ville.syrjala@linux.intel.com> ---
> > I tried a few random things for this on IVB.
> > 
> > - tried to send the training pattern and training lane set with one aux write
> > instead of two.
> > - tried to disable enhanced framing
> > - tried to force some voltage swing/pre-emphasis values
> > - tried with 6 bpc so that we'd get 1.62 links speed instead of 2.7
> > - tried to send post cursor2 traning values in case that would trick the sink
> > into cooperation
> > 
> > Unfortunately none of that helped.
> > 
> > The BIOS produces a picture with the dongle, so I tried to compare some of the
> > register values. The main differences I saw were that the BIOS uses auto
> > training for FDI, some of the M/N values were different, and of course the BIOS
> > also has panel fitter active since it's using a 720x400 resolution.
> 
> The m/n values could definitely be a factor.  Maybe our DP values are
> slightly off and causing some skew in the dongle?

It seems you are right. I just tried to hardcode the M/N values to the ones used by the BIOS, and now I get a picture on the screen. I'll just list the values here and hope someone else will figure out what code changes are needed to produce the working values ;)

TU = 64 for both
data M/N:
 BIOS: 62ae4e / 800000
 i915: 65a360 / 83d600
link M/N:
 BIOS: 83931 / 80000
 i915: 43c24 / 41eb0

The DP link training still "fails" the same way. It tries CR five times w/ vswing=0 and pre-emphasis=0 before giving up, and then goes on to the EQ phase which succeeds immediately. But the CR failure doesn't seem to prevent it from working.
Comment 20 Ville Syrjala 2013-04-22 13:56:06 UTC
OK I lied. I did spend a few moments thinking about the issue a bit more.

The BIOS N values are power of two. So assuming that power of two values are somehow better, perhaps we can adjust the calculated M/N values a bit.
Something like this perhaps:

new_n = min(roundup_pow_of_two(n), 1 << 23);
new_m = m * new_n / n;
Comment 21 Ville Syrjala 2013-04-22 14:27:28 UTC
Created attachment 78330 [details] [review]
Possible fix

This patch makes my Zotac donle + Samsung telly work. I have no idea whether it breaks some other displays though.
Comment 22 Wolf 2013-04-26 02:28:51 UTC
Kudos for making it work with your hardware - I tried your patch with Linux 3.8.0-19-generic / Ubuntu 13.04, but unfortunately it doesn't work for me. I can verify that your patch produces the same M/N values as your BIOS, but unfortunately my screens (2x Dell U2312) stay blank. 

Did you change anything else by any chance?

How did you figure out what values your BIOS uses?

On the plus side - your patch does not seem to break support for my native Displayport monitor (Dell U2711) either. That one still works!
Comment 23 Wolf 2013-04-26 03:15:57 UTC
I tried to pry open the Zotac adapter. It's based on an IDT VMM1402 chip, if that's of any help...
Comment 24 Jani Nikula 2013-04-26 06:19:29 UTC
(In reply to comment #22)
> Kudos for making it work with your hardware - I tried your patch with Linux
> 3.8.0-19-generic / Ubuntu 13.04, but unfortunately it doesn't work for me. I
> can verify that your patch produces the same M/N values as your BIOS, but
> unfortunately my screens (2x Dell U2312) stay blank. 
> 
> Did you change anything else by any chance?

You could try the drm-intel-nightly branch from [1]. It contains Ville's patch, and many many other changes.

> How did you figure out what values your BIOS uses?

Does the adapter work for you through BIOS? I.e. do you see stuff on screen before the kernel loads? If yes, you could prevent the i915 driver from loading (to make sure it doesn't mess with the registers), boot to console, and run intel_reg_dumper from the intel-gpu-tools [2] package.


[1] git://people.freedesktop.org/~danvet/drm-intel
[2] git://git.freedesktop.org/git/xorg/app/intel-gpu-tools
Comment 25 Adam Baxter 2013-05-04 13:46:09 UTC
Jani, confirming this is an issue on the HD4000 series as well - Lenovo Carbon X1.

Please let me know what further information is needed - however I would be testing from a liveUSB setup as I don't have a *nix install on the internal drive yet.

I'm also willing to ship a Zotac DP->Dual HDMI adapter to someone if you think it'd help them fix the bug.
Comment 26 Jani Nikula 2013-05-06 08:04:36 UTC
(In reply to comment #25)
> Please let me know what further information is needed - however I would be
> testing from a liveUSB setup as I don't have a *nix install on the internal
> drive yet.

Please see comment #24.

> I'm also willing to ship a Zotac DP->Dual HDMI adapter to someone if you
> think it'd help them fix the bug.

Thanks for the offer, we've got one.
Comment 27 Jani Nikula 2013-09-23 18:23:08 UTC
Created attachment 86402 [details] [review]
drm/i915: don't write training pattern set if it doesn't change

I had a look at this again. Here's a patch that fixes clock recovery (part of link training) for me. It's on top of drm-intel-nightly branch of [1]. I don't know if it does the right thing or whether it's strictly per the DP spec, but it's worth a try. Please report whether it works for you. Also available at dp-training-pattern branch of [2].

[1] git://people.freedesktop.org/~danvet/drm-intel
[2] git://gitorious.org/jani/drm.git
Comment 28 Jani Nikula 2013-09-27 12:12:34 UTC
Created attachment 86720 [details] [review]
drm/i915/dp: do not write DP_TRAINING_PATTERN_SET all the time

Please try the attached patch. Works for me.
Comment 29 Jani Nikula 2013-10-10 15:19:45 UTC
Presumed fixed by
commit 70aff66c953054334bf0569696901c13e206ade6
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Fri Sep 27 15:10:44 2013 +0300

    drm/i915/dp: do not write DP_TRAINING_PATTERN_SET all the time

We've fixed a number of display port link training issues, including the one above, and the Zotac adapter now works for me without problems running drm-intel-nightly branch of [1].

Please reopen if the problem persists running drm-intel-nightly.

If there is interest in getting this backported to stable kernels, please try a v3.12-rc kernel, cherry-pick the above commit on top (it applies cleanly), and report your Tested-by: if it works. Thanks.


[1] git://people.freedesktop.org/~danvet/drm

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.