drm/i915: CP_IRQ handling for DP HDCP2.2 msgs

Implements the
	Waitqueue is created to wait for CP_IRQ
	Signaling the CP_IRQ arrival through atomic variable.
	For applicable DP HDCP2.2 msgs read wait for CP_IRQ.

As per HDCP2.2 spec "HDCP Transmitters must process CP_IRQ interrupts
when they are received from HDCP Receivers"

Without CP_IRQ processing, DP HDCP2.2 H_Prime msg was getting corrupted
while reading it based on corresponding status bit. This creates the
random failures in reading the DP HDCP2.2 msgs.

v2:
  CP_IRQ arrival is tracked based on the atomic val inc [daniel]
  Recording the reviewed-by Daniel from IRC.

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1550338640-17470-16-git-send-email-ramalingam.c@intel.com
This commit is contained in:
Ramalingam C
2019-02-16 23:07:02 +05:30
committed by Daniel Vetter
parent 2d4254e506
commit cf9cb35ff7
3 changed files with 35 additions and 15 deletions

View File

@@ -1806,6 +1806,7 @@ int intel_hdcp_init(struct intel_connector *connector,
if (is_hdcp2_supported(dev_priv))
intel_hdcp2_init(connector);
init_waitqueue_head(&hdcp->cp_irq_queue);
return 0;
}
@@ -1935,12 +1936,8 @@ void intel_hdcp_handle_cp_irq(struct intel_connector *connector)
if (!hdcp->shim)
return;
/*
* CP_IRQ could be triggered due to 1. HDCP2.2 auth msgs availability,
* 2. link failure and 3. repeater reauth request. At present we dont
* handle the CP_IRQ for the HDCP2.2 auth msg availability for read.
* To handle other two causes for CP_IRQ we have the work_fn which is
* scheduled here.
*/
atomic_inc(&connector->hdcp.cp_irq_count);
wake_up_all(&connector->hdcp.cp_irq_queue);
schedule_delayed_work(&hdcp->check_work, 0);
}