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
