On Wed, May 20, 2020 at 9:08 AM Sean Paul <sean@xxxxxxxxxx> wrote:
>
> From: Sean Paul <seanpaul@xxxxxxxxxxxx>
>
> We're seeing some R0' mismatches in the field, particularly with
> repeaters. I'm guessing the (already lenient) 300ms wait time isn't
> enough for some setups. So add an additional wait when R0' is
> mismatched.
>
I think my guess was wrong and now suspect this issue is fixed with
"drm/i915/hdcp: Avoid duplicate HDCP enables".
While this patch probably still has some value in cases where R0' is
slow to update, I don't have any concrete examples where it helps.
Sean
> Signed-off-by: Sean Paul <seanpaul@xxxxxxxxxxxx>
>
> Changes in v2:
> - Actually add the delay in R0` wait (Ram)
> ---
>
> Apologies, v1 was generated from a forward port from the CrOS kernel and
> patch got confused and put the diff in V' wait instead of R0' wait.
>
> Pay closer attention, Sean.
>
> drivers/gpu/drm/i915/display/intel_hdcp.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index 2cbc4619b4ce..3c2d8c0a6da6 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -743,6 +743,9 @@ static int intel_hdcp_auth(struct intel_connector *connector)
> if (!wait_for(intel_de_read(dev_priv, HDCP_STATUS(dev_priv, cpu_transcoder, port)) &
> (HDCP_STATUS_RI_MATCH | HDCP_STATUS_ENC), 1))
> break;
> +
> + /* Maybe the sink is lazy, give it some more time */
> + usleep_range(10000, 50000);
> }
>
> if (i == tries) {
> --
> Sean Paul, Software Engineer, Google / Chromium OS
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
