On Tue, 2023-11-14 at 16:00 +0200, Ville Syrjälä wrote: > On Wed, Oct 11, 2023 at 02:01:56PM +0300, Tomas Winkler wrote: > > From: Alexander Usyskin <alexander.usyskin@xxxxxxxxx> > > > > Disable and enable mei-pxp client on errors to clean the internal state. > > This broke i915 on my Alderlake-P laptop. > Hi Alex, i just relooked at the series that got merged, and i noticed that in patch #3 of the series, you had changed mei_pxp_send_message to return bytes sent instead of zero on success. IIRC, we had agreed to not effect the behavior of this component interface (other than adding the timeout) - this was the intention of Patch #4 that i was pushing for in order to spec the interface (which continues to say zero on success). We should fix this to stay with the original behavior - where mei-pxp should NOT send partial packets and will only return zero in success case where success is sending of the complete packets - so we don't need to get back the "bytes sent" from mei_pxp_send_message. So i think this might be causing the problem. Side note to Ville:, are you enabling PXP kernel config by default in all MESA contexts? I recall that MESA folks were running some CI testing with enable pxp contexts, but didn't realize this is being enabled by default in all contexts. Please be aware that enabling pxp-contexts would temporarily disabled runtime-pm during that contexts lifetime. Also pxp contexts will be forced to be irrecoverable if it ever hangs. The former is a hardware architecture requirement but doesn't do anything if you're enabling display (which I beleive also blocks in ADL). The latter was a requirement to comply with Vulkan. ...alan
