Re: [Intel-gfx] [PATCH v2 2/4] drm/i915/hdcp: update cp_irq_count_cached in intel_dp_hdcp2_read_msg()

["Gupta, Anshuman" <anshuman.gupta@intel.com>]

> -----Original Message-----
> From: Li, Juston <juston.li@intel.com>
> Sent: Wednesday, January 27, 2021 12:21 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: seanpaul@chromium.org; Gupta, Anshuman
> <anshuman.gupta@intel.com>; C, Ramalingam <ramalingam.c@intel.com>;
> Li, Juston <juston.li@intel.com>
> Subject: [PATCH v2 2/4] drm/i915/hdcp: update cp_irq_count_cached in
> intel_dp_hdcp2_read_msg()
> 
> Update cp_irq_count_cached when we handle reading the messages rather
> than writing a message to make sure the value is up to date and not stale
> from a previously handled CP_IRQ. AKE flow  doesn't always respond to a
> read with a write msg.
> 
> E.g. currently AKE_Send_Pairing_Info will "timeout" because we received a
> CP_IRQ for reading AKE_Send_H_Prime but no write occurred between that
> and reading AKE_Send_Pairing_Info so cp_irq_count_cached is stale
> causing the wait to return right away rather than waiting for a new CP_IRQ.
> 
> Signed-off-by: Juston Li <juston.li@intel.com>
> ---
>  drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> index 4dba5bb15af5..d1397af97f69 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> @@ -442,8 +442,6 @@ static
>  int intel_dp_hdcp2_write_msg(struct intel_digital_port *dig_port,
>  			     void *buf, size_t size)
>  {
> -	struct intel_dp *dp = &dig_port->dp;
> -	struct intel_hdcp *hdcp = &dp->attached_connector->hdcp;
>  	unsigned int offset;
>  	u8 *byte = buf;
>  	ssize_t ret, bytes_to_write, len;
> @@ -459,8 +457,6 @@ int intel_dp_hdcp2_write_msg(struct
> intel_digital_port *dig_port,
>  	bytes_to_write = size - 1;
>  	byte++;
> 
> -	hdcp->cp_irq_count_cached = atomic_read(&hdcp->cp_irq_count);
> -
>  	while (bytes_to_write) {
>  		len = bytes_to_write > DP_AUX_MAX_PAYLOAD_BYTES ?
>  				DP_AUX_MAX_PAYLOAD_BYTES :
> bytes_to_write; @@ -509,6 +505,8 @@ int
> intel_dp_hdcp2_read_msg(struct intel_digital_port *dig_port,
>  			    u8 msg_id, void *buf, size_t size)  {
>  	struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> +	struct intel_dp *dp = &dig_port->dp;
> +	struct intel_hdcp *hdcp = &dp->attached_connector->hdcp;
>  	unsigned int offset;
>  	u8 *byte = buf;
>  	ssize_t ret, bytes_to_recv, len;
> @@ -523,6 +521,8 @@ int intel_dp_hdcp2_read_msg(struct
> intel_digital_port *dig_port,
>  	if (ret < 0)
>  		return ret;
> 
> +	hdcp->cp_irq_count_cached = atomic_read(&hdcp->cp_irq_count);
> +
We can get a CP_IRQ even before caching it that may timeout the CP_IRQ wait but that is not an issue, 
I would have slightly conservative to remove it from  intel_dp_hdcp2_write_msg
and update the cp_irq_count_cached after reading the AKE_SEND_HPRIME.
Either way 
Acked-by: Anshuman Gupta <anshuman.gupta@intel.com>
>  	if (msg_id == HDCP_2_2_REP_SEND_RECVID_LIST) {
>  		ret = get_receiver_id_list_size(dig_port);
>  		if (ret < 0)
> --
> 2.29.2

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx