All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Sean Paul <sean@poorly.run>
Cc: jani.nikula@intel.com, markyacoub@chromium.org,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	swboyd@chromium.org, David Airlie <airlied@linux.ie>,
	Sean Paul <seanpaul@chromium.org>,
	abhinavk@codeaurora.org, Thomas Zimmermann <tzimmermann@suse.de>,
	bjorn.andersson@linaro.org, freedreno@lists.freedesktop.org
Subject: Re: [PATCH v5 03/10] drm/hdcp: Update property value on content type and user changes
Date: Thu, 14 Apr 2022 17:44:11 -0400	[thread overview]
Message-ID: <YliVq7yaNVN5R24L@intel.com> (raw)
In-Reply-To: <YlhEipy/e3U2hePl@art_vandelay>

On Thu, Apr 14, 2022 at 03:58:02PM +0000, Sean Paul wrote:
> On Tue, Apr 12, 2022 at 09:25:59AM -0400, Rodrigo Vivi wrote:
> > On Mon, Apr 11, 2022 at 08:47:32PM +0000, Sean Paul wrote:
> > > 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).
> > > 
> > > Acked-by: Jani Nikula <jani.nikula@intel.com>
> > > Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
> > > Signed-off-by: Sean Paul <seanpaul@chromium.org>
> > > Link: https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-4-sean@poorly.run #v1
> > > Link: https://patchwork.freedesktop.org/patch/msgid/20210915203834.1439-4-sean@poorly.run #v2
> > > Link: https://patchwork.freedesktop.org/patch/msgid/20211001151145.55916-4-sean@poorly.run #v3
> > > Link: https://patchwork.freedesktop.org/patch/msgid/20211105030434.2828845-4-sean@poorly.run #v4
> > > 
> > > Changes in v2:
> > > -None
> > > Changes in v3:
> > > -Fixed indentation issue identified by 0-day
> > > Changes in v4:
> > > -None
> > > Changes in v5:
> > > -None
> > > ---
> > >  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..8c851d40cd45 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) {
> > 
> > shouldn't we add some && ( old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED)) {
> > here?
> 
> Thanks for your reviews Rodrigo.
> 
> I don't think so since the content type is changing the current state of old
> content protection is immaterial (ie: if we need to enable HDCP 2.x, the state
> of HDCP 1.x doesn't really matter), we need to re-evaluate whether the current
> level of HDCP is sufficient.
> 
> Hopefully that makes sense, but I could be missing something :-)

nope, I think I was just missing that the important is the content type change
as you pointed out in the item number 1 in the commit msg.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>


> 
> Sean
> 
> > 
> > > +		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
> > > 
> 
> -- 
> Sean Paul, Software Engineer, Google / Chromium OS

WARNING: multiple messages have this Message-ID (diff)
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Sean Paul <sean@poorly.run>
Cc: Maxime Ripard <mripard@kernel.org>,
	jani.nikula@intel.com, markyacoub@chromium.org,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	swboyd@chromium.org, David Airlie <airlied@linux.ie>,
	Sean Paul <seanpaul@chromium.org>,
	abhinavk@codeaurora.org, Thomas Zimmermann <tzimmermann@suse.de>,
	bjorn.andersson@linaro.org, freedreno@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v5 03/10] drm/hdcp: Update property value on content type and user changes
Date: Thu, 14 Apr 2022 17:44:11 -0400	[thread overview]
Message-ID: <YliVq7yaNVN5R24L@intel.com> (raw)
In-Reply-To: <YlhEipy/e3U2hePl@art_vandelay>

