<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <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#c8">Comment # 8</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 <a class="email" href="mailto:ville.syrjala@linux.intel.com" title="Ville Syrjala <ville.syrjala@linux.intel.com>"> Ville Syrjala</a> <pre>(In reply to Egbert Eich from <a href="show_bug.cgi?id=86202#c7">comment #7</a>) > > > > 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? > > > > The monitor is a DELL 2212HM in fact. > I agree, this should not happen even it I2C read out is slowed down > considerably. > > > 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. > > 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. That discussion seemed somewhat orthogonal. What I'm talking about is sending the sink the DP_SET_POWER command around other AUX transfers to make sure it doesn't drop into sleep even if we take approximately forever to perform the transfer. But the pre/post hooks could potentially be the place where the DP_SET_POWER is issued.</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>