
Upon receiving a CP_IRQ, the current implementation waits for up to 200 milliseconds for the link polling to be enabled, before reading the message from the sink. This wait is currently done in the DP HDCP module's main event thread. However, polling mode is also enabled in the same event thread upon a wakeup triggered by the HDCP engine. This can be problematic if the CP_IRQ comes before link has been transitioned to the polling mode. Such a sequence of event is easily seen when executing HDCP 2.3 CTS test 1B-09 using Unigraf UCD-400 test equipment. To address this, wait for the polling mode to be enabled from the CP_IRQ handler context directly and invoke the event thread only for reading the CP_IRQ message after the link has transitioned to polling mode. In addition to the above change, increase the wait time for link to transition to polling mode to 300ms. This is needed because, in the current implementation there is a fixed delay of 200ms as part of the call to the QSEECOM API to enable encryption after the authentication is successful. Change-Id: I0bdd4893bf63e6ae0fcda5dfb61f23e901061207 Signed-off-by: Aravind Venkateswaran <aravindh@codeaurora.org>
24 KiB
24 KiB