On Thu, Apr 14, 2022 at 03:58:02PM +0000, Sean Paul wrote:
> On Tue, Apr 12, 2022 at 09:25:59AM -0400, Rodrigo Vivi wrote:
> > On Mon, Apr 11, 2022 at 08:47:32PM +0000, Sean Paul wrote:
> > > 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).
> > > 
> > > Acked-by: Jani Nikula <jani.nikula@intel.com>
> > > Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
> > > Signed-off-by: Sean Paul <seanpaul@chromium.org>
> > > Link: https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-4-sean@poorly.run #v1
> > > Link: https://patchwork.freedesktop.org/patch/msgid/20210915203834.1439-4-sean@poorly.run #v2
> > > Link: https://patchwork.freedesktop.org/patch/msgid/20211001151145.55916-4-sean@poorly.run #v3
> > > Link: https://patchwork.freedesktop.org/patch/msgid/20211105030434.2828845-4-sean@poorly.run #v4
> > > 
> > > Changes in v2:
> > > -None
> > > Changes in v3:
> > > -Fixed indentation issue identified by 0-day
> > > Changes in v4:
> > > -None
> > > Changes in v5:
> > > -None
> > > ---
> > >  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..8c851d40cd45 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) {
> > 
> > shouldn't we add some && ( old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED)) {
> > here?
> 
> Thanks for your reviews Rodrigo.
> 
> I don't think so since the content type is changing the current state of old
> content protection is immaterial (ie: if we need to enable HDCP 2.x, the state
> of HDCP 1.x doesn't really matter), we need to re-evaluate whether the current
> level of HDCP is sufficient.
> 
> Hopefully that makes sense, but I could be missing something :-)

nope, I think I was just missing that the important is the content type change
as you pointed out in the item number 1 in the commit msg.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>


> 
> Sean
> 
> > 
> > > +		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
> > > 
> 
> -- 
> Sean Paul, Software Engineer, Google / Chromium OS

  reply	other threads:[~2022-04-14 21:44 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-11 20:47 [PATCH v5 00/10] drm/hdcp: Pull HDCP auth/exchange/check into helpers Sean Paul
2022-04-11 20:47 ` [Intel-gfx] " Sean Paul
2022-04-11 20:47 ` [PATCH v5 01/10] drm/hdcp: Add drm_hdcp_atomic_check() Sean Paul
2022-04-11 20:47   ` [Intel-gfx] " Sean Paul
2022-04-12 13:15   ` Rodrigo Vivi
2022-04-12 13:15     ` [Intel-gfx] " Rodrigo Vivi
2022-04-11 20:47 ` [PATCH v5 02/10] drm/hdcp: Avoid changing crtc state in hdcp atomic check Sean Paul
2022-04-11 20:47   ` [Intel-gfx] " Sean Paul
2022-04-12 13:20   ` Rodrigo Vivi
2022-04-12 13:20     ` [Intel-gfx] " Rodrigo Vivi
2022-04-11 20:47 ` [PATCH v5 03/10] drm/hdcp: Update property value on content type and user changes Sean Paul
2022-04-11 20:47   ` [Intel-gfx] " Sean Paul
2022-04-12 13:25   ` Rodrigo Vivi
2022-04-12 13:25     ` [Intel-gfx] " Rodrigo Vivi
2022-04-14 15:58     ` Sean Paul
2022-04-14 15:58       ` Sean Paul
2022-04-14 21:44       ` Rodrigo Vivi [this message]
2022-04-14 21:44         ` [Intel-gfx] " Rodrigo Vivi
2022-04-11 20:47 ` [PATCH v5 04/10] drm/hdcp: Expand HDCP helper library for enable/disable/check Sean Paul
2022-04-11 20:47   ` [Intel-gfx] " Sean Paul
2022-04-12  1:52   ` kernel test robot
2022-04-12  1:52     ` kernel test robot
2022-04-11 20:47 ` [PATCH v5 05/10] drm/i915/hdcp: Consolidate HDCP setup/state cache Sean Paul
2022-04-11 20:47   ` [Intel-gfx] " Sean Paul
2022-04-12 13:37   ` Rodrigo Vivi
2022-04-12 13:37     ` [Intel-gfx] " Rodrigo Vivi
2022-04-11 20:47 ` [PATCH v5 06/10] drm/i915/hdcp: Retain hdcp_capable return codes Sean Paul
2022-04-11 20:47   ` [Intel-gfx] " Sean Paul
2022-04-12 13:36   ` Rodrigo Vivi
2022-04-12 13:36     ` [Intel-gfx] " Rodrigo Vivi
2022-04-11 20:47 ` [PATCH v5 07/10] drm/i915/hdcp: Use HDCP helpers for i915 Sean Paul
2022-04-11 20:47   ` [Intel-gfx] " Sean Paul
2022-04-11 20:47 ` [PATCH v5 08/10] dt-bindings: msm/dp: Add bindings for HDCP registers Sean Paul
2022-04-11 20:47   ` [Intel-gfx] " Sean Paul
2022-04-11 20:47   ` Sean Paul
2022-04-11 20:47 ` [PATCH v5 09/10] arm64: dts: qcom: sc7180: Add support for HDCP in dp-controller Sean Paul
2022-04-11 20:47   ` [Intel-gfx] " Sean Paul
2022-04-11 20:47   ` Sean Paul
2022-04-20  3:10   ` Bjorn Andersson
2022-04-20  3:10     ` [Intel-gfx] " Bjorn Andersson
2022-04-20  3:10     ` Bjorn Andersson
2022-04-11 20:47 ` [PATCH v5 10/10] drm/msm: Implement HDCP 1.x using the new drm HDCP helpers Sean Paul
2022-04-11 20:47   ` [Intel-gfx] " Sean Paul
2022-04-11 20:47   ` Sean Paul
2022-04-12  0:30   ` kernel test robot
2022-04-12  0:30     ` [Intel-gfx] " kernel test robot
2022-05-11 18:40   ` Dmitry Baryshkov
2022-05-11 18:40     ` Dmitry Baryshkov
2022-04-12 13:41 ` [PATCH v5 00/10] drm/hdcp: Pull HDCP auth/exchange/check into helpers Rodrigo Vivi
2022-04-12 13:41   ` [Intel-gfx] " Rodrigo Vivi
2022-04-14 16:00   ` Sean Paul
2022-04-14 16:00     ` [Intel-gfx] " Sean Paul
2022-06-15 12:53 ` [Freedreno] " Dmitry Baryshkov

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=YliVq7yaNVN5R24L@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=abhinavk@codeaurora.org \
    --cc=airlied@linux.ie \
    --cc=bjorn.andersson@linaro.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=markyacoub@chromium.org \
    --cc=sean@poorly.run \
    --cc=seanpaul@chromium.org \
    --cc=swboyd@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.