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.ale...@intel.com>
> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com>
> Acked-by: Lionel Landwerlin <lionel.g.landwer...@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
