<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<p>
<div>
<b><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#c15">Comment # 15</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 <span class="vcard"><a class="email" href="mailto:simon@farnz.org.uk" title="Simon Farnsworth <simon@farnz.org.uk>"> <span class="fn">Simon Farnsworth</span></a>
</span></b>
<pre>(In reply to Ville Syrjala from <a href="show_bug.cgi?id=91451#c13">comment #13</a>)
<span class="quote">> (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.</span >
I have an e-mail report saying that the following patch appears to help; Ville,
can you take over on this?
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 80a02a4..a17444f 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -440,7 +440,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct
drm_dp_aux_msg *msg)
* is required to retry at least seven times upon receiving AUX_DEFER
* before giving up the AUX transaction.
*/
- for (retry = 0, defer_i2c = 0; retry < (7 + defer_i2c); retry++) {
+ for (retry = 0, defer_i2c = 0; retry < (70 + defer_i2c); retry++) {
mutex_lock(&aux->hw_mutex);
ret = aux->transfer(aux, msg);
mutex_unlock(&aux->hw_mutex);</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<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>