On Wed, 2023-03-29 at 08:43 +0100, Tvrtko Ursulin wrote: > On 28/03/2023 18:52, Rodrigo Vivi wrote: > > On Tue, Mar 28, 2023 at 05:01:36PM +0000, Teres Alexis, Alan Previn wrote: > > > On Mon, 2023-03-27 at 17:15 +0100, Tvrtko Ursulin wrote: > > > alan:snip > How will the context create path look like on those platforms: > > 1. Block, then potentially error out if the full initialization failed. > 2. Error out "in progress" while initializing, error out "something > else" if initialization failed. > alan:i was thinking of taking a page from huc-authentication's get-param where we could return different values based on startup progress - in all cases we never block: 1. we dont support it in hw/kernel (i.e. not pxp in device-info or not enough CONFIG_foo - reusing intel_pxp_is_supported?) 2. we support it in kernel but internal dependencies are still in progress (i.e. we have not yet completed huc-loading/huc-authen/proxy-init - UAPI spec should include how many max seconds delay per platform) 3. we support it in kernel but internal dependencies failed (i.e. we know huc-load/authent. failed ... or we know proxy-init failed). 4. we support it in kernel but platform has no support (at this stage we actually attempt to create a PXP context or create the arb-session from inside i915-get-param but we ended up a PXP fw error indicating select list of failures such as fusing / BIOS-config / wrong-version. 0. we support it completely i.e. step 4's attempt to create active PXP session succeeded I want to differentiate 3 and 4 (as opposed to return x-means-ENODEV) because i have am sure it will save debug time when facing customer issues. Ofc we will have to optimize the checking sequences above but at #4, we would be creating a session which might take up to ~200 milisecs for the round trip response from fw. We could store a flag in i915-pxp-internal-struct to indicate if we ever did succeed a pxp creation after a fresh boot ... intel_pxp_is_ready_for_active()? ... true only if we ever did allocate a slot successfully at least once since boot. This also ensure mesa init will return almost immediately except at the first time when hitting #4.
