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.ripard@xxxxxxxxxxx> --- 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
