Bug 93915

Created attachment 121374 [details]
xrandr.log

(In reply to Humberto Israel Perez Rodriguez from comment #1)
> Created attachment 121374 [details]
> xrandr.log

BXT has an 'HPD sense invert' bit in the HOTPLUG_CTL register that causes display detection to be inverted; that value needs to be saved and restored across suspend/resume.  This patch from Bob Paauwe should solve the problem here:

http://patchwork.freedesktop.org/patch/72566/

Hi Humberto,
Could check with the patch?
Thanks

After test with the patch from @Matt Roper this issue is gone

kernel information :
===================
commit f5d413cccefa1f93d64c34f357151d42add63a84
Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Date:   Thu Mar 24 14:35:16 2016 +0000

    drm-intel-nightly: 2016y-03m-24d-14h-34m-29s UTC integration manifest

Matt,
Could you add a comment when the patch is integrated. Then we will check again.

(In reply to cprigent from comment #5)
> Matt,
> Could you add a comment when the patch is integrated. Then we will check
> again.

This patch probably won't be accepted upstream since the review feedback was that we should read the value from VBT rather than saving/restoring it.  I believe someone from VPG (Sivakumar?) is working on some patches for that.

The VBT solution won't work on embedded platforms that lack any kind of firmware that can provide a VBT, but it should work in most other cases.

(In reply to Matt Roper from comment #6)
> (In reply to cprigent from comment #5)
> > Matt,
> > Could you add a comment when the patch is integrated. Then we will check
> > again.
> 
> This patch probably won't be accepted upstream since the review feedback was
> that we should read the value from VBT rather than saving/restoring it.  I
> believe someone from VPG (Sivakumar?) is working on some patches for that.
> 
> The VBT solution won't work on embedded platforms that lack any kind of
> firmware that can provide a VBT, but it should work in most other cases.

Would it be possible to read out the register during booting and program it after resume during hpd setup time accordingly? That could be still overwritten  by any VBT settings.

(In reply to Matt Roper from comment #6)
> (In reply to cprigent from comment #5)
> > Matt,
> > Could you add a comment when the patch is integrated. Then we will check
> > again.
> 
> This patch probably won't be accepted upstream since the review feedback was
> that we should read the value from VBT rather than saving/restoring it.  I
> believe someone from VPG (Sivakumar?) is working on some patches for that.
> 
> The VBT solution won't work on embedded platforms that lack any kind of
> firmware that can provide a VBT, but it should work in most other cases.

Pushed the VBT solution to dinq as

commit d252bf68b75792108ae2821c3a6e1cdc58e88cb9
Author: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com>
Date:   Thu Mar 31 16:11:47 2016 +0530

    drm/i915: Set invert bit for hpd based on VBT

to make progress.

I'm closing this one as fixed, please file another bug about the non-VBT issue.

---

I've been slowly pushing towards abstracting VBT access from the rest of the driver to hide all the gory details. For example, the above commit adds a function to query the invert status, instead of directly accessing the VBT data.

We already have a function init_vbt_defaults() that we call in intel_bios_init() regardless of whether VBT is present. In this case, I could imagine adding a function to fill in more of dev_priv->vbt with sensible data when VBT is not present. Alternatively, the accessor functions could check if VBT was present or not and provide the data from somewhere else.