[Intel-gfx] [PATCH v8 6/8] drm/i915/uapi/pxp: Add a GET_PARAM for PXP

[Teres Alexis, Alan Previn]

On Thu, 2023-04-20 at 22:34 -0700, Teres Alexis, Alan Previn wrote:
> Because of the additional firmware, component-driver and
> initialization depedencies required on MTL platform before a
> PXP context can be created, UMD calling for PXP creation as a
> way to get-caps can take a long time. An actual real world
> customer stack has seen this happen in the 4-to-8 second range
> after the kernel starts (which sees MESA's init appear in the
> middle of this range as the compositor comes up). To avoid
> unncessary delays experienced by the UMD for get-caps purposes,
> add a GET_PARAM for I915_PARAM_PXP_SUPPORT.
> 
> However, some failures can still occur after all the depedencies
> are met (such as firmware init flow failure, bios configurations
> or SOC fusing not allowing PXP enablement). Those scenarios will
> only be known to user space when it attempts creating a PXP context.
> 
> With this change, large delays are only met by user-space processes
> that explicitly need to create a PXP context and boot very early.
> There is no way to avoid this today.
> 
> Signed-off-by: Alan Previn <alan.previn.teres.alexis at intel.com>
> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio at intel.com>
> Acked-by: Lionel Landwerlin <lionel.g.landwerlin at intel.com>
> ---
alan: Hi Jordan, Tvrtko, Daniel Vetter and Lionel,... 
how to proceed on this series (which have required Rb/Ack's) in light of
the recent discussion on the other series here:
https://patchwork.freedesktop.org/patch/532994/?series=115980&rev=8
it sounds like:
- Jordan still wants the extension query
- Daniel recapped the overview of historical discussions and kernel UAPI guidelines
  and in summary is okay with the GET_PARAM option. However Daniel cites PXP taking
  8 seconds to create a context is broken.
- I corrected above assumption -> current timeout is 1 second. 8 seconds is not the
  time taken to init the context, its the max-possible-time to ensure dependencies
  like the gsc-proxy-component is loaded so that protected context could be attempted
  successfully. Else, it would return an error that Mesa could interpret as not supported.

Should I:
(a) rerev this, drop this patch #6 and work towards merging the rest of the series
    to allow the get-param vs extensions-query to continue independently?
(b) go ahead and merge this series as is with the GET_PARAM? (i need to get the Mesa
    UMD change tested and PR requested first)

alan:snip