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

[Teres Alexis, Alan Previn]

(fixed email addresses again - why is my Evolution client deteorating??)

On Thu, 2023-04-27 at 17:18 +0000, Teres Alexis, Alan Previn wrote:
> 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
> > 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: I also realize with these final touch-ups, we can go back to the original
pxp-context-creation timeout of 250 milisecs like it was on ADL since the user
space component will have this new param to check on (so even farther down from
1 sec on the last couple of revs).

Jordan, Lional - i am thinking of creating the PR on MESA side to take advantage
of GET_PARAM on both get-caps AND runtime creation (latter will be useful to ensure
no unnecesssary delay experienced by Mesa stuck in kernel call - which practically
never happenned in ADL AFAIK):

1. MESA PXP get caps: 
	- use GET_PARAM (any positive number shall mean its supported).
2. MESA app-triggered PXP context creation (i.e. if caps was supported):
	- use GET_PARAM to wait until positive number switches from "2" to "1".
	- now call context creation. So at this point if it fails, we know its
	  an actual failure.

you guys okay with above? (i'll re-rev this kernel series first and wait on your
ack or feedback before i create/ test/ submit a PR for Mesa side).