-
Alan Previn authored
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@intel.com> Reviewed-by: Balasubrawmanian, Vivaik <vivaik.balasubrawmanian@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230802182550.1592926-1-alan.previn.teres.alexis@intel.com
3b918f4f