<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Apple miniDP-to-VGA adapter doesn't work anymore since Kernel 4.1" href="https://bugs.freedesktop.org/show_bug.cgi?id=91451#c14">Comment # 14</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Apple miniDP-to-VGA adapter doesn't work anymore since Kernel 4.1" href="https://bugs.freedesktop.org/show_bug.cgi?id=91451">bug 91451</a> from <a class="email" href="mailto:simon@farnz.org.uk" title="Simon Farnsworth <simon@farnz.org.uk>"> Simon Farnsworth</a> <pre>(In reply to Ville Syrjala from <a href="show_bug.cgi?id=91451#c13">comment #13</a>) > (In reply to Simon Farnsworth from <a href="show_bug.cgi?id=91451#c12">comment #12</a>) > > 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are on the CC list for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>