Bug 103345

NOTE on CI_DRM_3265:

<tsa> glkb5?
<tsa> yeah, I changed the non-psr panel to 3200x psr panel, and now it's red
<tsa> need to find fullhd or 2560x psr panel ..
<tsa> although, fixing the 3200x issue would be fine too

So all these new fails are from that machine with this display:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb5/igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-mmap-gtt.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb5/igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-render.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb5/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-mmap-cpu.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb5/igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-blt.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb5/igt@kms_frontbuffer_tracking@psr-rgb565-draw-blt.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb5/igt@kms_frontbuffer_tracking@psr-rgb565-draw-pwrite.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb5/igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-shrfb-draw-pwrite.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb5/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-mmap-cpu.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb5/igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-shrfb-draw-mmap-cpu.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb5/igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-onoff.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb5/igt@kms_frontbuffer_tracking@fbcpsr-stridechange.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb5/igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-shrfb-draw-pwrite.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb5/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-mmap-wc.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb5/igt@kms_frontbuffer_tracking@psr-modesetfrombusy.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb5/igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-gtt.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb5/igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-pwrite.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb5/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-mmap-gtt.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb5/igt@kms_frontbuffer_tracking@psr-rgb565-draw-mmap-wc.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb5/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb5/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-move.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb5/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-blt.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb5/igt@kms_frontbuffer_tracking@psr-rgb101010-draw-mmap-wc.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb5/igt@kms_frontbuffer_tracking@psr-rgb101010-draw-blt.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb5/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-mmap-wc.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb5/igt@kms_psr_sink_crc@primary_blt.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb5/igt@kms_frontbuffer_tracking@fbcpsr-badstride.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb4/igt@kms_flip@vblank-vs-suspend-interruptible.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb5/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-render.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb5/igt@kms_frontbuffer_tracking@psr-farfromfence.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb5/igt@kms_frontbuffer_tracking@fbcpsr-rgb565-draw-mmap-cpu.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb5/igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-shrfb-draw-mmap-cpu.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb5/igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-fullscreen.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb5/igt@kms_frontbuffer_tracking@fbcpsr-rgb565-draw-pwrite.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb5/igt@kms_frontbuffer_tracking@psr-1p-rte.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb5/igt@kms_frontbuffer_tracking@psr-suspend.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3265/shard-glkb5/igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-gtt.html

Is this maybe related to the discussion started at:
https://bugs.freedesktop.org/show_bug.cgi?id=101623#c11
Where I showed that for BDW the "FBC disabled" frequency was related to which draw domains was being swapped between by the test.

and specifically on Cris suggestion to drop_caches instead of just increasing the timeout.

This seem to be congruent with the fact that we only hit this on the GLK5 that has the bigger display.

PSR is disabled for that panel/mode by:

<7>[  137.163726] [drm:intel_psr_compute_config [i915]] PSR condition failed: PSR setup time (330 us) too long

        if (intel_usecs_to_scanlines(adjusted_mode, psr_setup_time) >
            adjusted_mode->crtc_vtotal - adjusted_mode->crtc_vdisplay - 1) {
                DRM_DEBUG_KMS("PSR condition failed: PSR setup time (%d us) too long\n",
                              psr_setup_time);
                return;
        }

https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3367/shard-glkb1/igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-shrfb-draw-render.html

apparently not all was covered yet...

Even more, this probably comes now due to archiving some other bug...

https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3367/shard-glkb3/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-indfb-msflip-blt.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3367/shard-glkb6/igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-pwrite.html

Since commit dc911f5bd8aa ("drm/i915/edp: Allow alternate fixed mode for eDP if available.") the kernel has had very limited support for one set of alternate timings on eDP.

I have an SKL which has an eDP panel with this PSR vs. vblank length problem, and IIRC this crude support for alternate timings should be sufficient to enable the use of PSR on that panel.

So to fix the problem someone should change the test to iterate over the modes for the connector, and try to pick one where PSR works. An alternative approach would be to hack the EDID for the panel to remove the non PSR friendly mode and use the edid_firmware thing to override the EDID entirely, which would naturally make the entire igt run use the PSR friendly mode. But this latter approach would then have to replicated on every machine which has one of these annoying panels.

Quick update:
Assertion is now a bit different, these tests are still failing:

(kms_frontbuffer_tracking:1538) CRITICAL: Test assertion failure function do_status_assertions, file kms_frontbuffer_tracking.c:1856:
(kms_frontbuffer_tracking:1538) CRITICAL: Failed assertion: psr_is_enabled()
(kms_frontbuffer_tracking:1538) CRITICAL: PSR still disabled

(In reply to Elizabeth from comment #7)
> Quick update:
> Assertion is now a bit different, these tests are still failing:
> 
> (kms_frontbuffer_tracking:1538) CRITICAL: Test assertion failure function
> do_status_assertions, file kms_frontbuffer_tracking.c:1856:
> (kms_frontbuffer_tracking:1538) CRITICAL: Failed assertion: psr_is_enabled()
> (kms_frontbuffer_tracking:1538) CRITICAL: PSR still disabled

We are very well aware why these tests are failing on the GLK-shards.

(In reply to Marta Löfstedt from comment #8)
> (In reply to Elizabeth from comment #7)
> > Quick update:
> > Assertion is now a bit different, these tests are still failing:
> > 
> > (kms_frontbuffer_tracking:1538) CRITICAL: Test assertion failure function
> > do_status_assertions, file kms_frontbuffer_tracking.c:1856:
> > (kms_frontbuffer_tracking:1538) CRITICAL: Failed assertion: psr_is_enabled()
> > (kms_frontbuffer_tracking:1538) CRITICAL: PSR still disabled
> 
> We are very well aware why these tests are failing on the GLK-shards.

setting prio to low

We do not have these glk machines anymore, and we cannot reproduce this on any other glk (potentially because we do not have PSR-enabled panels).

In any case, let's close the bug because it was on pre-production HW.