[Intel-gfx] [PATCH v2 2/4] drm/i915/hdcp: update cp_irq_count_cached in intel_dp_hdcp2_read_msg()
Gupta, Anshuman
anshuman.gupta at intel.com
Wed Jan 27 07:17:21 UTC 2021
> -----Original Message-----
> From: Li, Juston <juston.li at intel.com>
> Sent: Wednesday, January 27, 2021 12:21 PM
> To: intel-gfx at lists.freedesktop.org
> Cc: seanpaul at chromium.org; Gupta, Anshuman
> <anshuman.gupta at intel.com>; C, Ramalingam <ramalingam.c at intel.com>;
> Li, Juston <juston.li at 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 at 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 at 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
More information about the Intel-gfx
mailing list