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
