public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Nautiyal, Ankit K" <ankit.k.nautiyal@intel.com>
To: Suraj Kandpal <suraj.kandpal@intel.com>,
	<intel-gfx@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH v3 3/4] drm/i915/hdcp: Fix modeset locking issue in hdcp mst
Date: Mon, 15 May 2023 15:40:52 +0530	[thread overview]
Message-ID: <03f0f72c-a368-5534-bf30-a58f951d62ac@intel.com> (raw)
In-Reply-To: <20230515051557.672109-4-suraj.kandpal@intel.com>


On 5/15/2023 10:45 AM, Suraj Kandpal wrote:
> Since topology state is being added to drm_atomic_state now all
> drm_modeset_lock required are being taken from core. This raises
> an issue when we try to loop over connector and assign vcpi id to
> our streams as we did not have atomic state to derive acquire_ctx
> from. We fill in stream info if dpmst encoder is found before
> enabling hdcp. intel_hdcp_required_stream will be broken which
> will only set the content type.
>
> --v2
> -move prepare streams to beginning of intel_hdcp_enable to avoid
> checking of mst encoder twice [Ankit]
>
> --v3
> -break intel_required_content_stream to two part and set the stream_id
> at the beginning [Ankit]
>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
> ---
>   drivers/gpu/drm/i915/display/intel_hdcp.c | 63 +++++++++++++++--------
>   1 file changed, 42 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index f2d258a72c59..64875c33832c 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -30,7 +30,8 @@
>   #define KEY_LOAD_TRIES	5
>   #define HDCP2_LC_RETRY_CNT			3
>   
> -static int intel_conn_to_vcpi(struct intel_connector *connector)
> +static int intel_conn_to_vcpi(struct drm_atomic_state *state,
> +			      struct intel_connector *connector)
>   {
>   	struct drm_dp_mst_topology_mgr *mgr;
>   	struct drm_dp_mst_atomic_payload *payload;
> @@ -42,7 +43,7 @@ static int intel_conn_to_vcpi(struct intel_connector *connector)
>   		return 0;
>   	mgr = connector->port->mgr;
>   
> -	drm_modeset_lock(&mgr->base.lock, NULL);
> +	drm_modeset_lock(&mgr->base.lock, state->acquire_ctx);
>   	mst_state = to_drm_dp_mst_topology_state(mgr->base.state);
>   	payload = drm_atomic_get_mst_payload_state(mst_state, connector->port);
>   	if (drm_WARN_ON(mgr->dev, !payload))
> @@ -54,7 +55,6 @@ static int intel_conn_to_vcpi(struct intel_connector *connector)
>   		goto out;
>   	}
>   out:
> -	drm_modeset_unlock(&mgr->base.lock);
>   	return vcpi;
>   }
>   
> @@ -71,22 +71,42 @@ static int intel_conn_to_vcpi(struct intel_connector *connector)
>   static int
>   intel_hdcp_required_content_stream(struct intel_digital_port *dig_port)
>   {
> -	struct drm_connector_list_iter conn_iter;
> -	struct intel_digital_port *conn_dig_port;
> -	struct intel_connector *connector;
> -	struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
>   	struct hdcp_port_data *data = &dig_port->hdcp_port_data;
>   	bool enforce_type0 = false;
>   	int k;
>   
> -	data->k = 0;
> -
>   	if (dig_port->hdcp_auth_status)
>   		return 0;
>   
>   	if (!dig_port->hdcp_mst_type1_capable)
>   		enforce_type0 = true;
>   
> +	/*
> +	 * Apply common protection level across all streams in DP MST Topology.
> +	 * Use highest supported content type for all streams in DP MST Topology.
> +	 */
> +	for (k = 0; k < data->k; k++)
> +		data->streams[k].stream_type =
> +			enforce_type0 ? DRM_MODE_HDCP_CONTENT_TYPE0 : DRM_MODE_HDCP_CONTENT_TYPE1;
> +
> +	return 0;

I think there is no need for return anything now.

Same with the caller for this function.

> +}
> +
> +static int
> +intel_hdcp_set_content_streams(struct intel_digital_port *dig_port,

Here we are setting stream id and number of streams k, so 'content' in 
the name can be dropped.

It would be good to place this function above the caller.

Otherwise looks good to me.


Regards,

Ankit


> +			       struct intel_atomic_state *state)
> +{
> +	struct drm_connector_list_iter conn_iter;
> +	struct intel_digital_port *conn_dig_port;
> +	struct intel_connector *connector;
> +	struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> +	struct hdcp_port_data *data = &dig_port->hdcp_port_data;
> +
> +	if (!intel_encoder_is_mst(&dig_port->base))
> +		return 0;
> +
> +	data->k = 0;
> +
>   	drm_connector_list_iter_begin(&i915->drm, &conn_iter);
>   	for_each_intel_connector_iter(connector, &conn_iter) {
>   		if (connector->base.status == connector_status_disconnected)
> @@ -99,7 +119,8 @@ intel_hdcp_required_content_stream(struct intel_digital_port *dig_port)
>   		if (conn_dig_port != dig_port)
>   			continue;
>   
> -		data->streams[data->k].stream_id = intel_conn_to_vcpi(connector);
> +		data->streams[data->k].stream_id =
> +			intel_conn_to_vcpi(&state->base, connector);
>   		data->k++;
>   
>   		/* if there is only one active stream */
> @@ -111,14 +132,6 @@ intel_hdcp_required_content_stream(struct intel_digital_port *dig_port)
>   	if (drm_WARN_ON(&i915->drm, data->k > INTEL_NUM_PIPES(i915) || data->k == 0))
>   		return -EINVAL;
>   
> -	/*
> -	 * Apply common protection level across all streams in DP MST Topology.
> -	 * Use highest supported content type for all streams in DP MST Topology.
> -	 */
> -	for (k = 0; k < data->k; k++)
> -		data->streams[k].stream_type =
> -			enforce_type0 ? DRM_MODE_HDCP_CONTENT_TYPE0 : DRM_MODE_HDCP_CONTENT_TYPE1;
> -
>   	return 0;
>   }
>   
> @@ -2375,9 +2388,17 @@ int intel_hdcp_enable(struct intel_atomic_state *state,
>   	 * is capable of HDCP2.2, it is preferred to use HDCP2.2.
>   	 */
>   	if (intel_hdcp2_capable(connector)) {
> -		ret = _intel_hdcp2_enable(connector);
> -		if (!ret)
> -			check_link_interval = DRM_HDCP2_CHECK_PERIOD_MS;
> +		ret = intel_hdcp_set_content_streams(dig_port, state);
> +		if (!ret) {
> +			ret = _intel_hdcp2_enable(connector);
> +			if (!ret)
> +				check_link_interval =
> +					DRM_HDCP2_CHECK_PERIOD_MS;
> +		} else {
> +			drm_dbg_kms(&dev_priv->drm,
> +				    "Set content streams failed: (%d)\n",
> +				    ret);
> +		}
>   	}
>   
>   	/*

  parent reply	other threads:[~2023-05-15 10:11 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-15  5:15 [Intel-gfx] [PATCH v3 0/4] Fix modeset locking issue in HDCP MST Suraj Kandpal
2023-05-15  5:15 ` [Intel-gfx] [PATCH v3 1/4] drm/i915/hdcp: add intel_atomic_state argument to hdcp_enable function Suraj Kandpal
2023-05-15  9:46   ` Jani Nikula
2023-05-15  5:15 ` [Intel-gfx] [PATCH v3 2/4] drm/i915/hdcp: Remove enforce_type0 check outside loop Suraj Kandpal
2023-05-15  9:46   ` Jani Nikula
2023-05-15  5:15 ` [Intel-gfx] [PATCH v3 3/4] drm/i915/hdcp: Fix modeset locking issue in hdcp mst Suraj Kandpal
2023-05-15 10:00   ` Jani Nikula
2023-05-15 10:10   ` Nautiyal, Ankit K [this message]
2023-05-15  5:15 ` [Intel-gfx] [PATCH v3 4/4] drm/i915/hdcp: Fill hdcp2_streamid_type and k in appropriate places Suraj Kandpal
2023-05-15 10:16   ` Nautiyal, Ankit K
2023-05-15  6:06 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for Fix modeset locking issue in HDCP MST (rev3) Patchwork
2023-05-15  6:19 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " 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=03f0f72c-a368-5534-bf30-a58f951d62ac@intel.com \
    --to=ankit.k.nautiyal@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=suraj.kandpal@intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox