Bug 91697

Created attachment 117805 [details]
dmesg dump

Created attachment 117806 [details]
dmesg from dpms cycle

apparently a DPMS cycle clears the error, and normal operation resumes

In further test, DPMS cycle can't clear the error on all platforms.

What dmc version are you using?
Could you please check what happens with latest ver1_21: https://01.org/linuxgraphics/downloads/skldmcver121

Thanks,
Rodrigo.

Created attachment 117905 [details]
drm log for distorted display in CRB

I used drm-intel-nightly (2015y-08m-24d-07h-39m-09s) in Ubuntu 15.04 with following fire-wares on CRB for BIOS RC 1.4, this issue could be reproduced.

skl_dmc_ver1_21
Details
Release Date: 
14 Aug, 2015
Version: ver1_21
Type: dmc

skl_guc_ver4_3
Details
Release Date: 
23 Jul, 2015
Version: ver4_3
Type: guc

Created attachment 117906 [details]
BIOS version for comment #5

List BIOS version for comment #5

Created attachment 117907 [details]
Distorted eDP display for comment #5

Distorted eDP display for comment #5

For comment #5, if I change to BIOS RC 1.3 for CRB, this issue went away.

This is using a Dell BIOS or an Intel reference BIOS?  Assuming a Dell BIOS what Intel BIOS version corresponds to that RC code version?

I checked it by Intel BIOS (please refer https://bugs.freedesktop.org/attachment.cgi?id=117906).

Created attachment 117924 [details]
Dump reg for symptom (before S3 and after resume)

Check related values of reg for issue being happened (please refer "reg_dump.7z", only DSPASURF changed by intel_reg_dumper).

This is critical issue reported by customer and blocking customer shipping schedule now. Please help to fix it. Thanks,

Created attachment 117946 [details]
force to check CDCLK in gfx driver during resuming from S3

Hi Timo, 

I found BIOS RC 1.4 will enable CDCLK PLL during S3 resume, then Linux gfx driver would not set CDCLk during its early init cdclk phase. Force to check CDCLk could avoid display corruption. I verify my patch with test cycle 10 times, it passed the test. 

Could you please help to verify it "0001-drm-i915-force-to-check-CDCLK-during-resuming-from-S.patch" before official solution from Intel back-end? Thanks!

I verified it on  drm-intel-nightly 2015/08/24.

Could you post your patch to the intel-gfx mailing list for review?

One thing that is important to check as well is if we correctly re-initialize the DDI PHY registers, could you check the value of register 0x64E00?

$ sudo ./tools/intel_reg read 0x64E00

Making sure that's not set to the reset value will avoid hard-to-debug bugs down the line.

As an early review:

Your patch makes the code still go through skl_dpll0_enable() when PLL0 is on after resume, which touches the CDCLK and DPLL0 registers. It sort of work because the PLL is already locked and the writes ignored but doesn't feel totally satisfactory.

Could you skip skl_dpll0_enable() if DPLL0 is already enabled?

Thanks,

Created attachment 117957 [details]
set CDCLK if DPLL0 enabled during resuming from S3

Hi Rodrigo and Damien,

Thanks for your comments. Yes, skl_dpll0_enable() should be skipped if DPLL0 enabled. 

I verified this issue with new patch on drm-intel-nightly 8/24/2015, it passed test (10 test cycles).

Hi Rodrigo and Damien,

I has checked DDI PHY reg for phases of before S3 and resume completed, they are the same,
(0x00064e00): 0x00000018

Created attachment 117958 [details]
set CDCLK if DPLL0 enabled during resuming from S3

Please ignore patch from comment #17.

I upload patch for comment #17/#18. Thanks!

we've verified that the latest version from #19 works fine

If we just enable the ‘DBUF Power Request’ bit in DBUF_CNTL, there is no display corruption. IMO this bit is left in reset state as we are enabling the PW2 in BIOS. Following change would also fix the issue:

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index af0bcfe..fd69c4c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5698,6 +5698,12 @@ void skl_init_cdclk(struct drm_i915_private *dev_priv)
        /* DPLL0 already enabed !? */
        if (I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE) {
                DRM_DEBUG_DRIVER("DPLL0 already running\n");
+               /* check for DBUF status and enable if in reset state */
+               if (!(I915_READ(DBUF_CTL) & DBUF_POWER_STATE)) {
+                       I915_WRITE(DBUF_CTL, I915_READ(DBUF_CTL)
+                                       | DBUF_POWER_REQUEST);
+                       POSTING_READ(DBUF_CTL);
+               }
                return;
        }

(In reply to Akshu Agrawal from comment #21)
> If we just enable the ‘DBUF Power Request’ bit in DBUF_CNTL, there is no
> display corruption. IMO this bit is left in reset state as we are enabling
> the PW2 in BIOS. Following change would also fix the issue:

We already have

commit 39d9b85a4d4fa1642663ca0d208b5c246a3d6f50
Author: Gary Wang <gary.c.wang@intel.com>
Date:   Fri Aug 28 16:40:34 2015 +0800

    drm/i915: set CDCLK if DPLL0 enabled during resuming from S3

merged in drm-intel-next-fixes. I just overlooked closing the bug. If there's a problem with that commit, please reopen.