Please supply the bisect result, thanks.

3cb2803e582301bcdde86a30bf77fac32778a392 is the first bad commit
commit 3cb2803e582301bcdde86a30bf77fac32778a392
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Wed Nov 5 14:26:09 2014 -0800

    drm/i915: check for audio and infoframe changes across mode sets v2

    If these change (e.g. after a modeset following a fastboot), we need to
    do a full mode set.

    v2:
      - put under pipe_config check so we don't deref a null state (Jesse)

Hm, has_infoframe mismatch should be fixed in latest -nightly. Can you please double-check?

The bisect result seems to point at a different commit though, so I'm a bit confused.

(In reply to Daniel Vetter from comment #3)
> Hm, has_infoframe mismatch should be fixed in latest -nightly. Can you
> please double-check?
> 

DP has been fixed in the latest-nightly.But HDMI still has mismatch in has_infoframe error and still call trace:

[   35.218248] Call Trace:
[   35.218261]  [<ffffffff81789572>] ? dump_stack+0x41/0x51
[   35.218270]  [<ffffffff810368cc>] ? warn_slowpath_common+0x78/0x90
[   35.218307]  [<ffffffffa00c8e9b>] ? check_crtc_state+0xa9a/0xad2 [i915]
[   35.218314]  [<ffffffff8103697c>] ? warn_slowpath_fmt+0x45/0x4a
[   35.218351]  [<ffffffffa00c8e9b>] ? check_crtc_state+0xa9a/0xad2 [i915]
[   35.218390]  [<ffffffffa00d505f>] ? intel_modeset_check_state+0x461/0x768 [i915]
[   35.218427]  [<ffffffffa00d619f>] ? intel_crtc_set_config+0x855/0xbf5 [i915]
[   35.218447]  [<ffffffffa0017f54>] ? drm_mode_set_config_internal+0x4e/0xd2 [drm]
[   35.218457]  [<ffffffffa0060b2f>] ? restore_fbdev_mode+0xa8/0xc1 [drm_kms_helper]
[   35.218468]  [<ffffffffa0060b65>] ? drm_fb_helper_restore_fbdev_mode_unlocked+0x1d/0x34 [drm_kms_helper]
[   35.218483]  [<ffffffffa002352a>] ? drm_modeset_drop_locks+0x29/0x3c [drm]
[   35.218493]  [<ffffffffa00613e9>] ? drm_fb_helper_set_par+0x32/0x51 [drm_kms_helper]
[   35.218503]  [<ffffffffa00613b0>] ? drm_fb_helper_hotplug_event+0xa2/0xa9 [drm_kms_helper]
[   35.218510]  [<ffffffff81047bed>] ? process_one_work+0x1ae/0x31c
[   35.218516]  [<ffffffff81047fd5>] ? worker_thread+0x255/0x350
[   35.218522]  [<ffffffff81047d80>] ? process_scheduled_works+0x25/0x25


> The bisect result seems to point at a different commit though, so I'm a bit
> confused.

But I'm sorry ,I can't exactly unserstand what you refer to.

There was one more bug in the bdw/hsw infoframe readout code:

commit bbd440fb81338d8e8d58193867f1404c4e6cef7a
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Nov 20 22:33:59 2014 +0100

    drm/i915: Don't rely upon encoder->type for infoframe hw state readout

Since this issue still happens with latest -nightly, reopen it.

I'm guessing this should fix it.

http://lists.freedesktop.org/archives/intel-gfx/2014-November/056010.html

(In reply to Ville Syrjala from comment #7)
> I'm guessing this should fix it.
> 
> http://lists.freedesktop.org/archives/intel-gfx/2014-November/056010.html

Preventing we missing info, please use 'NEEDINFO' status more aggressive. :)

With this patch ,call trace disappear.But with this patch ,eDP goes black.We are not sure if it is caused by this commit :f8fb76317f35aca4294d9ea65cc87e8091da515b
drm/i915/chv: Enable AVI,	SPD and HDMI infoframes for CHV.

(In reply to Li Xu from comment #9)
> With this patch ,call trace disappear.But with this patch ,eDP goes black.We
> are not sure if it is caused by this commit
> :f8fb76317f35aca4294d9ea65cc87e8091da515b
> drm/i915/chv: Enable AVI,	SPD and HDMI infoframes for CHV.

Okay, so this bug has presumably been fixed by

commit b4eb1564623b2ee82e3296c808c68c6fe47548cd
Author: Clint Taylor <clinton.a.taylor@intel.com>
Date:   Fri Nov 21 11:13:02 2014 -0800

    drm/i915/chv: Enable AVI, SPD and HDMI infoframes for CHV.

Are you still seeing the eDP issues? Has another bug been filed for that? Can we close this one?

We have test with the latest kernel,but the eDP issues still exits.

This bug is not about the eDP issue.

Has another bug been filed for that?

Can we close this bug?

(In reply to Jani Nikula from comment #12)
> This bug is not about the eDP issue.
> 
> Has another bug been filed for that?
> 
> Can we close this bug?

Yes, it should be better closing this bug since the call trace on HDMI/DP hot-plug has gone. Any other issue such as eDP we should file new one.