disabled) but instead called
guc_context_sched_disable (no underscore) causing an
infinite loop for mid-disabling.
...alan
On Fri, 2022-08-19 at 16:47 +, Teres Alexis, Alan Previn wrote:
> Will look into this - apologies for the trouble Matt.
> ...alan
>
> -Original Message
Will look into this - apologies for the trouble Matt.
...alan
-Original Message-
From: Harrison, John C
Sent: Friday, August 19, 2022 8:46 AM
To: Auld, Matthew ; intel-gfx@lists.freedesktop.org
Cc: Brost, Matthew ; Teres Alexis, Alan Previn
Subject: Re: [PATCH] Revert "drm/i91
On Tue, 2022-08-16 at 15:45 -0700, Harrison, John C wrote:
> On 8/15/2022 19:17, Alan Previn wrote:
> > From: Matthew Brost
> >
> > Add a delay, configurable via debugfs (default 34ms), to disable
> > (default is 3/4) of the guc_ids.
> are in use.
>
my bad - got clipped - will fix.
> > --- a/d
Hmmm - i guess I've been it wrong all the while (been using the same script for
a while).
Will fix - thanks
...alan
On Mon, 2022-08-15 at 15:40 -0700, Harrison, John C wrote:
> On 8/15/2022 09:01, Alan Previn wrote:
> > From: Matthew Brost
> >
> > This will help in an upcoming patch where the
Shall fix all of the cosmetics and repost.
WRT the magic number 34 milisecs: It was to have a "1 milisec buffer over a
33-fps" type workload which was how the
issue was found in the first place (it was a workload that had hundreds of
these 33-fps contexts running and thats why
the impact was gre
Looks good to me.
Reviewed-by: Alan Previn
On Wed, 2022-07-27 at 19:20 -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The GuC log buffer sizes had to be configured statically at compile
> time. This can be quite troublesome when needing to get larger logs
> out of a releas
Sounds good - thanks. (ignore the "doing the opposite" comment).
Reviewed-by: Alan Previn
On Mon, 2022-08-08 at 11:43 -0700, Harrison, John C wrote:
> On 8/4/2022 17:40, Teres Alexis, Alan Previn wrote:
> > I have a question on below code. Everything else looked good.
> &g
I have a question on below code. Everything else looked good.
Will r-b as soon as we can close on below question
...alan
On Wed, 2022-07-27 at 19:20 -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> It is useful to be able to match GuC events to kernel events when
> looking at t
I was informed by Daniele that the MEI team had done the functional reviews as
part of their differentiated "Signed-of-
by" process and so i was asked to only do a at the surface code-syntax /
code-structure review.
That said i did find one issue farther below.
I'm also compelled to add the fo
Reviewed-by: Alan Previn
On Wed, 2022-07-27 at 19:20 -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Some debug code got left in when the GuC based register save for error
> capture was added. Remove that.
>
> Signed-off-by: John Harrison
> ---
> .../gpu/drm/i915/gt/uc/int
One concern below. Else, nice, simple yet good optimization here. :)
In the interest of quicker progression, I will provide a conditional R-B if you
can either fix the issue raised below on
the way in or provide a reason why that's not an issue:
Reviewed-by: Alan Previn
On Wed, 2022-07-27 at 1
One minor NIT (though i hope it could be fixed otw in as it adds a bit of
ease-of-log-readibility).
That said, everything else looks good.
Reviewed-by: Alan Previn
On Wed, 2022-07-27 at 19:20 -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> When debugging GuC communication i
Straight forward change - LGTM.
Reviewed-by: Alan Previn
On Wed, 2022-07-27 at 19:20 -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> There was a size check to warn if the GuC error state capture buffer
> allocation would be too small to fit a reasonable amount of capture
>
Something minor in comments, so conditional R-B (please fix on the way in or
reply to correct me):
Reviewed-by: Alan Previn
On Wed, 2022-07-27 at 19:20 -0700, Harrison, John C wrote:
> From: Alan Previn
>
> Add a helper to get GuC log buffer size.
>
> Signed-off-by: Alan Previn
> Signed-off
Looks good, just a minor nit.
Reviewed-by: Alan Previn
On Wed, 2022-07-06 at 14:43 +0300, Alexander Usyskin wrote:
> From: Tomas Winkler
>
> GSC requires more operational memory than available on chip.
> Reserve 4M of LMEM for GSC operation. The memory is provided to the
> GSC as struct resou
code looks in order and this patch hasnt too much meat to it anyways.
I have 1 question but its not pertaining to the code but rather to the backend
firmware expectation, see below:
On Thu, 2022-06-09 at 16:19 -0700, Ceraolo Spurio, Daniele wrote:
> From: Vitaly Lubart
>
> Adding command stream
On Thu, 2022-06-09 at 16:19 -0700, Ceraolo Spurio, Daniele wrote:
> From: Tomas Winkler
>
> Support matching with a discrete graphics card.
>
> Signed-off-by: Tomas Winkler
> Cc: Vitaly Lubart
> ---
> drivers/misc/mei/pxp/mei_pxp.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 de
All looks good:
Reviewed-by: Alan Previn
On Thu, 2022-06-09 at 16:19 -0700, Ceraolo Spurio, Daniele wrote:
> Wait on the fence to be signalled to avoid the submissions finding HuC
> not yet loaded.
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Tony Ye
> ---
> drivers/gpu/drm/i915/gt/uc/int
On Thu, 2022-06-09 at 16:19 -0700, Ceraolo Spurio, Daniele wrote:
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> index 075ec97b459d..33bfac91fa01 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.
Other than the one nit below, everything looks in order as per internal
development and reviews...
but really wish we had the nit added - so we have a single location we can
build on to get all
the various stages of gsc vs pxp vs huc operation sequences across hw gens (at
least the first
gen wh
LGTM.
Reviewed-by: Alan Previn
On Thu, 2022-06-09 at 16:19 -0700, Ceraolo Spurio, Daniele wrote:
> intel_huc_wait_for_auth_complete
WRT possible new issues below, the patches i made does not impact any display
or even execution operation.
Unfortunately, i cant seem to access the "possible regression" failure below.
Additionally, GuC is not supported on SKL.
thus we can safely ignore these.
On Mon, 2022-06-27 at 12:47 +,
> > + /**
> > +* @last_jiffies: jiffies at last actual stats collection time
> > +* We use this timestamp to ensure we don't oversample the
> > +* stats because runtime power management events can trigger
> > +* stats collection at much hi
Thanks Umesh. As per offline - i will address Tvrtko's comments too.
...alan
On Wed, 2022-06-22 at 16:00 -0700, Nerlige Ramappa, Umesh wrote:
> On Fri, Jun 17, 2022 at 10:43:45PM -0700, Alan Previn wrote:
> > Using igt's gem-create and with additional patches to track object
> > creation time, it
Reviewed-by: Alan Previn
On Thu, 2022-06-09 at 16:19 -0700, Ceraolo Spurio, Daniele wrote:
> The fw name is different and we need to record the fact that the blob is
> gsc-loaded, so add a new macro to help.
>
> Note: A-step DG2 G10 does not support HuC loading via GSC and would
> require a sepa
Reviewed-by: Alan Previn
On Thu, 2022-06-09 at 16:19 -0700, Ceraolo Spurio, Daniele wrote:
> The fw name is different and we need to record the fact that the blob is
> gsc-loaded, so add a new macro to help.
>
> Note: A-step DG2 G10 does not support HuC loading via GSC and would
> require a sepa
Reviewed-by: Alan Previn
On 6/9/2022 4:19 PM, Ceraolo Spurio, Daniele wrote:
From: Tomas Winkler
Add support for loading HuC via a pxp stream command.
Signed-off-by: Tomas Winkler
Signed-off-by: Vitaly Lubart
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
---
drivers/gpu/drm/i91
Reviewed-by: Alan Previn
On Thu, 2022-06-09 at 16:19 -0700, Ceraolo Spurio, Daniele wrote:
> From: Vitaly Lubart
>
> Command to be sent via the stream interface are written to a local
> memory page, whose address is then provided to the GSC.
> The interface supports providing a full sg with mu
Reviewed-by: Alan Previn
On Thu, 2022-06-09 at 16:19 -0700, Ceraolo Spurio, Daniele wrote:
> The mei_pxp module is required to send the command to load authenticate
> the HuC to the GSC even if pxp is not in use for protected content
> management.
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc:
> > > Not updating the driver state in park will not negatively impact
> > > accuracy in some scenarios? That needs to balanced against the
> > > questions whether or not there are real world scenarios impacted by
> > > the update cost or it is just for IGT.
> >
If i understand it correctly (h
> Who did you find is doing the sampling in the real world use case? AFAIR
> if one one is querying busyness, I thought there would only be the GuC
> ping worker which runs extremely infrequently (to avoid some counter
> overflow).
>
> Regards,
>
> Tvrtko
>
> >
Hi Tvrtko, the case where we
Can't see anything wrong with this.
I consider this only a NIT, so feel : not sure if -ECANCELLED is reflective of
the "ct service being temporarily down"
as opposed to the "requester cancelling". Perhaps a -EPIPE or -EAGAIN (if we
got this far, we know we are probably mid-
reset) ?? (if not alre
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 po
Nit: not sure why we use ERR_PTR for int when calling func was also returning
an int.
Anyway, that was how the original code was, so:
Reviewed-by: Alan Previn
On Thu, 2022-05-05 at 22:41 -0700, Vinay Belgaumkar wrote:
> To avoid false positives in error injection cases.
>
> Signed-off-by: Vin
Looking through the log messages, all 4 failures below are not related to the
GuC relay logging change of this series. They are all display related.
Two of the failures were on SKL which doesn't have GuC enabled.
Interestingly, all 4 cases, carries multiple different test or subtest failures
but
Because i reviewed this already and the only new change is the relocation
of the function "huc_is_authenticated()" from Patch 1 to this patch while
maintaining the same logic as rev-1, thus:
Acked-by: Alan Previn
On Wed, 2022-05-04 at 13:48 -0700, Daniele Ceraolo Spurio wrote:
> HuC loading via
Reviewed-by: Alan Previn
On Wed, 2022-05-04 at 13:48 -0700, Daniele Ceraolo Spurio wrote:
> The fuction name is confusing, because it doesn't check the actual auth
> status in HW but the SW status. Given that there is only one user (the
> huc_auth function itself), just get rid of it and use the
Thanks Umesh for clarifying that question. With that, here is my rvb and
apologies for the tardiness.
Reviewed-by: Alan Previn
On Mon, 2022-05-02 at 13:07 -0700, Umesh Nerlige Ramappa wrote:
> On Thu, Apr 28, 2022 at 09:13:57AM -0700, Teres Alexis, Alan Previn wrote:
> > At a high le
Reviewed-by: Alan Previn
On Tue, 2022-04-26 at 17:26 -0700, Daniele Ceraolo Spurio wrote:
> HuC loading via GSC is performed via a PXP command sent through the mei
> modules, so we need both MEI_GSC and MEI_PXP to be available. Given that
> the GSC will do both the transfer and the authenticatio
minor nit: not sure if its worth mentioning in commit msg that "loaded_via_gsc"
is zero-init-ed as fw_def macros we havent added fw_defs for gsc-loaded-huc-bins
which explains why "loaded_via_gsc" not getting set anywhere in this series.
Reviewed-by: Alan Previn
On Tue, 2022-04-26 at 17:26 -070
At a high level, this change looks good and simple.
However, inside __guc_reset_context, i think there might be
an observed change in behavior for parallel submission.
(or perhaps this change is part the intent?):
Unless my understanding is incorrect, assuming a
parallel submission comes
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 dmesgs
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
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 drm
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 r
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 int
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 Gu
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 = guc->
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 *gt
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 usa
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
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 is
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 re
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
d
n Sun, Feb 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_capt
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
ha
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.
> >
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,
> > + INTEL_GUC_STATE_CAPTURE_EVENT_STAT
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 respon
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. Ad
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 >= IP_V
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
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:
>
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
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
> > error-state
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
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 populati
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, 2
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 define
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 A
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
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 though
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 int
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
the
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 wi
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 are no
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
lay - 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
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: https://pastebin.com/8k5p3kS
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:
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:
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 sends no
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 that
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 discussion with
&
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
subj
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 gen
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 "d
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 a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.
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
condition
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 == GUC_CAPTURE_LIST_TYPE_ENG
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];
> > - drm_info(&guc_to_gt(guc)->
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, 20
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 af
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 +0
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 singl
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 sha
lexis, 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)
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 a
301 - 400 of 412 matches
Mail list logo
