Created attachment 67565 [details]
intel_reg_dumper.txt

Created attachment 67566 [details]
xrandr verbose

The first question is whether it is an active dual-link dongle (presumably it is if it is drawing power)? If not then it is relying on hw support for dual-link, which is non-existent.

Anyway the handling of DP dongles is quite broken right now..

(In reply to comment #3)
> The first question is whether it is an active dual-link dongle (presumably
> it is if it is drawing power)? If not then it is relying on hw support for
> dual-link, which is non-existent.
> 
> Anyway the handling of DP dongles is quite broken right now..

Hi Chris - yes it is an active dongle that uses usb power.  Have you/Intel got any brand of dual link DP dongle to work? If so, which one(s)?  If not, anything else I can provide?

(In reply to comment #4)
> If not, anything else I can provide?

Please try the for-aidanamarks branch of git://gitorious.org/jani/drm.git

It's the latest Intel driver stuff with a few possibly related patches on top. Please use drm.debug=0xe and post the results. Thanks.

Created attachment 67651 [details]
dmesg-git1

Here are the debug results from your git branch.  No change, still 1024x768.

(In reply to comment #6)
> Created attachment 67651 [details]
> dmesg-git1
> 
> Here are the debug results from your git branch.  No change, still 1024x768.

Thanks, that confirms we're indeed getting the aux native defer reply. It seems that's not unusual for DP to legacy interface dongles as the downstream i2c bitrate might be slow. I pushed another patch to the same branch with "big enough" retry count to see if that helps. Please try that and post the dmesg.

Created attachment 67677 [details]
dmesg-git2

No change except noticable wait during bootup.

Just double checking some facts:

(In reply to comment #0)
> DRM on i7-3770T on Intel DH77EB motherboard doesn't detect the common Accell
> B087B-007B DisplayPort/Mini DisplayPort to DVI-D Dual-Link Adapter with 3D
> support.  It reverts back to 1024x768.

So you do get an image on the display using the adapter, just at 1024x768 resolution?

> Connected to it is a NEC LCD3090WQXi 30 inch at 2560x1600 native resolution
> on dual link DVI that works fine on a discrete Radeon NI card.

And this setup does not have the adapter, just the dual link DVI?

(In reply to comment #9)
> Just double checking some facts:
> 
> (In reply to comment #0)
> > DRM on i7-3770T on Intel DH77EB motherboard doesn't detect the common Accell
> > B087B-007B DisplayPort/Mini DisplayPort to DVI-D Dual-Link Adapter with 3D
> > support.  It reverts back to 1024x768.
> 
> So you do get an image on the display using the adapter, just at 1024x768
> resolution?

yes @ 1024x768.

> 
> > Connected to it is a NEC LCD3090WQXi 30 inch at 2560x1600 native resolution
> > on dual link DVI that works fine on a discrete Radeon NI card.
> 
> And this setup does not have the adapter, just the dual link DVI?

yes, with the discrete radeon card there is no dongle connected/needed as dual link DVI is supported natively.

I was just wondering when you may have bandwidth to work on this issue?  Would it help move things along if I buy an identical dongle and ship it to one of you?

Jani bought a few dp dongles to play around with, dunno whether this one here was included in the batch. Assigning the bug to him at least.

New kernel (3.7), time for a test...

Created attachment 71405 [details]
dmesg-3.7.0-kernel

Hi Chris - no change with the 3.7 kernel, still goes back to 1024x768 with the dongle.

$ equery l libdrm xf86-video-intel xorg-server   
 * Searching for libdrm ...
[IP-] [  ] x11-libs/libdrm-2.4.40:0

 * Searching for xf86-video-intel ...
[IP-] [  ] x11-drivers/xf86-video-intel-2.20.15:0

 * Searching for xorg-server ...
[IP-] [  ] x11-base/xorg-server-1.13.0-r1:0
$ uname -a
Linux vger 3.7.0-gentoo #1 SMP Wed Dec 12 22:24:30 EST 2012 x86_64 Intel(R) Core(TM) i7-3770T CPU @ 2.50GHz GenuineIntel GNU/Linux
$

Created attachment 76194 [details]
dmesg-3.8.2-kernel-drm-debug

Still doesn't work with 3.8 kernel *sigh*. drm.debug attached.

If it's all too hard, please tell me which dongle(s) do actually work, I will just buy one of the working ones.

$ equery l xorg-server xf86-video-intel libdrm mesa
 * Searching for xorg-server ...
[IP-] [  ] x11-base/xorg-server-1.14.0:0/1.14.0

 * Searching for xf86-video-intel ...
[IP-] [  ] x11-drivers/xf86-video-intel-2.21.3:0

 * Searching for libdrm ...
[IP-] [  ] x11-libs/libdrm-2.4.42:0

 * Searching for mesa ...
[IP-] [  ] media-libs/mesa-9.1:0
$ 
$ uname -a
Linux vger 3.8.2-gentoo #1 SMP Sat Mar 9 08:28:45 EST 2013 x86_64 Intel(R) Core(TM) i7-3770T CPU @ 2.50GHz GenuineIntel GNU/Linux
$

Imre had a patch for this I believe...

Hi Imre - happy to test.  This is still a daily issue for me. thanks.

Just in case, currently running:

xorg-server-1.14.2.901
xf86-video-intel-2.21.14
libdrm-2.4.46
mesa-9.1.6
gentoo-sources-3.8.2

(In reply to comment #17)
> Hi Imre - happy to test.  This is still a daily issue for me. thanks.
> 
> Just in case, currently running:
> 
> xorg-server-1.14.2.901
> xf86-video-intel-2.21.14
> libdrm-2.4.46
> mesa-9.1.6
> gentoo-sources-3.8.2

It was actually Mika's patch, but yes the dmesg here looks similar to the corresponding bug. Please try "drm/i915: Don't fallback to ddc probe if downstream port is dummy" in bug 60263.

Please try intel-dp-fixes branch of git://gitorious.org/jani/drm.git. It's intel-drm-nightly plus some DP aux fixes.

aidanamarks@gmail.com, there's been several DP dongle related fixes in the past months, please test current drm-intel-nightly branch at http://cgit.freedesktop.org/~danvet/drm-intel/log/?h=drm-intel-nightly

Hi Jani

It is still not working properly with latest drm-intel-nightly or gentoo-sources-3.12.6.  The same issue exists as per the original bug description.  It still reverts to 1024x768.

I have upgraded to:

xorg-server-1.15.0
xf86-video-intel-2.99.907
libdrm-2.4.50
mesa-9.2.5

I have also upgraded the Accell dongle firmware which made no difference either.

I will attach the drm debug with drm-intel-nightly.

Created attachment 91575 [details]
dmesg-3.13.0-rc7+-drm-intel-nightly-drm-debug

Guys - can you share what dual link dongles you actually have working at Intel?

Giving in to Mr DP.  Probably more DP training fail on our part.

Looks like AUX channel failures. Not being able to read DPCD or EDID params would likely give us fits. This should be interesting.

(In reply to comment #25)
> Looks like AUX channel failures. Not being able to read DPCD or EDID params
> would likely give us fits. This should be interesting.

Hi Todd - any update?  Do you need anything more from me?  Intel stuff no workie :(

Could you provide a log from a current kernel? A lot of the AUX stuff is now handled by the DRM layer, so if this persists after that change, that could lead in a couple different directions. If these dongles are appearing to the system as a branch device, that could also present some additional issues.

-T

Created attachment 98101 [details]
dmesg-3.14.1-drm-debug

(In reply to comment #27)
> Could you provide a log from a current kernel?

Hi Todd.  Please see attachment "dmesg-3.14.1-drm-debug".  Still not working with this kernel, stuck at 1024x768.

I also see stack traces for drm in there...it's not happy.

Current versions are:

gentoo-sources-3.14.1
xorg-server-1.15.0
xf86-video-intel-2.99.911
libdrm-2.4.53
mesa-10.1.0

Hi Todd, have you had a chance to look over the debug logs? thoughts?

Hi Todd, just a friendly reminder.  If you could take a look and let me know if you need any other info.  thanks.

Sorry for the long silence. Meanwhile we've reworked the dp aux code to use a shared library over all drivers, and that received a few fixes.

Can you please retest with latest kernels (preferrably 3.17-rc) and if things still don't really work, please attach a new dmesg with drm.debug=0xe.

(In reply to Daniel Vetter from comment #32)
> Sorry for the long silence. Meanwhile we've reworked the dp aux code to use
> a shared library over all drivers, and that received a few fixes.
> 
> Can you please retest with latest kernels (preferrably 3.17-rc) and if
> things still don't really work, please attach a new dmesg with drm.debug=0xe.

Ping for the extra info, except preferrably with v3.19-rc. Also, if that fails, you might want to try http://mid.gmane.org/1422373429-10137-1-git-send-email-simon.farnsworth@onelan.co.uk

Hi Jani

I tried 3.9.10-rc6 but that didn't work, however applying

[PATCH v3] drm/dp: Use large transactions for I2C over AUX

over the top did actually work!!! I have 2560x1600 resolution back now over the dongle.

Do you require any further logs?

Thanks for testing, Simon (+CC) will probably send another round of the patch after some further analysis, we'd appreciate you testing that. Thanks.

The Accell dongles are a Bizlink design under the covers (we've disassembled about 5 different makes of dongle here at the ONELAN offices, and found that there are many revisions from Bizlink - we saw HW revision 3, 13, 17 and 20).

On Haswell, I'm seeing the adapter crash after about a minute, even with my v3 patch - I've got an external hardware company (Datapath Ltd) comparing my v3 patch to Windows's behaviour, to see if they can see a cause. I assume that you're not seeing the adapter give up after a period of time?

(In reply to Simon Farnsworth from comment #36)

No crashes so far after 13 hours uptime.  I'll post here if it does.  Sounds like that's stable compared to yours.

FYI, 7 days of uptime on the v3 patch.  No issues at all so far.

(In reply to aidanamarks from comment #38)
> FYI, 7 days of uptime on the v3 patch.  No issues at all so far.

Thanks for the update! We're waiting for an update from Simon now.

I've now posted a v4 patch. Doesn't get me to a perfect place, but it's definitely an improvement.

Created attachment 113328 [details]
drm debug for v4 patch on 3.19-rc6

Hi Simon, I'm sorry to report that the v4 patch doesn't work for me at all, it reverts to 1024x768.  v3 was great though.  I'm attaching this debug for v4 in case it helps.  If you need anything more, let me know.

(In reply to aidanamarks from comment #41)
> Created attachment 113328 [details]
> drm debug for v4 patch on 3.19-rc6
> 
> Hi Simon, I'm sorry to report that the v4 patch doesn't work for me at all,
> it reverts to 1024x768.  v3 was great though.  I'm attaching this debug for
> v4 in case it helps.  If you need anything more, let me know.

One more thing, just to confirm that the patch has done what I'd expect it to do:

cat /sys/module/drm_kms_helper/parameters/dp_aux_i2c_transfer_size

I'd expect 16 - any other value is unexpected.

Created attachment 113346 [details] [review]
Debugging patch on top of v4 patch

Also, if you have a chance, can you apply this debugging patch on top of v4 and get me a fresh failure dmesg?

It just dumps out the key information from the transfer size algorithm, to confirm that it's doing what I expect it to do.

Created attachment 113348 [details] [review]
[PATCH] hack: try to set i2c bus speed to 100kbps via dpcd

The log with v4 just shows too many native defers, so could be the i2c transfer is just taking too long. This patch tries to force it to 100kHz even though your dongle doesn't report that it can actually change the speed. I don't really expect this to change anything, but might as well try.

I've tested v4 myself and it does what it's supposed to here, nor can I see anything wrong with the code. IIRC v3 also looked OK to me. So the only really viable explanation I can think of is that dongle is just having a bad day.

(In reply to Simon Farnsworth from comment #42)

> One more thing, just to confirm that the patch has done what I'd expect it
> to do:
> 
> cat /sys/module/drm_kms_helper/parameters/dp_aux_i2c_transfer_size
> 
> I'd expect 16 - any other value is unexpected.

It's 16 on the v3 patch but that file doesn't exist when I boot with v4.  The only file in the parameters directory with v4 is "poll".

(In reply to Simon Farnsworth from comment #43)
> Created attachment 113346 [details] [review] [review]
> Debugging patch on top of v4 patch
> 
> Also, if you have a chance, can you apply this debugging patch on top of v4
> and get me a fresh failure dmesg?
> 

The patch failed to apply on top of v4.  It's trying to patch functions that don't exist.  It looks like the patch is meant for v3?  Can you check please?  I'm not sure where you wanted the debug with v4.

(In reply to Ville Syrjala from comment #44)
> Created attachment 113348 [details] [review] [review]
> [PATCH] hack: try to set i2c bus speed to 100kbps via dpcd
> 
Hi Ville, you're right, it didn't help on top of v4 unfortunately.  I'm attaching the dmesg for your reference.

Created attachment 113421 [details]
drm debug for v4 patch and dpcd hack on 3.19-rc6

(In reply to Ville Syrjala from comment #44)
>
> I've tested v4 myself and it does what it's supposed to here, nor can I see
> anything wrong with the code. IIRC v3 also looked OK to me. So the only
> really viable explanation I can think of is that dongle is just having a bad
> day.

Ville, what I can say is that it's totally consistent/predictable.  Any boot with v3 is perfect, any boot with v4 is broken.  It's black and white in my testing, so there must be something going on between these two patches.  At least we're dealing with consistent results.

(In reply to aidanamarks from comment #46)
> (In reply to Simon Farnsworth from comment #43)
> > Created attachment 113346 [details] [review] [review] [review]
> > Debugging patch on top of v4 patch
> > 
> > Also, if you have a chance, can you apply this debugging patch on top of v4
> > and get me a fresh failure dmesg?
> > 
> 
> The patch failed to apply on top of v4.  It's trying to patch functions that
> don't exist.  It looks like the patch is meant for v3?  Can you check
> please?  I'm not sure where you wanted the debug with v4.

I generated the debug patch on top of the v4 patch; if it's trying to patch functions that don't exist, then you don't have the v4 patch applied to your kernel.

That would fit with the parameter not existing; it's created by the following lines from the v4 patch:

+static int dp_aux_i2c_transfer_size __read_mostly = DP_AUX_MAX_PAYLOAD_BYTES;
+module_param_unsafe(dp_aux_i2c_transfer_size, int, 0644);
+MODULE_PARM_DESC(dp_aux_i2c_transfer_size,
+                "Number of bytes to transfer in a single I2C over DP AUX CH message, (1-16, default 16)");
+

Fixed by

commit 1d002fa720738bcd0bddb9178e9ea0773288e1dd
Author: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Date:   Tue Feb 10 18:38:08 2015 +0000

    drm/dp: Use large transactions for I2C over AUX

in current drm-intel-nightly (through drm-misc). I hope we got it right, please reopen if the problem persists with that commit.