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

[Teres Alexis, Alan Previn]

On Wed, 2023-04-26 at 15:35 -0700, Justen, Jordan L wrote:
> On 2023-04-26 11:17:16, Teres Alexis, Alan Previn wrote:
alan:snip

> 
> > - Jordan still wants the extension query
> Yes, I do, but so far it doesn't appear that any kernel devs think
> it's a reasonable request.
> 
> As I read through your emails about this pxp situation, it seems like
> a separate issue. When I encountered the 8s delay, it was on MTL, and
> apparently some firmware issue meant it was never going to work. So, I
> thought this was a case of it either being supported, or never being
> supported.
alan: this might be because of an older patch version in internal tree
- which I'm trying hard to fix to follow latest upstream - but keep getting
delays and conflicts - but thats unrelated to this upstream POV


> Now I'm seeing from your emails that in some cases it might be
> supported, but just not ready yet. In that case a status which is
> directly tied to pxp seems valuable. (But, yuck, how did we get into
> this situation? :)
alan: thanks for the go ahead on this PXP's uniquely different-issue
(and i must agree, 'yukcy' situation).

How did we get here? we are trying to debug this - its interesting to see
the same kernel with the same configs much faster on ADL vs MTL but
the MTL case is suffering because the mei-heci-parent driver is getting
loaded much later (which IS common to ADL) - this delayed parent driver
is causing the delay on the gsc-proxy component MTL. From parent load
to gsc-proxy bin+init is relatively fast (~few hundred milisecs). But I
believe it seems to only be happenning on select OS stacks (our ChromeOS
fork is definitely seeing this).


> Can you tell that pxp is in progress, but not ready yet, as a separate
> state from 'it will never work on this platform'? If so, maybe the
> status could return something like:
> 
> 0: It's never going to work
> 1: It's ready to use
> 2: It's starting and should work soon
> 
> I could see an argument for treating that as a case where we could
> still advertise protected content support, but if we try to use it we
> might be in for a nasty delay.
> 
alan: IIRC Lionel seemed okay with any permutation that would allow it to not
get blocked. Daniele did ask for something similiar to what u mentioned above
but he said that is non-blocking. But since both you AND Daniele have mentioned
the same thing, i shall re-rev this and send that change out today.
I notice most GET_PARAMS use -ENODEV for "never gonna work" so I will stick with that.
but 1 = ready to use and 2 = starting and should work sounds good. so '0' will never
be returned - we just look for a positive value (from user space). I will also
make a PR for mesa side as soon as i get it tested. thanks for reviewing btw.

alan:snip