(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).
