[igt-dev] [PATCH i-g-t v5 3/6] kms_content_protection: test content type change
Daniel Vetter
daniel at ffwll.ch
Mon Apr 29 14:40:16 UTC 2019
On Thu, Apr 18, 2019 at 02:18:39PM +0530, Ramalingam C wrote:
> Testing the content type change when the content protection already
> enabled.
>
> Signed-off-by: Ramalingam C <ramalingam.c at intel.com>
> ---
> tests/kms_content_protection.c | 61 ++++++++++++++++++++++++----------
> 1 file changed, 44 insertions(+), 17 deletions(-)
>
> diff --git a/tests/kms_content_protection.c b/tests/kms_content_protection.c
> index b33b37b9379c..754ce996640d 100644
> --- a/tests/kms_content_protection.c
> +++ b/tests/kms_content_protection.c
> @@ -164,7 +164,7 @@ static void modeset_with_fb(const enum pipe pipe, igt_output_t *output,
> }
>
> static bool test_cp_enable(igt_output_t *output, enum igt_commit_style s,
> - int content_type)
> + int content_type, bool test_type_change)
> {
> igt_display_t *display = &data.display;
> igt_plane_t *primary;
> @@ -172,8 +172,11 @@ static bool test_cp_enable(igt_output_t *output, enum igt_commit_style s,
>
> primary = igt_output_get_plane_type(output, DRM_PLANE_TYPE_PRIMARY);
>
> - igt_output_set_prop_value(output,
> - IGT_CONNECTOR_CONTENT_PROTECTION, CP_DESIRED);
> + if (!test_type_change)
> + igt_output_set_prop_value(output,
> + IGT_CONNECTOR_CONTENT_PROTECTION,
> + CP_DESIRED);
> +
> if (output->props[IGT_CONNECTOR_HDCP_CONTENT_TYPE])
> igt_output_set_prop_value(output,
> IGT_CONNECTOR_HDCP_CONTENT_TYPE,
> @@ -215,13 +218,17 @@ static void test_cp_disable(igt_output_t *output, enum igt_commit_style s)
>
> static void test_cp_enable_with_retry(igt_output_t *output,
> enum igt_commit_style s, int retry,
> - int content_type, bool expect_failure)
> + int content_type, bool expect_failure,
> + bool test_type_change)
> {
> + int retry_orig = retry;
> bool ret;
>
> do {
> - test_cp_disable(output, s);
> - ret = test_cp_enable(output, s, content_type);
> + if (!test_type_change || retry_orig != retry)
> + test_cp_disable(output, s);
> +
> + ret = test_cp_enable(output, s, content_type, test_type_change);
>
> if (!ret && --retry)
> igt_debug("Retry (%d/2) ...\n", 3 - retry);
> @@ -260,7 +267,7 @@ static void test_cp_lic(igt_output_t *output)
> static void
> test_content_protection_on_output(igt_output_t *output, enum igt_commit_style s,
> bool dpms_test, int content_type,
> - bool mei_reload_test)
> + bool mei_reload_test, bool test_type_change)
> {
> igt_display_t *display = &data.display;
> igt_plane_t *primary;
> @@ -281,7 +288,12 @@ test_content_protection_on_output(igt_output_t *output, enum igt_commit_style s,
> continue;
>
> modeset_with_fb(pipe, output, s);
> - test_cp_enable_with_retry(output, s, 3, content_type, false);
> + test_cp_enable_with_retry(output, s, 3, content_type, false,
> + false);
> + if (test_type_change && content_type == HDCP_CONTENT_TYPE_1)
> + test_cp_enable_with_retry(output, s, 3,
> + HDCP_CONTENT_TYPE_0, false,
> + test_type_change);
>
> if (mei_reload_test) {
> igt_assert_f(!igt_kmod_unload("mei_hdcp", 0),
> @@ -289,7 +301,7 @@ test_content_protection_on_output(igt_output_t *output, enum igt_commit_style s,
>
> /* Expected to fail */
> test_cp_enable_with_retry(output, s, 3,
> - content_type, false, true);
> + content_type, true, false);
>
> igt_assert_f(!igt_kmod_load("mei_hdcp", NULL),
> "mei_hdcp load failed");
> @@ -314,7 +326,8 @@ test_content_protection_on_output(igt_output_t *output, enum igt_commit_style s,
> KERNEL_AUTH_TIME_ALLOWED_MSEC);
> if (!ret)
> test_cp_enable_with_retry(output, s, 2,
> - content_type, false);
> + content_type, false,
> + false);
> }
>
> test_cp_disable(output, s);
> @@ -379,7 +392,8 @@ static bool sink_hdcp2_capable(igt_output_t *output)
>
> static void
> test_content_protection(enum igt_commit_style s, bool dpms_test,
> - int content_type, bool mei_reload_test)
> + int content_type, bool mei_reload_test,
> + bool test_type_change)
Hm this is getting a bit too much I think, usually we create a new usigned
flags and a pile of bitmask defines for this. Then you have checks like
if (flags & TEST_USE_ATOMIC_COMMIT)
or if (flags & TEST_TYPE1)
or similar. A long list of various bool arguments is pretty hard to read
on the caller side, since no one can remember what 0/true/false stands for
in each case, and it's easy to screw up.
Looks all good to me otherwise.
-Daniel
> {
> igt_display_t *display = &data.display;
> igt_output_t *output;
> @@ -411,7 +425,8 @@ test_content_protection(enum igt_commit_style s, bool dpms_test,
>
> test_content_protection_on_output(output, s, dpms_test,
> content_type,
> - mei_reload_test);
> + mei_reload_test,
> + test_type_change);
> valid_tests++;
> }
>
> @@ -430,30 +445,42 @@ igt_main
>
> igt_subtest("legacy")
> test_content_protection(COMMIT_LEGACY, false,
> - HDCP_CONTENT_TYPE_0, false);
> + HDCP_CONTENT_TYPE_0, false,
> + false);
>
> igt_subtest("atomic") {
> igt_require(data.display.is_atomic);
> test_content_protection(COMMIT_ATOMIC, false,
> - HDCP_CONTENT_TYPE_0, false);
> + HDCP_CONTENT_TYPE_0, false,
> + false);
> }
>
> igt_subtest("atomic-dpms") {
> igt_require(data.display.is_atomic);
> test_content_protection(COMMIT_ATOMIC, true,
> - HDCP_CONTENT_TYPE_0, false);
> + HDCP_CONTENT_TYPE_0, false,
> + false);
> }
>
> igt_subtest("type1") {
> igt_require(data.display.is_atomic);
> test_content_protection(COMMIT_ATOMIC, false,
> - HDCP_CONTENT_TYPE_1, false);
> + HDCP_CONTENT_TYPE_1, false,
> + false);
> }
>
> igt_subtest("type1_mei_interface") {
> igt_require(data.display.is_atomic);
> test_content_protection(COMMIT_ATOMIC, false,
> - HDCP_CONTENT_TYPE_1, true);
> + HDCP_CONTENT_TYPE_1, true,
> + false);
> + }
> +
> + igt_subtest("content_type_change") {
> + igt_require(data.display.is_atomic);
> + test_content_protection(COMMIT_ATOMIC, false,
> + HDCP_CONTENT_TYPE_1, false,
> + true);
> }
>
> igt_fixture
> --
> 2.19.1
>
> _______________________________________________
> igt-dev mailing list
> igt-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
More information about the igt-dev
mailing list