[Intel-gfx] [PATCH v3 6/7] drm/i915/mtl: Add function to send command to GSC CS

[Teres Alexis, Alan Previn]

On Wed, 2022-12-14 at 14:37 +0530, Suraj Kandpal wrote:
> Add function that takes care of sending command to gsc cs. We start
> of with allocation of memory for our command intel_hdcp_gsc_message that
> contains gsc cs memory header as directed in specs followed by the
> actual payload hdcp message that we want to send.
> Spec states that we need to poll pending bit of response header around
> 20 times each try being 50ms apart hence adding that to current
> gsc_msg_send function
> Also we use the same function to take care of both sending and receiving
> hence no separate function to get the response.
> 
> Cc: Ankit Nautiyal <ankit.k.nautiyal at intel.com>
> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio at intel.com>
> Cc: Uma Shankar <uma.shankar at intel.com>
> Cc: Anshuman Gupta <anshuman.gupta at intel.com>
> Signed-off-by: Suraj Kandpal <suraj.kandpal at intel.com>
> ---
>  drivers/gpu/drm/i915/Makefile                 |   1 +
>  drivers/gpu/drm/i915/display/intel_hdcp_gsc.c | 207 ++++++++++++++++++
>  drivers/gpu/drm/i915/display/intel_hdcp_gsc.h |  18 ++
>  drivers/gpu/drm/i915/gt/uc/intel_gsc_fwif.h   |   1 +
>  4 files changed, 227 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
>  create mode 100644 drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index f64a8bc73c89..9cae0c1598a7 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -251,6 +251,7 @@ i915-y += \
>  	display/intel_frontbuffer.o \
>  	display/intel_global_state.o \
>  	display/intel_hdcp.o \
> +	display/intel_hdcp_gsc.o \
>  	display/intel_hotplug.o \
>  	display/intel_hti.o \
>  	display/intel_lpe_audio.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
> new file mode 100644
> index 000000000000..6858b6219221
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
> @@ -0,0 +1,207 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright 2021, Intel Corporation.
> + */
> +
> +#include "display/intel_hdcp_gsc.h"
> +#include "gem/i915_gem_region.h"
> +#include "gt/uc/intel_gsc_fw.h"
> +#include "gt/uc/intel_gsc_fwif.h"
> +#include "i915_drv.h"
> +#include "i915_utils.h"
> +
> +struct intel_hdcp_gsc_message {
> +	struct drm_i915_gem_object *obj;
> +	struct i915_vma *vma;
> +	void *hdcp_cmd;
> +};
> 
Alan: see my last set of comments below.

