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

[Lionel Landwerlin]

On 27/04/2023 21:19, Teres Alexis, Alan Previn wrote:
> (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).
>

Sounds good.

Thanks,


-Lionel