kernel used was from latest drm-intel-nightly branch. 
This issue is no regression - EDID readout on DP hasnt' worked with any kernels I've tested.
PCI ID of GPU: 8086:0f31

I assume you've tested the same cable and display with some other device, and it works?

(In reply to Jani Nikula from comment #2)
> I assume you've tested the same cable and display with some other device,
> and it works?

Definitely. I'm using this cable regularly for testing purposes. To make sure I've just tested the cable/monitor combo on a Haswell system. It worked without issues there.
I haven't been able to test with another monitor brand / other VLV system. I may be able to do so tomorrow or Friday.

As it looks like, this issue is a fallout of 
  https://bugs.freedesktop.org/show_bug.cgi?id=86201
It does look like EDID readout did work on versions prior to commit 773538e86081d146e0020435d614f4b96996c1f9. 

I'm therefore marking this as a duplicate for now.

*** This bug has been marked as a duplicate of bug 86201 ***

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 :)

(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.

> 
> 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.

(In reply to Egbert Eich from comment #7)
> > 
> > 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.

Any chance this is fixed by
commit 7f1241ed1a06b4846ad7a2a57eb088b757e58e16
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Thu Dec 18 11:44:06 2014 +0200

    drm/i915: Kill check_power_well() calls

I'm pretty sure this is fixed now. Egbert, please don't hesitate to reopen if the problem persists. Thanks for the report.