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@xxxxxxxxx> > Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@xxxxxxxxx> > Acked-by: Lionel Landwerlin <lionel.g.landwerlin@xxxxxxxxx> > --- 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
