It seems like there's a regression (at least using the vc4 DRM display
driver) when doing multiple calls to tests/kms_chamelium.c enable_output
after a single prepare_output.

Indeed, the DRM atomic_state doesn't seem to be full on the second run,
especially for the CRTC that doesn't have any encoder or connector enabled
(and isn't set as active). This will later fail here:
https://elixir.bootlin.com/linux/v4.16-rc5/source/drivers/gpu/drm/drm_atomic_helper.c#L607

With the atomic_commit failing. This went unnoticed mostly because all the
chamelium test cases that are enabled in the test suites do not follow that
pattern.

Since there's nothing really driver specific and it all seems that the
generic code in IGT is doing something wrong, let's try to run it on
intel's GPU to confirm (or deny) that it's broken for everyone.

Signed-off-by: Maxime Ripard <maxime.rip...@bootlin.com>
---
 tests/intel-ci/fast-feedback.testlist | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/intel-ci/fast-feedback.testlist 
b/tests/intel-ci/fast-feedback.testlist
index f71a16bcd191..847889d7220f 100644
--- a/tests/intel-ci/fast-feedback.testlist
+++ b/tests/intel-ci/fast-feedback.testlist
@@ -204,6 +204,7 @@ igt@kms_chamelium@dp-crc-fast
 igt@kms_chamelium@hdmi-hpd-fast
 igt@kms_chamelium@hdmi-edid-read
 igt@kms_chamelium@hdmi-crc-fast
+igt@kms_chamelium@hdmi-crc-multiple
 igt@kms_chamelium@vga-hpd-fast
 igt@kms_chamelium@vga-edid-read
 igt@kms_chamelium@common-hpd-after-suspend
-- 
2.14.3

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Reply via email to