[PATCH v4 1/1] drm/i915/pxp: Optimize GET_PARAM:PXP_STATUS

Teres Alexis, Alan Previn alan.previn.teres.alexis at intel.com
Thu Aug 3 21:34:52 UTC 2023


On Wed, 2023-08-02 at 11:25 -0700, Teres Alexis, Alan Previn wrote:
> After recent discussions with Mesa folks, it was requested
> that we optimize i915's GET_PARAM for the PXP_STATUS without
> changing the UAPI spec.
> 
> Add these additional optimizations:
>    - If any PXP initializatoin flow failed, then ensure that
>      we catch it so that we can change the returned PXP_STATUS
>      from "2" (i.e. 'PXP is supported but not yet ready')
>      to "-ENODEV". This typically should not happen and if it
>      does, we have a platform configuration issue.
>    - If a PXP arbitration session creation event failed
>      due to incorrect firmware version or blocking SOC fusing
>      or blocking BIOS configuration (platform reasons that won't
>      change if we retry), then reflect that blockage by also
>      returning -ENODEV in the GET_PARAM:PXP_STATUS.
>    - GET_PARAM:PXP_STATUS should not wait at all if PXP is
>      supported but non-i915 dependencies (component-driver /
>      firmware) we are still pending to complete the init flows.
>      In this case, just return "2" immediately (i.e. 'PXP is
>      supported but not yet ready').
> 
> Difference from prio revs:
>   v3: - Rebase with latest tip that has pulled in setting the
>         gsc fw load to fail if proxy init fails.
>   v2: - Use a #define for the default readiness timeout (Vivaik).
>       - Improve comments around the failing of proxy-init.
>   v1: - Change the commit msg style to be imperative. (Jani)
>       - Rename timeout to timeout_ms. (Jani)
>       - Fix is_fw_err_platform_config to use higher order
>         param (pxp) first. (Jani)
> 
> Signed-off-by: Alan Previn <alan.previn.teres.alexis at intel.com>

alan: Daniele pointed out that i removed Vivaik's RB from rev-3.
The difference from this rev vs rev is a hunk of code got removed
and went into a different patch (that reused the same code, is
higher priority - CI related, and had to go first). So this rev
is identical to rev3 except a hunk that has been removed.
I've checked with Vivaik and he is good with keeping his R-b
since the rest of the patch is the same. Thus repasting his
R-b from rev3 (Thanks Daniele and Vivaik):

Reviewed-by: Balasubrawmanian, Vivaik <vivaik.balasubrawmanian at intel.com>


More information about the dri-devel mailing list