<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body><span class="vcard"><a class="email" href="mailto:matthew.d.roper@intel.com" title="Matt Roper <matthew.d.roper@intel.com>"> <span class="fn">Matt Roper</span></a>
</span> changed
<a class="bz_bug_link
bz_status_NEW "
title="NEW - [CI][RESUME] igt@kms_plane_scaling@2x-scaler-multi-pipe - fail - Failed assertion: ret == 0"
href="https://bugs.freedesktop.org/show_bug.cgi?id=112027">bug 112027</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">CC</td>
<td>
</td>
<td>matthew.d.roper@intel.com
</td>
</tr>
<tr>
<td style="text-align:right;">Severity</td>
<td>not set
</td>
<td>minor
</td>
</tr>
<tr>
<td style="text-align:right;">Priority</td>
<td>not set
</td>
<td>low
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - [CI][RESUME] igt@kms_plane_scaling@2x-scaler-multi-pipe - fail - Failed assertion: ret == 0"
href="https://bugs.freedesktop.org/show_bug.cgi?id=112027#c3">Comment # 3</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - [CI][RESUME] igt@kms_plane_scaling@2x-scaler-multi-pipe - fail - Failed assertion: ret == 0"
href="https://bugs.freedesktop.org/show_bug.cgi?id=112027">bug 112027</a>
from <span class="vcard"><a class="email" href="mailto:matthew.d.roper@intel.com" title="Matt Roper <matthew.d.roper@intel.com>"> <span class="fn">Matt Roper</span></a>
</span></b>
<pre>Yes, Swati is correct; the issue is that the test is trying to use too many
scalers. The test only explicitly enables two plane scalers per pipe, but
fails to account for one of the scalers already being used by the pipe (i.e.,
in "panel fitter" mode).
In this case, the second display is driving a YCbCr display which necessitates
the use of a pipe scaler even in cases where the resolution does not change:
<7> [152.668726] [drm:skl_update_scaler [i915]] scaler_user index 1.31: staged
scaling request for 3840x2160->3840x2160 scaler_users = 0x80000000
...
<7> [154.169675] [drm:intel_dump_pipe_config [i915]] active: yes, output_types:
HDMI (0x40), output format: YCBCR4:2:0
Once we try to activate scaling on two planes, our scaler user bitmask for the
second display has three bits turned on (highest bit in the mask is the crtc):
<7> [154.115560] [drm:skl_update_scaler [i915]] scaler_user index 0.1: staged
scaling request for 500x500->3840x2160 scaler_users = 0x3
<7> [154.115676] [drm:skl_update_scaler [i915]] scaler_user index 1.9: staged
scaling request for 400x400->3840x2160 scaler_users = 0x80000300
which ultimately results in the kernel rejecting the atomic transaction as
invalid as Swati pointed out:
<7> [154.115816] [drm:intel_atomic_setup_scalers [i915]] Too many scaling
requests 3 > 2
This is exactly the behavior we want --- kernel properly rejects userspace
requests that it doesn't have the resources to handle. Real userspace would
take the failure into account and try again with a different compositing
strategy. Unfortunately our IGT tests are trying to use insider knowledge of
the hardware resources, but failing to account for CRTC scaler usage due to YUV
outputs, which leads to a false positive failure.
This should be fixed on the IGT side; there's no impact to end users, only to
CI. Setting priority/exposure to low.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
<li>You are the QA Contact for the bug.</li>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>