<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#c7">Comment # 7</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:eich@pdx.freedesktop.org" title="Egbert Eich <eich@pdx.freedesktop.org>"> <span class="fn">Egbert Eich</span></a>
</span></b>
        <pre>
<span class="quote">> 
> 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?
> </span >

The monitor is a DELL 2212HM in fact.
I agree, this should not happen even it I2C read out is slowed down
considerably.

<span class="quote">> 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.</span >

Right. Maybe you have seen the discussion Daniel and I had on the intel-gfx@.
I had a really simplistic approach but Daniel was afraid that this will not
scale when adding more DP AUX transfers.
So implementing this the proper way is actually on my TODO. I didn't get to it,
yet.</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>