From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Winkler, Tomas" <tomas.winkler@intel.com>
Cc: "Teres Alexis, Alan Previn" <alan.previn.teres.alexis@intel.com>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"Usyskin, Alexander" <alexander.usyskin@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Lubart, Vitaly" <vitaly.lubart@intel.com>
Subject: Re: [Intel-gfx] [char-misc-next 3/4] mei: pxp: re-enable client on errors
Date: Wed, 15 Nov 2023 22:35:16 +0200 [thread overview]
Message-ID: <ZVUrhGsqJ9jKNM5x@intel.com> (raw)
In-Reply-To: <MN2PR11MB4093E7F5490A51DED7672145E5B2A@MN2PR11MB4093.namprd11.prod.outlook.com>
On Tue, Nov 14, 2023 at 06:40:26PM +0000, Winkler, Tomas wrote:
>
>
> > -----Original Message-----
> > From: Teres Alexis, Alan Previn <alan.previn.teres.alexis@intel.com>
> > Sent: Tuesday, November 14, 2023 5:32 PM
> > To: ville.syrjala@linux.intel.com; Winkler, Tomas <tomas.winkler@intel.com>
> > Cc: gregkh@linuxfoundation.org; Usyskin, Alexander
> > <alexander.usyskin@intel.com>; linux-kernel@vger.kernel.org; intel-
> > gfx@lists.freedesktop.org; Lubart, Vitaly <vitaly.lubart@intel.com>
> > Subject: Re: [char-misc-next 3/4] mei: pxp: re-enable client on errors
> >
> > 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@intel.com>
> > > >
> > > > Disable and enable mei-pxp client on errors to clean the internal state.
> > >
> > > This broke i915 on my Alderlake-P laptop.
>
> This fix was already posted, just missed the merging window
> https://lkml.org/lkml/2023/10/31/636
Gave this a spin and it fixes the issue for me. Thanks.
>
> Greg can you please take this fix into v6.7-rc2 run, or I can repost it with the correct subject.
> Thanks
> Tomas
>
>
> > >
> >
> >
> > 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
> >
>
--
Ville Syrjälä
Intel
WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Winkler, Tomas" <tomas.winkler@intel.com>
Cc: "Teres Alexis, Alan Previn" <alan.previn.teres.alexis@intel.com>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"Usyskin, Alexander" <alexander.usyskin@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"Lubart, Vitaly" <vitaly.lubart@intel.com>
Subject: Re: [char-misc-next 3/4] mei: pxp: re-enable client on errors
Date: Wed, 15 Nov 2023 22:35:16 +0200 [thread overview]
Message-ID: <ZVUrhGsqJ9jKNM5x@intel.com> (raw)
In-Reply-To: <MN2PR11MB4093E7F5490A51DED7672145E5B2A@MN2PR11MB4093.namprd11.prod.outlook.com>
On Tue, Nov 14, 2023 at 06:40:26PM +0000, Winkler, Tomas wrote:
>
>
> > -----Original Message-----
> > From: Teres Alexis, Alan Previn <alan.previn.teres.alexis@intel.com>
> > Sent: Tuesday, November 14, 2023 5:32 PM
> > To: ville.syrjala@linux.intel.com; Winkler, Tomas <tomas.winkler@intel.com>
> > Cc: gregkh@linuxfoundation.org; Usyskin, Alexander
> > <alexander.usyskin@intel.com>; linux-kernel@vger.kernel.org; intel-
> > gfx@lists.freedesktop.org; Lubart, Vitaly <vitaly.lubart@intel.com>
> > Subject: Re: [char-misc-next 3/4] mei: pxp: re-enable client on errors
> >
> > 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@intel.com>
> > > >
> > > > Disable and enable mei-pxp client on errors to clean the internal state.
> > >
> > > This broke i915 on my Alderlake-P laptop.
>
> This fix was already posted, just missed the merging window
> https://lkml.org/lkml/2023/10/31/636
Gave this a spin and it fixes the issue for me. Thanks.
>
> Greg can you please take this fix into v6.7-rc2 run, or I can repost it with the correct subject.
> Thanks
> Tomas
>
>
> > >
> >
> >
> > 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
> >
>
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2023-11-15 20:39 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-11 11:01 [char-misc-next 0/4] mei: enhance mei pxp recoverability Tomas Winkler
2023-10-11 11:01 ` [char-misc-next 1/4] mei: bus: add send and recv api with timeout Tomas Winkler
2023-10-11 11:01 ` [char-misc-next 2/4] mei: pxp: recover from recv fail under memory pressure Tomas Winkler
2023-10-11 11:01 ` [char-misc-next 3/4] mei: pxp: re-enable client on errors Tomas Winkler
2023-11-14 14:00 ` [Intel-gfx] " Ville Syrjälä
2023-11-14 14:00 ` Ville Syrjälä
2023-11-14 15:31 ` [Intel-gfx] " Teres Alexis, Alan Previn
2023-11-14 15:31 ` Teres Alexis, Alan Previn
2023-11-14 18:40 ` [Intel-gfx] " Winkler, Tomas
2023-11-14 18:40 ` Winkler, Tomas
2023-11-15 20:35 ` Ville Syrjälä [this message]
2023-11-15 20:35 ` Ville Syrjälä
2023-11-27 13:22 ` [Intel-gfx] " Ville Syrjälä
2023-11-27 13:31 ` gregkh
2023-11-27 13:31 ` gregkh
2023-11-15 13:31 ` Tvrtko Ursulin
2023-11-15 15:58 ` Teres Alexis, Alan Previn
2023-11-15 15:58 ` Teres Alexis, Alan Previn
2023-10-11 11:01 ` [char-misc-next 4/4] mei: update mei-pxp's component interface with timeouts Tomas Winkler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZVUrhGsqJ9jKNM5x@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=alan.previn.teres.alexis@intel.com \
--cc=alexander.usyskin@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tomas.winkler@intel.com \
--cc=vitaly.lubart@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.