[Bug 86202] Intel/VLV: EDID readout on DP port (with DP display connected) gives random results

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed Nov 26 07:50:54 PST 2014


https://bugs.freedesktop.org/show_bug.cgi?id=86202

--- Comment #6 from Ville Syrjala <ville.syrjala at linux.intel.com> ---
(In reply to Egbert Eich from comment #5)
> Further analysis has shown that this issue was actually fixed by the patch in
>   https://bugs.freedesktop.org/attachment.cgi?id=109670
> (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 :)

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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20141126/6c84c6d8/attachment-0001.html>


More information about the intel-gfx-bugs mailing list