[Intel-gfx] [PATCH v2] drm/i915/pxp: don't start pxp without mei_pxp bind

Ceraolo Spurio, Daniele daniele.ceraolospurio at intel.com
Mon Aug 15 15:35:30 UTC 2022



On 8/9/2022 5:42 PM, Juston Li wrote:
> pxp will not start correctly until after mei_pxp bind completes and
> intel_pxp_init_hw() is called.
>
> This fixes a race condition during bootup where we observed a small
> window for pxp commands to be sent before mei_pxp bind completed.
>
> Changes since v1:
> - check pxp_component instead of pxp_component_added (Daniele)
> - pxp_component needs tee_mutex (Daniele)
> - return -EAGAIN so caller knows to retry (Daniele)

Sorry for the follow up, but I have reflected on this a bit more and I 
was thinking that maybe it would be better to wait a bit for the 
component to be bound, instead of immediately failing the call. Do you 
have a measure of how long after your failure you see the component bind 
complete? The wait would make sense only if relatively short (< 1s).

Daniele

> Signed-off-by: Juston Li <justonli at google.com>
> ---
>   drivers/gpu/drm/i915/pxp/intel_pxp.c | 8 ++++++++
>   1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> index 15311eaed848..8b395ebc430a 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -187,6 +187,14 @@ int intel_pxp_start(struct intel_pxp *pxp)
>   	if (!intel_pxp_is_enabled(pxp))
>   		return -ENODEV;
>   
> +	mutex_lock(&pxp->tee_mutex);
> +	/* check if mei_pxp is bound */
> +	if (!pxp->pxp_component) {
> +		mutex_unlock(&pxp->tee_mutex);
> +		return -EAGAIN;
> +	}
> +	mutex_unlock(&pxp->tee_mutex);
> +
>   	mutex_lock(&pxp->arb_mutex);
>   
>   	if (pxp->arb_is_valid)



More information about the Intel-gfx mailing list