...@virtuousgeek.org]
Sent: Wednesday, May 08, 2013 7:19 AM
To: Jesse Barnes
Cc: intel-gfx@lists.freedesktop.org; Teres Alexis, Alan Previn
Subject: Re: [Intel-gfx] [PATCH] drm/i915: BIOS and power context stolen mem
handling for VLV v6
Alan, is this something your team can test since your BIOS
@lists.freedesktop.org; Cheah, Vincent Beng Keat;
Ung, Teng En; Teres Alexis, Alan Previn; Widawsky, Benjamin
Subject: Re: [Intel-gfx] intel-gpu-tools patches for read/write MMIO
On Tue, Jan 29, 2013 at 09:15:22PM +0100, Daniel Vetter wrote:
On 29/01/2013 21:01, Jesse Barnes wrote:
Can you just post them
on with our internal testing.
...alan
-Original Message-
From: Teres Alexis, Alan Previn
Hey folks,
Putting previous work aside, I have to agree with Ben about getting the user to
provide the absolute register offset - the adding of the 0x18 into the igt
tool patch below was based
On Fri, 2021-05-07 at 14:42 -0400, Rodrigo Vivi wrote:
> >
> On Fri, Apr 30, 2021 at 03:55:28PM +0300, Ville Syrjälä wrote:
> > On Fri, Apr 30, 2021 at 07:12:53AM +, Gupta, Anshuman wrote:
> > >
> > > > -Original Message-
> > > > From: Ville Syrjälä
> > > > Sent: Wednesday, April
On Mon, 2021-05-24 at 22:47 -0700, Daniele Ceraolo Spurio wrote:
> From: "Huang, Sean Z"
>
> Implement the funcs to create the TEE channel, so kernel can
> send the TEE commands directly to TEE for creating the arbitrary
> (default) session.
>
> v2: fix locking, don't pollute dev_priv (Chris)
>
I dont see any issues except a couple of nits.
Reviewed-by : Alan Previn
...alan
On Fri, 2021-08-27 at 18:27 -0700, Daniele Ceraolo Spurio wrote:
> 2 debugfs files, one to query the current status of the pxp session and one
> to trigger an invalidation for testing.
>
> Signed-off-by: Daniele
Reviewed-by: Alan Previn
..alan
On Fri, 2021-09-10 at 08:36 -0700, Daniele Ceraolo Spurio wrote:
> 2 debugfs files, one to query the current status of the pxp session and one
> to trigger an invalidation for testing.
>
> v2: rename debugfs, fix date (Alan)
>
> Signed-off-by: Daniele Ceraolo
On Thu, 2021-09-16 at 09:59 -0400, Rodrigo Vivi wrote:
> On Thu, Sep 16, 2021 at 02:06:56PM +0300, Jani Nikula wrote:
> > On Wed, 15 Sep 2021, Rodrigo Vivi wrote:
> > > On Wed, Sep 15, 2021 at 04:53:35PM +0300, Jani Nikula wrote:
> > > > On Fri, 10 Sep 2021, Daniele Ceraolo Spurio
> > > >
On Wed, 2021-09-22 at 15:56 -0700, Harish Chegondi wrote:
> On Tue, Sep 21, 2021 at 05:15:22PM -0700, Alan Previn wrote:
> > From: "Huang, Sean Z"
> >
> > Teardown is triggered when the display topology changes and no
> > long meets the secure playback requirement, and hardware trashes
> >
On Mon, 2021-09-20 at 12:04 -0400, Rodrigo Vivi wrote:
> On Fri, Sep 17, 2021 at 09:20:00PM -0700, Alan Previn wrote:
> > From: "Huang, Sean Z"
> >
> > The HW will generate a teardown interrupt when session termination is
> > required, which requires i915 to submit a terminating batch. Once the
On Mon, 2021-09-20 at 12:09 -0400, Rodrigo Vivi wrote:
> On Fri, Sep 17, 2021 at 09:20:01PM -0700, Alan Previn wrote:
> > From: Daniele Ceraolo Spurio
> >
> > This api allow user mode to create protected buffers and to mark
> > contexts as making use of such objects. Only when using contexts
>
I forgot to add the RVB that Rodrigo provided for this patch at Rev7.
Adding in reply for pw pickup:
Reviewed-by: Rodrigo Vivi
On Tue, 2021-09-21 at 17:15 -0700, Alan Previn wrote:
> From: "Huang, Sean Z"
>
> During the power event S3+ sleep/resume, hardware will lose all the
> encryption
On Fri, 2021-12-24 at 12:09 +, Tvrtko Ursulin wrote:
> Hi,
>
> Somehow I stumbled on this while browsing through the mailing list.
>
> On 23/12/2021 18:54, Teres Alexis, Alan Previn wrote:
> > Revisiting below hunk of patch-7 comment, as per offline disc
On Tue, 2022-01-04 at 13:56 +, Tvrtko Ursulin wrote:
>
> > The flow of events are as below:
> >
> > 1. guc sends notification that an error capture was done and ready to take.
> > - at this point we copy the guc error captured dump into an interim
> > store
> > (larger buffer
ST_INDEX_PF = 0,
> GUC_CAPTURE_LIST_INDEX_VF = 1,
> GUC_CAPTURE_LIST_INDEX_MAX = 2,
s/INDEX/OWNER ?
-Original Message-
From: Wajdeczko, Michal
Sent: Tuesday, November 23, 2021 1:47 PM
To: Teres Alexis, Alan Previn ;
intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [RFC 2/7]
Hi Michal - wrt to this comment:
+struct intel_guc;
> > > +
> > > +struct __guc_mmio_reg_descr {
> > > + i915_reg_t reg;
> > > + u32 flags;
> > > + u32 mask;
> > > + char *regname;
> >
> > const char* ?
> >
> > but maybe instead of adding reg name to the GuC specific struct we
> > should add
Michal, wrt this one:
+/ FIXME: Populate tables for other devices in subsequent patch
/
> > > +
> > > +static struct __guc_mmio_reg_descr_group *
> > > +guc_capture_get_device_reglist(struct drm_i915_private *dev_priv)
> >
> > in new code we are using "i915" instead of
Revisiting below hunk of patch-7 comment, as per offline discussion with Matt,
there is little benefit to even making that guc-id lookup because:
1. the delay between the context reset notification (when the vmas are copied
and when we verify we had received a guc err capture dump) may be
, Alan Previn
Sent: Monday, November 22, 2021 3:04 PM
To: intel-gfx@lists.freedesktop.org
Cc: Teres Alexis, Alan Previn
Subject: [RFC 7/7] drm/i915/guc: Print the GuC error capture output register
list.
Print the GuC captured error state register list (offsets and values) when
Hey Matt, apologies for the delay, went thru all the code, LGTM.
Reviewed-by: Alan Previn
P.S. - As a side note, would be interesting to replay the original reason
behind the overloading of the
func ptr bits to begin with... to see what the initial intention was.
...alan
On Wed, 2021-09-22
Thanks Michal for the thorough review of the code (and the other patches). I
will fix them all.
On the register-to-string helper function,
i'll have to think it through because i do want to keep future development
maintenance work when adding new registers simple (in the sense that
adding a
Thanks very much Jani for the detail review of the code... apologies on some of
the styling mishaps.
I will fix them all. I agree completely with the header file comments - my bad
on that - had already
learnt that lesson on pxp side. Will fix accordingly.
...alan
On Wed, 2021-11-24 at 12:06
Good catch - i missed that. Will fix it. Thanks again.
...alan
On Wed, 2021-11-24 at 12:08 +0200, Jani Nikula wrote:
> On Mon, 22 Nov 2021, Alan Previn wrote:
> > Add GuC's error capture output structures and definitions as how
> > they would appear in GuC log buffer's error capture subregion
Thanks Michal for reviewing the code. I will get all of these fixed.
I still would like continue to have a first patch with a skeleton table of
registers
as the patch that focuses on the infrastructure and another patch just for the
registers.
That sad, to align with your review comments, i
Thanks for the conditional Rvb - will get that fixed on next rev.
On Tue, 2021-12-07 at 13:01 -0800, Matthew Brost wrote:
> On Mon, Nov 22, 2021 at 03:03:59PM -0800, Alan Previn wrote:
> >
> >
> > +struct intel_guc_capture_out_data_header {
> > + u32 reserved1;
> > + u32 info;
> > +
Thank you for the detailed review Matt. Responses and follow up questions on
some of them below (wanna
make sure i dont misunderstand).
Will fix all the rest - glad we dont have any design problems .. so far :)
...alan
On Tue, 2021-12-07 at 14:31 -0800, Matthew Brost wrote:
> On Mon, Nov 22,
Thanks again for the detailed review here.
Will fix all the rest on next rev.
One special response for this one:
On Tue, 2021-12-07 at 16:22 -0800, Matthew Brost wrote:
> On Mon, Nov 22, 2021 at 03:04:02PM -0800, Alan Previn wrote:
> > + if (datatype ==
Thanks Matt for reviewing. Responses to the questions you had.
will fix the rest on next rev.
> > @@ -4013,10 +4016,11 @@ int intel_guc_error_capture_process_msg(struct
> > intel_guc *guc,
> > return -EPROTO;
> > }
> >
> > - status = msg[0];
> > -
After chatting offline with Matt, it became apparent that
i somehow missed the fact that the ctb processing handler
was already in a work queue. That said, Matt is correct, i
dont need to create a work queue to extract that capture
log into the interim-store. That would eliminate the race
I missed responding to this.
Thanks for the review Michal - will fix them on next rev.
...alan
On Tue, 2021-11-23 at 22:12 +0100, Michal Wajdeczko wrote:
>
> On 23.11.2021 00:03, Alan Previn wrote:
> > From: John Harrison
> ...
>
> > diff --git
On Fri, 2022-01-07 at 09:03 +, Tvrtko Ursulin wrote:
> On 06/01/2022 18:33, Teres Alexis, Alan Previn wrote:
> > On Thu, 2022-01-06 at 09:38 +, Tvrtko Ursulin wrote:
> > > On 05/01/2022 17:30, Teres Alexis, Alan Previn wrote:
> > > > On Tue, 2022-01-04 at 13:
some task IRQs.
...alan
-Original Message-
From: Tvrtko Ursulin
Sent: Tuesday, January 11, 2022 2:09 AM
To: Teres Alexis, Alan Previn ; Brost,
Matthew
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [RFC 7/7] drm/i915/guc: Print the GuC error capture
output register list.
On 10/01
On Mon, 2022-01-10 at 08:07 +, Tvrtko Ursulin wrote:
> On 07/01/2022 17:03, Teres Alexis, Alan Previn wrote:
> > On Fri, 2022-01-07 at 09:03 +, Tvrtko Ursulin wrote:
> > > On 06/01/2022 18:33, Teres Alexis, Alan Previn wrote:
> > > > On Thu, 2022-01-06 at 09:
In RFC rev2, Matt Brost requested for a comparison of the error capture from
execlist vs guc-capture.
I've added that data into the following links:
gem_exec_capture_errordump_ADLS_execlist : https://pastebin.com/RBwkHFNq
gem_exec_capture_errordump_ADLS_gucsubmission:
Looks like trying to move the vma up into guc-upper is impacting many other
functions
in intel_guc_log and intel_guc_log_debugfs. I'll have to take it back (the
level of
redesign i shall attempt with this series).
I'll just move the log_stats back into intel_guc_log and have intel_guc_capture
Thanks Umesh for reviewing the patch.
Am fixing all the rest but a couple of comments.
Responses to the latter and other questions below:
...alan
> > +enum intel_guc_state_capture_event_status {
> > + INTEL_GUC_STATE_CAPTURE_EVENT_STATUS_SUCCESS = 0x0,
> > +
On this specific question.
On Fri, 2022-02-04 at 17:28 -0800, Umesh Nerlige Ramappa wrote:
> On Wed, Jan 26, 2022 at 02:48:15AM -0800, Alan Previn wrote:
> > Add additional DG2 registers for GuC error state capture.
> >
> > + num_steer_regs = ARRAY_SIZE(xelpd_extregs);
> > + if (ipver >=
On 3/9/2022 9:30 PM, Matthew Brost wrote:
On Sat, Feb 26, 2022 at 01:55:29AM -0800, Alan Previn wrote:
+intel_guc_capture_getlist(struct intel_guc *guc, u32 owner, u32 type,
u32 classid,
+ struct file **fileoutptr)
+{
+ struct __guc_state_capture_priv *gc =
Thanks for reviewing Matt.. On one specific open - have replied below.
Will fix the others.
...alan
On 3/9/2022 9:30 PM, Matthew Brost wrote:
On Sat, Feb 26, 2022 at 01:55:29AM -0800, Alan Previn wrote:
+static int
+guc_capture_prep_lists(struct intel_guc *guc)
{
+ struct intel_gt
Thanks for reviewing and for the Rvb Umesh. ... will fix
guc_capture_alloc_one_node as per below.
...alan
On 3/11/2022 11:40 AM, Umesh Nerlige Ramappa wrote:
On Sat, Feb 26, 2022 at 01:55:39AM -0800, Alan Previn wrote:
In the rare but possible scenario where we are in the midst of
multiple
Thanks Umesh for reviewing and for the conditional Rb ... a follow up
on the conditions for #1 below (as per our offline conversation)... and
i will fix #2 as expected.
On 3/11/2022 10:16 AM, Umesh Nerlige Ramappa wrote:
On Sat, Feb 26, 2022 at 01:55:38AM -0800, Alan Previn wrote: +static
I shall fix the length line warnings.
However i shall not fix the " WARNING:OOM_MESSAGE: Possible unnecessary
'out of memory' message" warnings for reasons as stated because the
caller function is not reporting the OOM error and because if such an
error occurs, the ADS function that populates
i missed something in rev3, but rev4 ended up as a different series.
Please review this new URL for this patch. Apologies for the confusion:
https://patchwork.freedesktop.org/series/101256/
...alan
On 3/9/2022 5:45 PM, Teres Alexis, Alan Previn wrote:
On 3/9/2022 5:18 PM, John Harrison
Folks, rev'd to version 4 but patchworks generated a new series:
https://patchwork.freedesktop.org/series/101256/ (BAT passed and all).
John, hoping for an RVB on that newer URL and your help to merge if its
good.
...alan
On 3/10/2022 4:31 PM, Alan Previn wrote:
Fix our pointer offset
Thanks Matt! :)
On 3/15/2022 8:17 AM, Matthew Brost wrote:
On Mon, Mar 14, 2022 at 10:09:42AM -0700, Alan Previn wrote:
Update GuC ADS size allocation to include space for
the lists of error state capture register descriptors.
Then, populate GuC ADS with the lists of registers we want
GuC to
This is an actual bug I missed - will fix this - would cause a
compilation error when enabling "CONFIG_DRM_I915_DEBUG_GUC"
On 3/14/2022 7:26 PM, kernel test robot wrote:
Hi Alan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[cannot apply to
On 3/1/2022 1:37 PM, John Harrison wrote:
On 2/25/2022 22:27, Alan Previn wrote:
...
This fixes a kernel page fault can happen when
multiple tests are running concurrently in a loop
and one is producing engine resets and consuming
the i915 error_state dump while the other is
forcing full GT
On 3/9/2022 5:18 PM, John Harrison wrote:
On 3/8/2022 11:47, Teres Alexis, Alan Previn wrote:
On 3/1/2022 1:37 PM, John Harrison wrote:
On 2/25/2022 22:27, Alan Previn wrote:
...
This fixes a kernel page fault can happen when
multiple tests are running concurrently in a loop
and one
13, 2022 at 11:47:00AM -0800, Teres Alexis, Alan Previn
wrote:
Thanks Umesh for reviewing the patch.
Am fixing all the rest but a couple of comments.
Responses to the latter and other questions below:
...alan
> +enum intel_guc_state_capture_event_
Thanks Umesh for reviewing this for me and for the R-v-b.
Responding on one comment below
On Thu, 2022-02-10 at 18:11 -0800, Umesh Nerlige Ramappa wrote:
> On Wed, Jan 26, 2022 at 02:48:20AM -0800, Alan Previn wrote:
> > Add a flags parameter through all of the coredump creation
> > functions.
On Thu, 2022-02-10 at 18:11 -0800, Umesh Nerlige Ramappa wrote:
> On Wed, Jan 26, 2022 at 02:48:20AM -0800, Alan Previn wrote:
> > Add a flags parameter through all of the coredump creation
> > functions. Add a bitmask flag to indicate if the top
> > level gpu_coredump event is triggered in
Matt, just a final confirmation on below
> > > > >
> > > > > On Fri, 2022-02-04 at 10:19 -0800, Matthew Brost wrote:
> > > > > > On Wed, Jan 26, 2022 at 02:48:18AM -0800, Alan Previn wrote:
> > > > > > >
> > If the object lives at the GuC level, operate on it at the GuC level.
> >
> > e.g.
> >
On 2/26/2022 1:55 AM, Alan Previn wrote:
-static void guc_capture_list_init(struct intel_guc *guc)
+static int
+guc_capture_prep_lists(struct intel_guc *guc)
{
...
- /* FIXME: Populate a proper capture list */
+ /* first, set aside the first page for a capture_list with zero
WRT below, i believe this failure is unrelated due to the following reasons:
1. GuC submission wasn't enabled on below IGT (see bootlog:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22607/shard-iclb2/boot11.txt)
2. The failure was coming from a KMD plane scaling IGT and based on the
Apologies, please ignore last reply (wrestling with my VNC). Proper reply:
On Thu, 2022-02-03 at 12:39 -0800, Alan Previn Teres Alexis wrote:
>
>
> On Thu, 2022-02-03 at 12:04 -0800, Lucas De Marchi wrote:
> > On Thu, Feb 03, 2022 at 11:03:24AM -0800, Matthew Brost wrote:
> > > On Wed, Jan 26,
I can refactor my code to enforce an owner module to only return the size and
an interim
buffer pointer (kzalloc, not io mem) and have ADS memcpy from that pointer into
the ADS
substructure pointer..
But I hope we can make it a rule that its okay for an external owner-module to
know and
So we are coming to an agreement... I will go with the option
of ADS calling intel_guc_capture and asking it for the temp buf ptr and
size and let ADS do the actual copying. I will have to see how straight
forward the copying will be (if u see RFC-rev1 of this series, the ADS
does the full
Squash will be much easier if i also squash all the prior register table
additions together
Should i do that? Squash XeLP + DG2 + Gen9 and this together?
On Thu, 2022-02-03 at 11:09 -0800, Matthew Brost wrote:
> On Wed, Jan 26, 2022 at 02:48:21AM -0800, Alan Previn wrote:
> > Before we print the
Facepalming myself - yes you're right - that's an easy fix...
move the device specific ext-list into the guc_capture_priv structure
which is allocated per gt.
Thanks Jani.
...alan
On Thu, 2022-01-27 at 11:30 +0200, Jani Nikula wrote:
> On Wed, 26 Jan 2022, "Teres Alexis, Ala
As per the rev 5 CI results between this patch and patch7, i have introduced a
lockdep splat bug, i shall fix that in
the next rev.
...alan
On Wed, 2022-01-26 at 02:48 -0800, Alan Previn wrote:
> GuC log buffer regions for debug-log-events, crash-dumps and
> error-state-capture are all a single
Hi Matt, thank you for taking the time to review the codes.
Answering your question inline below.
On Fri, 2022-02-04 at 10:19 -0800, Matthew Brost wrote:
> On Wed, Jan 26, 2022 at 02:48:18AM -0800, Alan Previn wrote:
> > GuC log buffer regions for debug-log-events, crash-dumps and
> >
On Tue, 2022-02-08 at 14:18 -0800, Matthew Brost wrote:
> On Tue, Feb 08, 2022 at 11:38:13AM -0800, Teres Alexis, Alan Previn wrote:
> > Hi Matt, thank you for taking the time to review the codes.
> > Answering your question inline below.
> >
> >
> > On Fri, 2
On Tue, 2022-02-08 at 19:34 -0800, Matthew Brost wrote:
> On Tue, Feb 08, 2022 at 02:55:07PM -0800, Teres Alexis, Alan Previn wrote:
> > On Tue, 2022-02-08 at 14:18 -0800, Matthew Brost wrote:
> > > On Tue, Feb 08, 2022 at 11:38:13AM -0800, Teres Alexis, Alan Previn wrote:
>
Apologies for the delayed response. I totally agree with the
lpd vs hpg function separation. Thats what i initially implemented
but when cross-referencing my logic with the execlist i realized
DG2 steering registers for all Gens were in the same function so
I thought of keeping it consistent but i
A fresh round of offline design discussions with internal team has decided
that:
- we dont want to use an interim circular buffer to copy all of the GuC
generated register dumps of one or more 'engine-capture-groups'.
- instead, we shall dynamically allocate multiple nodes, each node being
Spurio, Daniele
; Summers, Stuart ;
Harrison, John C ; Teres Alexis, Alan Previn
Subject: [PATCH] drm/i915/wopcm: Handle pre-programmed WOPCM registers
Starting from DG2, some of the programming previously done by i915 and the GuC
has been moved to the GSC and the relevant registers
Reviewed-by: Alan Previn
On Mon, 2022-01-10 at 17:55 -0800, Umesh Nerlige Ramappa wrote:
> All timestamps returned by GuC for GuC PMU busyness are captured from
> GUC PM TIMESTAMP. Since this timestamp does not tick when GuC goes idle,
> kmd uses RING_TIMESTAMP to measure busyness of an engine
On Thu, 2022-01-06 at 09:38 +, Tvrtko Ursulin wrote:
> On 05/01/2022 17:30, Teres Alexis, Alan Previn wrote:
> > On Tue, 2022-01-04 at 13:56 +, Tvrtko Ursulin wrote:
> > > > The flow of events are as below:
> > > >
> > > > 1. guc send
Internal feedback is to exactly match the register dumps
output as it did in execlist, however it seems that the
register dump function in execlist targetting the GT subsystem
also includes non-GT registers like display-related ones that
GuC doesn't manage. So for that, I will have to break up
Thanks Jani for taking the time to review...
1. apologies on the const issue, this is my bad, i think it was
one of the comments from earlier rev not sure how i missed it.
Will fix this on next rev.
2. I do have a question below on the const for one of specific types
of tables. Need your
Thanks for the offline run through of all the corner
cases we are trying to handle through below codes.
Reviewed-by: Alan Previn
...alan
On Mon, 2022-01-24 at 18:01 -0800, Umesh Nerlige Ramappa wrote:
> GuC updates shared memory and KMD reads it. Since this is not
> synchronized, we run
On Wed, 2023-09-06 at 17:15 -0700, Teres Alexis, Alan Previn wrote:
> Update the GSC-fw input/output HECI packet size to match
> updated internal fw specs.
alan:snip
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
> @@ -14,8 +14,8 @@
>
> +/* PXP-Packet sizes fo
On Sat, 2023-09-09 at 15:38 -0700, Teres Alexis, Alan Previn wrote:
> Update the GSC-fw input/output HECI packet size to match
> updated internal fw specs.
>
> Signed-off-by: Alan Previn
> ---
> drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h | 4 ++--
> 1 file change
On Sat, 2023-09-09 at 15:38 -0700, Teres Alexis, Alan Previn wrote:
> Update the GSC-fw input/output HECI packet size to match
> updated internal fw specs.
>
> Signed-off-by: Alan Previn
>
alan:snip
> -/* PXP-Packet sizes for MTL's GSCCS-HECI instruction */
> -#define PXP4
On Fri, 2023-09-15 at 13:15 -0700, Teres Alexis, Alan Previn wrote:
> Debugging PXP issues can't even begin without understanding precedding
> sequence of important events. Add drm_dbg into the most important PXP events.
>
> v3 : - move gt_dbg to after mutex block
On Sat, 2023-09-09 at 15:38 -0700, Teres Alexis, Alan Previn wrote:
> Update the max GSC-fw response time to match updated internal
> fw specs. Because this response time is an SLA on the firmware,
> not inclusive of i915->GuC->HW handoff latency, when submitting
> requests
On Sat, 2023-09-09 at 15:38 -0700, Teres Alexis, Alan Previn wrote:
> Update the max GSC-fw response time to match updated internal
> fw specs. Because this response time is an SLA on the firmware,
> not inclusive of i915->GuC->HW handoff latency, when submitting
> requests
On Sat, 2023-09-09 at 15:38 -0700, Teres Alexis, Alan Previn wrote:
> On Meteorlake onwards, HW specs require that all user contexts that
> run on render or compute engines and require PXP must enforce
> run-alone bit in lrc. Add this enforcement for protected contexts.
alan:snip
>
On Sat, 2023-09-16 at 10:25 +0800, lkp wrote:
> Hi Alan,
>
> kernel test robot noticed the following build errors:
>
> [auto build test ERROR on cf1e91e884bb1113c653e654e9de1754fc1d4488]
>
> aAll errors (new ones prefixed by >>):
>
>
alan:snip
alan: missed building with PXP config after that
I went up the call stack to ensure the differences between the
old and new location isnt skipping over other functions that may reference
something engine related (that may also end up triggering stats variabls).
Without digging further, i see the old postion here:
i915_driver_probe ->
On Mon, 2023-09-11 at 12:26 +0300, Jani Nikula wrote:
> On Wed, 06 Sep 2023, Alan Previn wrote:
> > Debugging PXP issues can't even begin without understanding precedding
> > sequence of events. Add drm_dbg into the most important PXP events.
> >
> > Signed-off-by: Alan Previn
alan:snip
>
> >
On Fri, 2023-10-27 at 10:13 +0300, Jani Nikula wrote:
> On Thu, 26 Oct 2023, Zhanjun Dong wrote:
>
alan:snip
> I'll note that nobody checks intel_pxp_init() return status, so this
> silently skips PXP.
>
> BR,
> Jani.
alan:snip
> > + if (intel_gt_is_wedged(gt))
> > + return
(cc Anshuman who is working directly with the taskforce debugging this)
Thanks again for taking the time to review this patch.
Apologies for the tardiness, rest assured debug is still ongoing.
As mentioned in prior comments, the signatures and frequency are
now different compared to without the
On Thu, 2023-09-14 at 11:35 -0400, Vivi, Rodrigo wrote:
> On Sat, Sep 09, 2023 at 08:58:44PM -0700, Alan Previn wrote:
> > When suspending, flush the context-guc-id
> > deregistration worker at the final stages of
> > intel_gt_suspend_late when we finally call gt_sanitize
> > that eventually leads
On Sun, 2023-09-17 at 22:04 +, Patchwork wrote:
> Patch Details
> Series: drm/i915/pxp/mtl: Update gsc-heci cmd submission to align with fw/hw
> spec
> URL:https://patchwork.freedesktop.org/series/123830/
>
alan:snip
Below issue it unrelated since this series only changes code paths in
Thanks for taking the time to review this Tvrtko, replies inline below.
On Wed, 2023-09-27 at 10:02 +0100, Tvrtko Ursulin wrote:
> On 26/09/2023 20:05, Alan Previn wrote:
> > When suspending, add a timeout when calling
> > intel_gt_pm_wait_for_idle else if we have a lost
> > G2H event that holds
On Wed, 2023-10-04 at 06:34 +, Gupta, Anshuman wrote:
>
> > -Original Message-
> > From: Teres Alexis, Alan Previn > @@ -289,6 +289,13 @@ int intel_gt_resume(struct intel_gt *gt)
> >
> > static void wait_for_suspend(struct intel_gt *gt) {
> >
On Thu, 2023-09-28 at 13:46 +0100, Tvrtko Ursulin wrote:
> On 27/09/2023 17:36, Teres Alexis, Alan Previn wrote:
> > Thanks for taking the time to review this Tvrtko, replies inline below.
alan:snip
> > >
> > > Main concern is that we need to be sure there are no possi
>
> > alan:snip
> > > > @@ -3279,6 +3322,17 @@ static void destroyed_worker_func(struct
> > work_struct *w)
> > > > struct intel_gt *gt = guc_to_gt(guc);
> > > > int tmp;
> > > >
> > > > + /*
> > > > +* In rare cases we can get here via async context-free
> > > >
On Thu, 2023-09-14 at 11:34 -0400, Vivi, Rodrigo wrote:
> On Sat, Sep 09, 2023 at 08:58:45PM -0700, Alan Previn wrote:
alan:snip
>
> > + /* Change context state to destroyed and get gt-pm */
> > + __intel_gt_pm_get(gt);
> > + set_context_destroyed(ce);
> > + clr_context_registered(ce);
>
On Sat, 2023-09-16 at 03:09 +, Patchwork wrote:
>
alan:snip
> 2eab9e4e637a drm/i915/pxp: Add drm_dbgs for critical PXP events.
> -:7: WARNING:COMMIT_LOG_LONG_LINE: Prefer a maximum 75 chars per line
> (possible unwrapped commit description?)
> #7:
> sequence of important events. Add drm_dbg
>
> > Rodrigo: And why here and not some upper layer? like in prepare
> alan: wait_for_suspend does both the checking for idle as well as the
> potential
> wedging if guc or hw has hung at this late state. if i call from the upper
> layer before this wait_for_suspend, it might be too early
On Mon, 2023-08-14 at 18:12 -0700, Teres Alexis, Alan Previn wrote:
> This series is the result of debugging issues root caused to
> races between the GuC's destroyed_worker_func being triggered
> vs repeating suspend-resume cycles with concurrent delayed
> fence signals for engine-f
Thanks again Rodrigo for reviewing and apologies for my tardy replies.
We are stil testing on shipping platforms and these latest patches seemed
to have reduced the frequency and solved the "system hangs" while suspending
but its still causing issues so we continue to debug. (issue is that
its
just a follow up note-to-self:
On Tue, 2023-08-15 at 12:08 -0700, Teres Alexis, Alan Previn wrote:
> On Tue, 2023-08-15 at 09:56 -0400, Vivi, Rodrigo wrote:
> > On Mon, Aug 14, 2023 at 06:12:09PM -0700, Alan Previn wrote:
> > >
[snip]
in guc_submission_send_busy_loop, w
Thanks Rodrigo - agreed on everything below - will re-rev.
On Tue, 2023-08-15 at 09:51 -0400, Vivi, Rodrigo wrote:
> On Mon, Aug 14, 2023 at 06:12:10PM -0700, Alan Previn wrote:
> > When suspending, add a timeout when calling
> > intel_gt_pm_wait_for_idle else if we have a lost
> > G2H event that
On Tue, 2023-08-15 at 09:56 -0400, Vivi, Rodrigo wrote:
> On Mon, Aug 14, 2023 at 06:12:09PM -0700, Alan Previn wrote:
> > If we are at the end of suspend or very early in resume
> > its possible an async fence signal could lead us to the
> > execution of the context destruction worker (after the
On Tue, 2023-08-15 at 13:29 -0700, Teres Alexis, Alan Previn wrote:
> Update the max GSC-fw response time to match updated internal
> fw specs. Because this response time is an SLA on the firmware,
> not inclusive of i915->GuC->HW handoff latency, when submitting
> requests
the worker when !intel_guc_is_ready
(ct-is-disabled).
...alan
On Fri, 2023-08-25 at 11:54 -0700, Teres Alexis, Alan Previn wrote:
> just a follow up note-to-self:
>
> On Tue, 2023-08-15 at 12:08 -0700, Teres Alexis, Alan Previn wrote:
> > On Tue, 2023-08-15 at 09:56 -0400, Vivi, Ro
I'm confident that the below regression is not a regression that resulted from
the code change of this series.
The changes i made removes debug messages that are only executed at the GuC-ADS
preparation time
and is never being executed at runtime. Also, the code changes had nothing to
do with
1 - 100 of 409 matches
Mail list logo
