Bug 103159

Also, GLK-shards 

(kms_plane_scaling:1621) igt-kms-CRITICAL: Test assertion failure function igt_drm_plane_commit, file igt_kms.c:2245:
(kms_plane_scaling:1621) igt-kms-CRITICAL: Failed assertion: ret == 0
(kms_plane_scaling:1621) igt-kms-CRITICAL: Last errno: 22, Invalid argument
(kms_plane_scaling:1621) igt-kms-CRITICAL: error: -22 != 0
Test kms_plane_scaling failed.

https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3255/shard-glkb4/igt@kms_plane_scaling.html

Hi, 

By reviewing the logs, I see two kinds of failures:

On the CI APL and GLK:

[drm:skl_check_pipe_max_pixel_rate [i915]] Max supported pixel clock with scaling exceeded

And on the CI KBL:

[drm:__setplane_internal] Invalid pixel format XR24 little-endian (0x34325258)

On my personal system, which is an APL, I get the second kind of error.  It is due the attempt to use that pixel format on a cursor plane, which apparently is not supported.  Since we blindly fetch a plane, we could avoid that error with something like:  

--- a/tests/kms_plane_scaling.c
+++ b/tests/kms_plane_scaling.c
@@ -215,7 +215,7 @@ static void test_plane_scaling(data_t *d)
                }

                /* Set up fb2->plane2 mapping. */
-               d->plane2 = igt_output_get_plane(output, 2);
+               d->plane2 = igt_output_get_plane_type(output, DRM_PLANE_TYPE_OVERLAY);
                igt_plane_set_fb(d->plane2, &d->fb2);

                /* 2nd plane windowed */


That said, once I prevent that issue, I can hit the second error on my APL lake too:

[drm:skl_check_pipe_max_pixel_rate [i915]] Max supported pixel clock with scaling exceeded

> [drm:__setplane_internal] Invalid pixel format XR24 little-endian
> (0x34325258)

So... this is a regression introduced by igt commit 

ca20170afc6f ("tests/kms_plane_scaling: Add support for dynamic number of planes").

which I have a patch to fix.


> [drm:skl_check_pipe_max_pixel_rate [i915]] Max supported pixel clock with
> scaling exceeded

This appeared with the pixel rate check in linux commit:

73b0ca8ec76d ("drm/i915/skl+: consider max supported plane pixel rate while scaling").

I'll review this algorithm, but I still don't know why we calculate such a high rate.  We have a 4.2 plane_downscale which seems too big.  

I plan to send both patches as soon as i figure the second error out.

One patch merged, does this help thing?
https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/commit/?id=bde7d72f58df18f86127b5b7fdcb89b64ee1a1d2

IGT-Version: 1.20-gbde7d72f (x86_64) (Linux: 4.14.0-rc8-CI-CI_DRM_3317+ x86_64)
I.e. the patch is integrated.

But the test still fails:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3317/shard-glkb1/igt@kms_plane_scaling.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3317/shard-kbl6/igt@kms_plane_scaling.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3317/shard-apl3/igt@kms_plane_scaling.html


(kms_plane_scaling:15518) igt-kms-CRITICAL: Test assertion failure function igt_drm_plane_commit, file igt_kms.c:2157:
(kms_plane_scaling:15518) igt-kms-CRITICAL: Failed assertion: ret == 0
(kms_plane_scaling:15518) igt-kms-CRITICAL: Last errno: 22, Invalid argument
(kms_plane_scaling:15518) igt-kms-CRITICAL: error: -22 != 0
Test kms_plane_scaling failed.

(In reply to Jani Saarinen from comment #4)
> One patch merged, does this help thing?
> https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/commit/
> ?id=bde7d72f58df18f86127b5b7fdcb89b64ee1a1d2

Yes.  It fixes the following kind of failure on KBL (See comment 3):

> > [drm:__setplane_internal] Invalid pixel format XR24 little-endian
> > (0x34325258)

The other issue (below) is with the Pixel clock rate calculation, which I'm working on the driver-side for a fix.

> [drm:skl_check_pipe_max_pixel_rate [i915]] Max supported pixel clock with
> scaling exceeded

(In reply to krisman from comment #6)
> (In reply to Jani Saarinen from comment #4)
> > One patch merged, does this help thing?
> > https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/commit/
> > ?id=bde7d72f58df18f86127b5b7fdcb89b64ee1a1d2
> 
> Yes.  It fixes the following kind of failure on KBL (See comment 3):
> 
> > > [drm:__setplane_internal] Invalid pixel format XR24 little-endian
> > > (0x34325258)
> 
> The other issue (below) is with the Pixel clock rate calculation, which I'm
> working on the driver-side for a fix.
> 
> > [drm:skl_check_pipe_max_pixel_rate [i915]] Max supported pixel clock with
> > scaling exceeded

See for instance the following test:

https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3317/shard-kbl6/igt@kms_plane_scaling.html

Which no longer hits the invalid pixel format error but bails out on the pixel rate verification.

Regarding the pixel clock scaling exceeded issue: 

> > > [drm:skl_check_pipe_max_pixel_rate [i915]] Max supported pixel clock with
> > > scaling exceeded

The problem started to show after the following commit, which included a verification during .atomic_check() to ensure the bandwidth for pixel flow is enough for scaling operations.

73b0ca8ec76 ("drm/i915/skl+: consider max supported plane pixel rate while scaling")

The verification always succeeds when upscaling, since that operation won't increase the pixel rate, but it causes the same test to fail a while later, when trying downscaling.

As far as I can tell, there is no issue with the verification algorithm introduced by that commit, since it correctly calculates the desired pixel rate.  The problem happens a little before that on the driver, when calculating the required clock, because it doesn't take in consideration the scaling property.  This is where I'm patching a fix.

Note this test has been re-worked and split onto subtests. I will archive this bug from cibuglog, but leave the bug open since some people may be running on old IGT version.