| Message ID | 20210127065034.2501119-2-juston.li@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2,1/4] drm/i915/hdcp: Disable the QSES check for HDCP 1.4 over MST | expand |
> -----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
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); + if (msg_id == HDCP_2_2_REP_SEND_RECVID_LIST) { ret = get_receiver_id_list_size(dig_port); if (ret < 0)
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(-)