<html>
    <head>
      <base href="https://bugs.freedesktop.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEEDINFO "
   title="NEEDINFO - Intel/VLV: EDID readout on DP port (with DP display connected) gives random results"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=86202#c6">Comment # 6</a>
              on <a class="bz_bug_link 
          bz_status_NEEDINFO "
   title="NEEDINFO - Intel/VLV: EDID readout on DP port (with DP display connected) gives random results"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=86202">bug 86202</a>
              from <span class="vcard"><a class="email" href="mailto:ville.syrjala@linux.intel.com" title="Ville Syrjala <ville.syrjala@linux.intel.com>"> <span class="fn">Ville Syrjala</span></a>
</span></b>
        <pre>(In reply to Egbert Eich from <a href="show_bug.cgi?id=86202#c5">comment #5</a>)
<span class="quote">> Further analysis has shown that this issue was actually fixed by the patch in
>   <a href="https://bugs.freedesktop.org/attachment.cgi?id=109670">https://bugs.freedesktop.org/attachment.cgi?id=109670</a>
> (attached to fdo#86201).
> The reason for the issue is pretty much explained in that ticket.

> Ville, do you mind making sure that this patch is queued for drm-intel-next
> so that it doesn't get lost? 
> Thanks a lot :)</span >

Ugh. That patch really shouldn't fix EDID reads. But I guess it's possible this
is another one of those broken monitors that return garbage to AUX reads while
waking up, and the locking makes the operation slow enoguh that the monitor
falls back asleep between messages :( Either that or we have some nasty bug in
our aux code somewhere that causes this. Is it a HP ZR24w?

If the problem is widespread and the aux code is not at fault, I'm thinking we
may want to pursue the idea of waking up the sink around AUX transfers. I did
think about doing that at some point. The main complication is making sure the
sink doesn't get turned off when it should remain on. So maybe a ref count is
needed, or maybe we have enough locking in place to make sure we can just
return the sink to the same power state where we found it.</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>