Alan:[snip
> 
> 

> +static int intel_gsc_send_sync(struct drm_i915_private *i915,
> +			       struct intel_gsc_mtl_header *header, u64 addr,
> +			       size_t msg_out_len)
> +{
> +	struct intel_gt *gt = i915->media_gt;
> +	int ret;
> +
> +	header->flags = 0;
> +	ret = intel_gsc_fw_heci_send(&gt->uc.gsc, addr, header->message_size,
> +				     addr, msg_out_len + sizeof(*header));
> +	if (ret) {
> +		drm_err(&i915->drm, "failed to send gsc HDCP msg (%d)\n", ret);
> +		return ret;
> +	}
> +	/*
> +	 * Checking validity marker for memory sanity
> +	 */
> +	if (header->validity_marker != GSC_HECI_VALIDITY_MARKER) {
> +		drm_err(&i915->drm, "invalid validity marker\n");
> +		return -EINVAL;
> +	}
> +
> +	if (header->status != 0) {
> +		drm_err(&i915->drm, "header status indicates error %d\n",
> +			header->status);
> +		return -EINVAL;
> +	}
> +
> +	if (header->flags & INTEL_GSC_MSG_PENDING)
> +		return -EAGAIN;
> +
> +	return 0;
> +}
> +
Alan: As per my comment on patch #1 above function could go into the uc/gsc domain ... see the comment below for further elaboration.

> +/*
> + * This function can now be used for sending requests and will also handle
> + * receipt of reply messages hence no different function of message retrieval
> + * is required. We will initialize intel_hdcp_gsc_message structure then add
> + * gsc cs memory header as stated in specs after which the normal HDCP payload
> + * will follow
> + */
> +ssize_t intel_hdcp_gsc_msg_send(struct drm_i915_private *i915, u8 *msg_in,
> +				size_t msg_in_len, u8 *msg_out, size_t msg_out_len)
> +{
> +	struct intel_gt *gt = i915->media_gt;
> +	struct intel_gsc_mtl_header *header;
> +	const size_t max_msg_size = PAGE_SIZE - sizeof(*header);
> +	struct intel_hdcp_gsc_message *hdcp_message;
> +	u64 addr;
> +	u32 reply_size;
> +	int ret, tries = 0;
> +
> +	if (!intel_uc_uses_gsc_uc(&gt->uc))
> +		return -ENODEV;
> +
> +	if (msg_in_len > max_msg_size || msg_out_len > max_msg_size)
> +		return -ENOSPC;
> +
> +	hdcp_message = kzalloc(sizeof(*hdcp_message), GFP_KERNEL);
> +
> +	if (!hdcp_message)
> +		return -ENOMEM;
> +
> +	ret = intel_initialize_hdcp_gsc_message(i915, hdcp_message);
> +
> +	if (ret) {
> +		drm_err(&i915->drm,
> +			"Could not initialize hdcp_message\n");
> +		goto err;
> +	}
> +
> +	header = hdcp_message->hdcp_cmd;
> +	addr = i915_ggtt_offset(hdcp_message->vma);
> +
> +	memset(header, 0, sizeof(*header));
> +	header->validity_marker = GSC_HECI_VALIDITY_MARKER;
> +	header->gsc_address = HECI_MEADDRESS_HDCP;
> +	header->host_session_handle = 0;
> +	header->header_version = MTL_GSC_HEADER_VERSION;
> +	header->message_size = msg_in_len + sizeof(*header);
> +
> +	memcpy(hdcp_message->hdcp_cmd + sizeof(*header), msg_in, msg_in_len);
> +
> +	/*
> +	 * Keep sending request in case the pending bit is set no need to add
> +	 * message handle as we are using same address hence loc. of header is
> +	 * same and it will contain the message handle. we will send the message
> +	 * 20 times each message 50 ms apart
> +	 */
> +	do {
> +		ret = intel_gsc_send_sync(i915, header, addr, msg_out_len);
> +
> +		/* Only try again if gsc says so */
> +		if (ret != -EAGAIN)
> +			break;
> +
> +		msleep(50);
> +
> +	} while (++tries < 20);
> +
> +	if (ret)
> +		goto err;
> +
> +	/* we use the same mem for the reply, so header is in the same loc */
> +	reply_size = header->message_size - sizeof(*header);
> +	if (reply_size > msg_out_len) {
> +		drm_warn(&i915->drm, "caller with insufficient HDCP reply size %u (%d)\n",
> +			 reply_size, (u32)msg_out_len);
> +		reply_size = msg_out_len;
> +	} else if (reply_size != msg_out_len) {
> +		drm_dbg_kms(&i915->drm, "caller unexpected HCDP reply size %u (%d)\n",
> +			    reply_size, (u32)msg_out_len);
> +	}
> +
> +	memcpy(msg_out, hdcp_message->hdcp_cmd + sizeof(*header), msg_out_len);
> +
> +err:
> +	intel_free_hdcp_gsc_message(hdcp_message);
> +	return ret;
> +}

Alan: See my review comment on patch #1 - i believe most of this function above (intel_hdcp_gsc_msg_send)
could go into a common intel_gsc_engine_send_hecipkt function (in a new gsc-heci specific file, i.e. intel_gsc_heci.c)
that lives in the uc/gsc domain, not here in display. In fact the "struct intel_hdcp_gsc_message" also also be renamed
to be "struct intel_gsc_heci_pkt_info" and its definition moved over to (and included from) a header in the uc/gsc domain.
I believe it make sense for the caller to allocate the objects but the common header to have the structure definition and
the common function can do the cmd-prep, submission, waiting (and eventually checking of pending-bit).


Alan:[snip]