All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Paul <sean@poorly.run>
To: dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	freedreno@lists.freedesktop.org
Cc: Sean Paul <seanpaul@chromium.org>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>
Subject: [PATCH 03/14] drm/hdcp: Update property value on content type and user changes
Date: Mon, 13 Sep 2021 13:57:34 -0400	[thread overview]
Message-ID: <20210913175747.47456-4-sean@poorly.run> (raw)
In-Reply-To: <20210913175747.47456-1-sean@poorly.run>

From: Sean Paul <seanpaul@chromium.org>

This patch updates the connector's property value in 2 cases which were
previously missed:

1- Content type changes. The value should revert back to DESIRED from
   ENABLED in case the driver must re-authenticate the link due to the
   new content type.

2- Userspace sets value to DESIRED while ENABLED. In this case, the
   value should be reset immediately to ENABLED since the link is
   actively being encrypted.

To accommodate these changes, I've split up the conditionals to make
things a bit more clear (as much as one can with this mess of state).

Signed-off-by: Sean Paul <seanpaul@chromium.org>
---
 drivers/gpu/drm/drm_hdcp.c | 26 +++++++++++++++++---------
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index dd8fa91c51d6..742313ce8f6f 100644
--- a/drivers/gpu/drm/drm_hdcp.c
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -487,21 +487,29 @@ bool drm_hdcp_atomic_check(struct drm_connector *connector,
 		return true;
 
 	/*
-	 * Nothing to do if content type is unchanged and one of:
-	 *  - state didn't change
+	 * Content type changes require an HDCP disable/enable cycle.
+	 */
+	if (new_conn_state->hdcp_content_type != old_conn_state->hdcp_content_type) {
+		new_conn_state->content_protection =
+			DRM_MODE_CONTENT_PROTECTION_DESIRED;
+		return true;
+	}
+
+	/*
+	 * Ignore meaningless state changes:
 	 *  - HDCP was activated since the last commit
-	 *  - attempting to set to desired while already enabled
+	 *  - Attempting to set to desired while already enabled
 	 */
-	if (old_hdcp == new_hdcp ||
-	    (old_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
+	if ((old_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
 	     new_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED) ||
 	    (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
 	     new_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED)) {
-		if (old_conn_state->hdcp_content_type ==
-				new_conn_state->hdcp_content_type)
-			return false;
+		new_conn_state->content_protection =
+			DRM_MODE_CONTENT_PROTECTION_ENABLED;
+	     return false;
 	}
 
-	return true;
+	/* Finally, if state changes, we need action */
+	return old_hdcp != new_hdcp;
 }
 EXPORT_SYMBOL(drm_hdcp_atomic_check);
-- 
Sean Paul, Software Engineer, Google / Chromium OS


WARNING: multiple messages have this Message-ID (diff)
From: Sean Paul <sean@poorly.run>
To: dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	freedreno@lists.freedesktop.org
Cc: Sean Paul <seanpaul@chromium.org>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>
Subject: [Intel-gfx] [PATCH 03/14] drm/hdcp: Update property value on content type and user changes
Date: Mon, 13 Sep 2021 13:57:34 -0400	[thread overview]
Message-ID: <20210913175747.47456-4-sean@poorly.run> (raw)
In-Reply-To: <20210913175747.47456-1-sean@poorly.run>

From: Sean Paul <seanpaul@chromium.org>

This patch updates the connector's property value in 2 cases which were
previously missed:

1- Content type changes. The value should revert back to DESIRED from
   ENABLED in case the driver must re-authenticate the link due to the
   new content type.

2- Userspace sets value to DESIRED while ENABLED. In this case, the
   value should be reset immediately to ENABLED since the link is
   actively being encrypted.

To accommodate these changes, I've split up the conditionals to make
things a bit more clear (as much as one can with this mess of state).

Signed-off-by: Sean Paul <seanpaul@chromium.org>
---
 drivers/gpu/drm/drm_hdcp.c | 26 +++++++++++++++++---------
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index dd8fa91c51d6..742313ce8f6f 100644
--- a/drivers/gpu/drm/drm_hdcp.c
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -487,21 +487,29 @@ bool drm_hdcp_atomic_check(struct drm_connector *connector,
 		return true;
 
 	/*
-	 * Nothing to do if content type is unchanged and one of:
-	 *  - state didn't change
+	 * Content type changes require an HDCP disable/enable cycle.
+	 */
+	if (new_conn_state->hdcp_content_type != old_conn_state->hdcp_content_type) {
+		new_conn_state->content_protection =
+			DRM_MODE_CONTENT_PROTECTION_DESIRED;
+		return true;
+	}
+
+	/*
+	 * Ignore meaningless state changes:
 	 *  - HDCP was activated since the last commit
-	 *  - attempting to set to desired while already enabled
+	 *  - Attempting to set to desired while already enabled
 	 */
-	if (old_hdcp == new_hdcp ||
-	    (old_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
+	if ((old_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
 	     new_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED) ||
 	    (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
 	     new_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED)) {
-		if (old_conn_state->hdcp_content_type ==
-				new_conn_state->hdcp_content_type)
-			return false;
+		new_conn_state->content_protection =
+			DRM_MODE_CONTENT_PROTECTION_ENABLED;
+	     return false;
 	}
 
-	return true;
+	/* Finally, if state changes, we need action */
+	return old_hdcp != new_hdcp;
 }
 EXPORT_SYMBOL(drm_hdcp_atomic_check);
-- 
Sean Paul, Software Engineer, Google / Chromium OS


  parent reply	other threads:[~2021-09-13 17:58 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-13 17:57 [PATCH 00/14] drm/hdcp: Pull HDCP auth/exchange/check into Sean Paul
2021-09-13 17:57 ` [Intel-gfx] " Sean Paul
2021-09-13 17:57 ` [PATCH 01/14] drm/hdcp: Add drm_hdcp_atomic_check() Sean Paul
2021-09-13 17:57   ` [Intel-gfx] " Sean Paul
2021-09-13 17:57 ` [PATCH 02/14] drm/hdcp: Avoid changing crtc state in hdcp atomic check Sean Paul
2021-09-13 17:57   ` [Intel-gfx] " Sean Paul
2021-09-13 17:57 ` Sean Paul [this message]
2021-09-13 17:57   ` [Intel-gfx] [PATCH 03/14] drm/hdcp: Update property value on content type and user changes Sean Paul
2021-09-13 17:57 ` [PATCH 04/14] drm/hdcp: Expand HDCP helper library for enable/disable/check Sean Paul
2021-09-13 17:57   ` [Intel-gfx] " Sean Paul
2021-09-14  7:39   ` kernel test robot
2021-09-14  7:39     ` kernel test robot
2021-09-13 17:57 ` [PATCH 05/14] drm/i915/hdcp: Consolidate HDCP setup/state cache Sean Paul
2021-09-13 17:57   ` [Intel-gfx] " Sean Paul
2021-09-13 17:57 ` [PATCH 06/14] drm/i915/hdcp: Retain hdcp_capable return codes Sean Paul
2021-09-13 17:57   ` [Intel-gfx] " Sean Paul
2021-09-13 17:57 ` [PATCH 07/14] drm/i915/hdcp: Use HDCP helpers for i915 Sean Paul
2021-09-13 17:57   ` [Intel-gfx] " Sean Paul
2021-09-14  2:42   ` kernel test robot
2021-09-14  2:42     ` kernel test robot
2021-09-13 17:57 ` [PATCH 08/14] drm/msm/dpu_kms: Re-order dpu includes Sean Paul
2021-09-13 17:57   ` [Intel-gfx] " Sean Paul
2021-09-13 17:57 ` [PATCH 09/14] drm/msm/dpu: Remove useless checks in dpu_encoder Sean Paul
2021-09-13 17:57   ` [Intel-gfx] " Sean Paul
2021-09-13 17:57 ` [PATCH 10/14] drm/msm/dpu: Remove encoder->enable() hack Sean Paul
2021-09-13 17:57   ` [Intel-gfx] " Sean Paul
2021-09-13 17:57 ` [PATCH 11/14] drm/msm/dp: Re-order dp_audio_put in deinit_sub_modules Sean Paul
2021-09-13 17:57   ` [Intel-gfx] " Sean Paul
2021-09-13 17:57 ` [PATCH 12/14] dt-bindings: msm/dp: Add bindings for HDCP registers Sean Paul
2021-09-13 17:57   ` [Intel-gfx] " Sean Paul
2021-09-13 21:31   ` Rob Herring
2021-09-13 21:31     ` [Intel-gfx] " Rob Herring
2021-09-14  1:23   ` Stephen Boyd
2021-09-14  1:23     ` [Intel-gfx] " Stephen Boyd
2021-09-14  1:23     ` Stephen Boyd
2021-09-13 17:57 ` [PATCH 13/14] drm/msm: Add hdcp register ranges to sc7180 device tree Sean Paul
2021-09-13 17:57   ` [Intel-gfx] " Sean Paul
2021-09-14  1:28   ` Stephen Boyd
2021-09-14  1:28     ` [Intel-gfx] " Stephen Boyd
2021-09-14  1:28     ` Stephen Boyd
2021-09-13 17:57 ` [PATCH 14/14] drm/msm: Implement HDCP 1.x using the new drm HDCP helpers Sean Paul
2021-09-13 17:57   ` [Intel-gfx] " Sean Paul
2021-09-13 18:05 ` [PATCH 00/14] drm/hdcp: Pull HDCP auth/exchange/check into Alex Deucher
2021-09-13 18:05   ` [Intel-gfx] " Alex Deucher
2021-09-13 19:26   ` Sean Paul
2021-09-13 19:26     ` [Intel-gfx] " Sean Paul
2021-09-13 21:08     ` Harry Wentland
2021-09-13 21:08       ` [Intel-gfx] " Harry Wentland
2021-09-13 21:18 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210913175747.47456-4-sean@poorly.run \
    --to=sean@poorly.run \
    --cc=airlied@linux.ie \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=seanpaul@chromium.org \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.