[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