[Bug 91451] Apple miniDP-to-VGA adapter doesn't work anymore since Kernel 4.1

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91451

--- Comment #14 from Simon Farnsworth <simon at farnz.org.uk> ---
(In reply to Ville Syrjala from comment #13)
> (In reply to Simon Farnsworth from comment #12)
> > So, a suggestion if anyone's got time to work on this:
> > 
> > drm_kms_helper.dp_aux_i2c_transfer_size sets the number of bytes of I2C data
> > we try to transfer in a single DP AUX transaction; the maximum is 16, the
> > minimum is 1 byte. I have devices that need 16 bytes per transaction,
> > otherwise they fail; it looks like the Apple adapter fails if you try to
> > transfer more than 4 bytes per transaction.
> > 
> > drm_dp_i2c_xfer currently only reduces the transfer size if the DP device
> > returns a partial success (e.g. 4 bytes of I2C data returned when we asked
> > for 16 will cause us to try with 4 bytes per transaction in future). With a
> > bit of care, it could also learn that when the I2C transaction reaches the
> > retry limit and the only response to DP AUX transactions was
> > DP_AUX_NATIVE_REPLY_DEFER, it's time to reduce the transaction size. Note
> > that you do expect some DP_AUX_NATIVE_REPLY_DEFERs in normal operation -
> > they're how the device tells you that it can't reply yet.
> 
> I don't think we should need to reduce the transfer size. What we should do
> is figure out how long the transfer might reasonably take, and adjust our
> timeouts accordingly.

If anyone with an affected adapter wants to test this, the two things to play
with, both in drm_dp_i2c_do_msg:

 1. Try changing the 7 in "for (retry = 0; retry < 7; retry++) {" to 70, and
see if that helps - it *will* make things slower, by allowing 70 attempts
before a transaction fails (at 0.5 ms per attempt, so a delay of 35 ms per
failed transaction instead of 3.5 ms), but it may fix things.

 2. Try changing the "500, 600" in "usleep_range(500, 600);" in the case
DP_AUX_NATIVE_REPLY_DEFER: block to "5000, 6000"; this makes us wait 5 ms
between attempts instead of 0.5 ms. Again, this will slow things down
massively,  especially if you increase the retry count to 70.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20150824/8ce19b04/attachment-0001.html>