On 7/27/2021 02:49, Daniel Vetter wrote:
On Mon, Jul 26, 2021 at 07:21:43PM -0700, john.c.harri...@intel.com wrote:
From: John Harrison
Various UMDs require hardware configuration information about the
current platform. A bunch of static information is available in a
fixed table that can be
On 7/26/2021 17:23, Matthew Brost wrote:
Requests may take slightly longer with GuC submission, let's increase
the timeouts in live_requests.
Signed-off-by: Matthew Brost
Was already reviewed in previous series. Repeating here for patchwork:
Reviewed-by: John Harrison
---
drivers/gp
On 7/27/2021 11:20, Matthew Brost wrote:
With GuC submission contexts can get reordered (compared to submission
order), if contexts get reordered the sequential nature of the batches
releasing the next batch's semaphore in function timesliceN() get broken
resulting in the test taking much longer
On 7/28/2021 17:34, Matthew Brost wrote:
If an engine associated with a context does not have a heartbeat, ban it
immediately. This is needed for GuC submission as a idle pulse doesn't
kick the context off the hardware where it then can check for a
heartbeat and ban the context.
It's worse than t
On 7/30/2021 02:49, Tvrtko Ursulin wrote:
On 30/07/2021 01:13, John Harrison wrote:
On 7/28/2021 17:34, Matthew Brost wrote:
If an engine associated with a context does not have a heartbeat,
ban it
immediately. This is needed for GuC submission as a idle pulse doesn't
kick the context of
On 8/2/2021 02:40, Tvrtko Ursulin wrote:
On 30/07/2021 19:13, John Harrison wrote:
On 7/30/2021 02:49, Tvrtko Ursulin wrote:
On 30/07/2021 01:13, John Harrison wrote:
On 7/28/2021 17:34, Matthew Brost wrote:
If an engine associated with a context does not have a heartbeat,
ban it
immediately
On 7/30/2021 12:53, Matthew Brost wrote:
A small race exists between intel_gt_retire_requests_timeout and
intel_timeline_exit which could result in the syncmap not getting
free'd. Rather than work to hard to seal this race, simply cleanup the
free'd -> freed
syncmap on fini.
unreferenced obje
ding on gen12+ aside from TGL, RKL, and ADL_S not
allowed\n");
I would have said not supported rather than not allowed. Either way:
Reviewed-by: John Harrison
+ return -ENODEV;
+ }
+
if (get_user(idx, &ext->virtual_index))
return -EFAULT;
On 8/2/2021 22:11, Matthew Brost wrote:
From: Daniele Ceraolo Spurio
The firmware binary has to be loaded from lmem and the recommendation is
to put all other objects in there as well. Note that we don't fall back
to system memory if the allocation in lmem fails because all objects are
allocate
, 0, 0), huc_def(tgl, 7, 9, 3)) \
fw_def(JASPERLAKE, 0, guc_def(ehl, 62, 0, 0), huc_def(ehl, 9, 0, 0)) \
Reviewed-by: John Harrison
)) {
+ if (IS_ALDERLAKE_S(i915)) {
i915->params.enable_guc = ENABLE_GUC_LOAD_HUC;
return;
}
Reviewed-by: John Harrison
On 8/6/2021 11:29, Matthew Brost wrote:
On Fri, Aug 06, 2021 at 11:23:06AM -0700, John Harrison wrote:
On 7/30/2021 12:53, Matthew Brost wrote:
A small race exists between intel_gt_retire_requests_timeout and
intel_timeline_exit which could result in the syncmap not getting
free'd. Rather
On 8/6/2021 12:46, Daniel Vetter wrote:
Seen this fly by and figured I dropped a few thoughts in here. At the
likely cost of looking a bit out of whack :-)
On Fri, Aug 6, 2021 at 8:01 PM John Harrison wrote:
On 8/2/2021 02:40, Tvrtko Ursulin wrote:
On 30/07/2021 19:13, John Harrison wrote
On 5/26/2021 01:40, Tvrtko Ursulin wrote:
On 25/05/2021 18:52, Matthew Brost wrote:
On Tue, May 25, 2021 at 11:16:12AM +0100, Tvrtko Ursulin wrote:
On 06/05/2021 20:14, Matthew Brost wrote:
From: John Harrison
The serial number tracking of engines happens at the backend of
request
On 5/27/2021 01:53, Tvrtko Ursulin wrote:
On 26/05/2021 19:45, John Harrison wrote:
On 5/26/2021 01:40, Tvrtko Ursulin wrote:
On 25/05/2021 18:52, Matthew Brost wrote:
On Tue, May 25, 2021 at 11:16:12AM +0100, Tvrtko Ursulin wrote:
On 06/05/2021 20:14, Matthew Brost wrote:
From: John
AFAICT, none of these warnings are related to this patch set.
John.
On 5/25/2021 23:43, Patchwork wrote:
== Series Details ==
Series: Non-interface changing GuC CTBs updates (rev2)
URL : https://patchwork.freedesktop.org/series/90552/
State : warning
== Summary ==
$ dim sparse --fast orig
On 5/25/2021 23:42, Patchwork wrote:
== Series Details ==
Series: Non-interface changing GuC CTBs updates (rev2)
URL : https://patchwork.freedesktop.org/series/90552/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6b6bffd59ced drm/i915/guc: skip disabling CTBs before sanitizin
ases in a less catastrophic manner? Or are there
valid reasons for calling enable when already enabled?
Either way, it seems like a plausible change and CI is happy with it, so:
Reviewed-by: John Harrison
John.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/in
be necessary once
the CTBs are up and running. If mixing does occur in the future, it
sounds like something that should be addressed at the GuC architecture
level!
With the comment added:
Reviewed-by: John Harrison
+ } else {
+ wmb();
+ }
+}
+
/**
* DOC:
On 8/9/2021 23:38, Daniel Vetter wrote:
On Wed, Jul 28, 2021 at 05:33:59PM -0700, Matthew Brost wrote:
Should fix below failures with GuC submission for the following tests:
gem_exec_balancer --r noheartbeat
gem_ctx_persistence --r heartbeat-close
Not going to fix:
gem_ctx_persistence --r heart
On 8/9/2021 23:36, Daniel Vetter wrote:
On Mon, Aug 09, 2021 at 04:12:52PM -0700, John Harrison wrote:
On 8/6/2021 12:46, Daniel Vetter wrote:
Seen this fly by and figured I dropped a few thoughts in here. At the
likely cost of looking a bit out of whack :-)
On Fri, Aug 6, 2021 at 8:01 PM
On 7/26/2021 20:17, Matthew Brost wrote:
Like in the case of several other selftests, generating lots of requests
in a loop takes a bit longer with GuC submission. Increase a timeout in
i915_gem_contexts selftest to take this into account.
Signed-off-by: Matthew Brost
Reviewed-by: John
On 7/29/2021 17:00, Matthew Brost wrote:
On Thu, Jul 29, 2021 at 04:54:08PM -0700, John Harrison wrote:
On 7/27/2021 11:20, Matthew Brost wrote:
With GuC submission contexts can get reordered (compared to submission
order), if contexts get reordered the sequential nature of the batches
On 8/25/2021 20:23, Matthew Brost wrote:
When the GuC does a media reset, it copies a golden context state back
into the corrupted context's state. The address of the golden context
and the size of the engine state restore are passed in via the GuC ADS.
The i915 had a bug where it passed in the w
On 8/25/2021 20:23, Matthew Brost wrote:
Add GuC kernel doc for all structures added thus far for GuC submission
and update the main GuC submission section with the new interface
details.
v2:
- Drop guc_active.lock DOC
v3:
(Daniele)
- Fixup a few kernel doc comments
Signed-off-by: Matthew
Subject should be 'drop .. functions *from* intel...'.
On 8/25/2021 20:23, Matthew Brost wrote:
s/static inline/static/g + fix function argument alignment to make
checkpatch happy.
Why?
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 116 +
(Daniele)
v4 (Daniele):
- Implement doc suggestions from John
- Add kerneldoc for all members of the GuC structure and pull the file
in i915.rst
Signed-off-by: Matthew Brost
Signed-off-by: Daniele Ceraolo Spurio
Cc: John Harrison
---
Documentation/gpu/i915.rst| 2
const variables (John).
Fixes: 481d458caede ("drm/i915/guc: Add golden context to GuC ADS")
Signed-off-by: Matthew Brost
Signed-off-by: Daniele Ceraolo Spurio
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 26 ++
1 file changed, 17 insertions(+), 9 del
Fixes: f4eb1f3fe946 ("drm/i915/guc: Ensure G2H response has space in buffer")
Signed-off-by: Matthew Brost
Signed-off-by: Daniele Ceraolo Spurio
Cc:
Reviewed-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 79 +--
1 file changed, 37 insertions(+
(Daniele)
v4 (Daniele):
- Implement doc suggestions from John
- Add kerneldoc for all members of the GuC structure and pull the file
in i915.rst
v5 (Daniele):
- Implement new doc suggestions from John
Signed-off-by: Matthew Brost
Signed-off-by: Daniele Ceraolo Spurio
Cc: John Harrison
On 8/20/2021 15:44, Matthew Brost wrote:
Number of available GuC contexts ids might be limited.
Stop referring in code to macro and use variable instead.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 4
drivers/gpu
On 8/20/2021 15:44, Matthew Brost wrote:
For testing purposes it may make sense to reduce the number of guc_ids
available to be allocated. Add debugfs support for setting the number of
guc_ids.
Signed-off-by: Matthew Brost
It 'may make sense'? Is there an actual IGT/selftest test that uses this
On 8/20/2021 15:44, Matthew Brost wrote:
Taking a PM reference to prevent intel_gt_wait_for_idle from short
circuiting while a deregister context H2G is in flight.
FIXME: Move locking / structure changes into different patch
This split needs to be done. It would also be helpful to have a more
d
On 8/20/2021 15:44, Matthew Brost wrote:
Sometimes it is desirable to queue work up for later if the GT PM isn't
held and run that work on next GT PM unpark.
What is the reason for doing this? Why is it important? Why not just
take the GT PM at the time the work is requested?
Implemented wit
On 8/20/2021 15:44, Matthew Brost wrote:
Taking a PM reference to prevent intel_gt_wait_for_idle from short
circuiting while a scheduling of user context could be enabled.
As with earlier PM patch, needs more explanation of what the problem is
and why it is only now a problem.
v2:
(Daniel
On 8/20/2021 15:44, Matthew Brost wrote:
Calling switch_to_kernel_context isn't needed if the engine PM reference
is taken while all contexts are pinned. By not calling
switch_to_kernel_context we save on issuing a request to the engine.
I thought the intention of the switch_to_kernel was to ensu
On 6/24/2021 17:59, Matthew Brost wrote:
On Thu, Jun 24, 2021 at 12:05:12AM -0700, Matthew Brost wrote:
From: John Harrison
Use the official driver default scheduling policies for configuring
the GuC scheduler rather than a bunch of hardcoded values.
Signed-off-by: John Harrison
Signed-off
On 6/24/2021 00:04, Matthew Brost wrote:
Remove old GuC stage descriptor, add lrc descriptor which will be used
by the new GuC interface implemented in this patch series.
Cc: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
On 6/24/2021 00:04, Matthew Brost wrote:
Add new GuC interface defines and structures while maintaining old ones
in parallel.
Cc: John Harrison
Signed-off-by: Matthew Brost
I think there was some difference of opinion over whether these
additions should be squashed in to the specific patches
, 'can determine in the' should be 'can determine if the'. Again,
not exactly a blocking issue but should be fixed.
Cc: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 5 +++
.../gpu/drm/i915/gt/uc/intel_g
is
not assigned. Patches later in the series will assign this value.
Cc: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 9 +
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 4 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 231 +
On 6/24/2021 00:04, Matthew Brost wrote:
Add bypass tasklet submission path to GuC. The tasklet is only used if H2G
channel has backpresure.
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 37 +++
1 file changed
On 6/30/2021 01:22, Martin Peres wrote:
On 24/06/2021 10:05, Matthew Brost wrote:
From: Daniele Ceraolo Spurio
Unblock GuC submission on Gen11+ platforms.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/int
ction.
v2:
(Michal)
- Use define for H2G room calculations
- Move INTEL_GUC_SEND_NB define
(Daniel Vetter)
- Use msleep_interruptible rather than cond_resched
v3:
(Michal)
- Move includes to following patch
- s/INTEL_GUC_SEND_NB/INTEL_GUC_CT_SEND_NB/g
Signed-off-by: John Har
ct_deadlock()
v3:
(Michal)
- Add ms to stall timer comment
(Matthew)
- Move broken check to intel_guc_ct_send()
Signed-off-by: John Harrison
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Matthew Brost
Looks plausible to me.
Reviewed-by: John Harrison
---
drivers/gpu/drm
descriptor values when
absolutely necessary. Also store the current space in the each channel
locally.
v2:
(Michel)
- Add additional sanity checks for head / tail pointers
- Use GUC_CTB_HDR_LEN rather than magic 1
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
---
drivers
On 7/6/2021 12:12, Michal Wajdeczko wrote:
On 06.07.2021 21:00, John Harrison wrote:
On 7/1/2021 10:15, Matthew Brost wrote:
CTB writes are now in the path of command submission and should be
optimized for performance. Rather than reading CTB descriptor values
(e.g. head, tail) which could
On 7/6/2021 12:33, Michal Wajdeczko wrote:
On 06.07.2021 21:19, John Harrison wrote:
On 7/6/2021 12:12, Michal Wajdeczko wrote:
On 06.07.2021 21:00, John Harrison wrote:
On 7/1/2021 10:15, Matthew Brost wrote:
CTB writes are now in the path of command submission and should be
optimized for
-by: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 88 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 6 ++
2 files changed, 65 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu
11:14, Pekka Paalanen wrote:
On Wed, 30 Jun 2021 11:58:25 -0700
John Harrison wrote:
On 6/30/2021 01:22, Martin Peres wrote:
On 24/06/2021 10:05, Matthew Brost wrote:
From: Daniele Ceraolo Spurio
Unblock GuC submission on Gen11+ platforms.
Signed-off-by: Michal Wajdeczko
Signed-off-by
On 7/7/2021 10:50, Matthew Brost wrote:
On Tue, Jul 06, 2021 at 03:51:00PM -0700, John Harrison wrote:
On 7/6/2021 15:20, Matthew Brost wrote:
CTB writes are now in the path of command submission and should be
optimized for performance. Rather than reading CTB descriptor values
(e.g. head
On 7/7/2021 11:56, Matthew Brost wrote:
Ok, I sent it but I looks like patchworks didn't like it. Anyways we
should be able to review that patch.
Matt
Maybe because it came out as 6/56 instead of 6/7? Also, not sure if it
needs to be in reply to 0/7 or 6/7?
John.
___
sts while
the deregister is in flight. Once the G2H is received indicating the
deregistration is complete the context is registered and the fence is
released.
Cc: John Harrison
Signed-off-by: Matthew Brost
With the above text fixed up:
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915
s added to intel_context_unpin when pin count == 1
to disable scheduling for that context. When the response CTB is
received it is safe to do the final unpin.
Future patches may add a heuristic / delay to schedule the disable
call back to avoid thrashing on schedule enable / disable.
Cc: John Harrison
Sig
ernel context request
completes on each engine in the context engine mask.
Cc: John Harrison
Signed-off-by: Matthew Brost
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/intel_context.c| 2 +-
drivers/gpu/drm/i915/gt/intel_context.h| 1 +
drivers/gpu/drm/i9
On 6/24/2021 00:04, Matthew Brost wrote:
Extend the deregistration context fence to fence whne a GuC context has
scheduling disable pending.
Cc: John Harrison
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 37 +++
1 file changed, 30
On 6/24/2021 00:04, Matthew Brost wrote:
Disable preempt busywait when using GuC scheduling. This isn't need as
needed
the GuC control preemption when scheduling.
controls
With the above fixed:
Reviewed-by: John Harrison
Cc: John Harrison
Signed-off-by: Matthew Brost
---
dr
i915 so another reason to not enable
these for GuC submission.
v2: Reword commit message
Cc: John Harrison
Signed-off-by: Matthew Brost
I think the commit description does not really match the patch content.
The description is valid but the 'disable' is done by simply not setting
the e
.
v2: rtimeout -> remaining_timeout
Cc: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 3 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 19
drivers/gpu/drm/i915/gt/intel_gt.h| 2 +
drivers/gpu/drm/i915/gt/intel_gt_re
On 7/9/2021 20:36, Matthew Brost wrote:
On Fri, Jul 09, 2021 at 03:59:11PM -0700, John Harrison wrote:
On 6/24/2021 00:04, Matthew Brost wrote:
Extend the deregistration context fence to fence whne a GuC context has
scheduling disable pending.
Cc: John Harrison
Signed-off-by: Matthew Brost
On 7/9/2021 20:00, Matthew Brost wrote:
On Fri, Jul 09, 2021 at 03:53:29PM -0700, John Harrison wrote:
On 6/24/2021 00:04, Matthew Brost wrote:
Disable engine barriers for unpinning with GuC. This feature isn't
needed with the GuC as it disables context scheduling before unpinning
On 6/24/2021 00:04, Matthew Brost wrote:
Update GuC debugfs to support the new GuC structures.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 22
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 3 ++
.../gpu/drm/i915
On 6/24/2021 00:04, Matthew Brost wrote:
Add trace points for request dependencies and GuC submit. Extended
existing request trace points to include submit fence value,, guc_id,
Excessive punctuation. Or maybe should say 'fence value, tail, guc_id'?
With that fixed:
Reviewed-by: Joh
On 6/24/2021 00:04, Matthew Brost wrote:
Add intel_context tracing. These trace points are particular helpful
when debugging the GuC firmware and can be enabled via
CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS kernel config option.
Cc: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm
On 6/24/2021 00:04, Matthew Brost wrote:
From: John Harrison
The serial number tracking of engines happens at the backend of
request submission and was expecting to only be given physical
engines. However, in GuC submission mode, the decomposition of virtual
to physical engines does not happen
On 6/24/2021 00:04, Matthew Brost wrote:
Hold a reference to the intel_context over life of an i915_request.
Without this an i915_request can exist after the context has been
destroyed (e.g. request retired, context closed, but user space holds a
reference to the request from an out fence). In th
On 6/24/2021 00:04, Matthew Brost wrote:
Update the bonding extension to return -ENODEV when using GuC submission
as this extension fundamentally will not work with the GuC submission
interface.
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gem
class when using GuC submission and
direct all physical engine interrupts to this breadcrumbs.
Signed-off-by: Matthew Brost
CC: John Harrison
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 41 +---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.h | 14 +++-
.../gpu/d
reset
support. Plus see couple of minor comments below.
Cc: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c | 3 +
drivers/gpu/drm/i915/gt/intel_context_types.h | 7 +
drivers/gpu/drm/i915/gt/intel_engine_types.h | 6 +
.../drm/i9
On 6/24/2021 00:05, Matthew Brost wrote:
If submission is disabled by the backend for any reason, reset the GPU
immediately in the heartbeat code as the backend can't be reenabled
until the GPU is reset.
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
.../gpu/drm/i9
On 6/24/2021 00:05, Matthew Brost wrote:
Add disable GuC interrupts to intel_guc_sanitize(). Part of this
requires moving the guc_*_interrupt wrapper function into header file
intel_guc.h.
Signed-off-by: Matthew Brost
Cc: Daniele Ceraolo Spurio
Reviewed-by: John Harrison
---
drivers/gpu
On 7/12/2021 13:59, Matthew Brost wrote:
On Mon, Jul 12, 2021 at 11:05:59AM -0700, John Harrison wrote:
On 6/24/2021 00:04, Matthew Brost wrote:
Update GuC debugfs to support the new GuC structures.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc
On 7/12/2021 14:36, Matthew Brost wrote:
On Mon, Jul 12, 2021 at 08:05:30PM +, Matthew Brost wrote:
On Mon, Jul 12, 2021 at 11:23:14AM -0700, John Harrison wrote:
On 6/24/2021 00:04, Matthew Brost wrote:
Hold a reference to the intel_context over life of an i915_request.
Without this an
On 7/12/2021 14:47, Matthew Brost wrote:
On Mon, Jul 12, 2021 at 11:10:40AM -0700, John Harrison wrote:
On 6/24/2021 00:04, Matthew Brost wrote:
Add intel_context tracing. These trace points are particular helpful
when debugging the GuC firmware and can be enabled via
firmware and reinitialize everything (e.g. CTB channels, contexts,
etc..).
Cc: John Harrison
Signed-off-by: Matthew Brost
Signed-off-by: Michal Wajdeczko
Reviewed-by: John Harrison
---
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 64
On 6/24/2021 00:05, Matthew Brost wrote:
GuC will issue a reset on detecting an engine hang and will notify
the driver via a G2H message. The driver will service the notification
by resetting the guilty context to a simple state or banning it
completely.
Cc: Matthew Brost
Cc: John Harrison
On 6/24/2021 00:05, Matthew Brost wrote:
GuC will notify the driver, via G2H, if it fails to
reset an engine. We recover by resorting to a full GPU
reset.
Signed-off-by: Matthew Brost
Signed-off-by: Fernando Pacheco
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h
On 6/24/2021 00:05, Matthew Brost wrote:
The GuC can implement execution qunatums, detect hung contexts and
other such things but it requires the timer expired interrupt to do so.
Signed-off-by: Matthew Brost
CC: John Harrison
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt
,
further muddling our error state.
There is ongoing work to define an API for a GuC debug state dump. The
suggestion for now is to manually disable FW initiated resets in cases
where debug state is needed.
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt
On 6/24/2021 00:04, Matthew Brost wrote:
Ensure G2H response has space in the buffer before sending H2G CTB as
the GuC can't handle any backpressure on the G2H interface.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h
On 7/14/2021 17:06, Matthew Brost wrote:
On Tue, Jul 13, 2021 at 11:36:05AM -0700, John Harrison wrote:
On 6/24/2021 00:04, Matthew Brost wrote:
Ensure G2H response has space in the buffer before sending H2G CTB as
the GuC can't handle any backpressure on the G2H interface.
Signed-o
On 6/16/2021 03:25, Daniel Vetter wrote:
On Thu, Jun 10, 2021 at 10:46 PM wrote:
From: John Harrison
Various UMDs need to know the L3 bank count. So add a query API for it.
Please link to both the igt test submission for this (there's not even
a Test-with: on the cover letter)
Is th
On 7/19/2021 10:24, Matthew Brost wrote:
On Fri, Jul 16, 2021 at 01:17:14PM -0700, Matthew Brost wrote:
From: John Harrison
The media watchdog mechanism involves GuC doing a silent reset and
continue of the hung context. This requires the i915 driver provide a
golden context to GuC in the ADS
this value.
v2:
(John Harrison)
- Clean up some comments
Cc: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 9 +
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 4 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 231 +
: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c | 5 +
drivers/gpu/drm/i915/gt/intel_context_types.h | 22 +-
drivers/gpu/drm/i915/gt/intel_lrc_reg.h | 1 -
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 40 ++
drivers/gpu/drm/i915/gt/uc
On 7/19/2021 15:55, Matthew Brost wrote:
On Mon, Jul 19, 2021 at 04:01:56PM -0700, John Harrison wrote:
On 7/16/2021 13:16, Matthew Brost wrote:
Implement GuC submission tasklet for new interface. The new GuC
interface uses H2G to submit contexts to the GuC. Since H2G use a single
channel, a
i915 so another reason to not enable
these for GuC submission.
This patch fixes an existing bug where I915_ENGINE_HAS_SEMAPHORES was
not honored correctly.
Bugs plural. Otherwise:
Reviewed-by: John Harrison
v2: Reword commit message
v3:
(John H)
- Add text to commit indicating this also
.
v2: rtimeout -> remaining_timeout
v3: Drop unnecessary includes, guc_submission_busy_loop ->
guc_submission_send_busy_loop, drop negatie timeout trick, move a
refactor of guc_context_unpin to earlier path (John H)
Cc: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/d
On 7/16/2021 13:16, Matthew Brost wrote:
Update GuC debugfs to support the new GuC structures.
v2:
(John Harrison)
- Remove intel_lrc_reg.h include from i915_debugfs.c
(Michal)
- Rename GuC debugfs functions
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by
addressed.
John.
and ring tail value.
v2: Fix white space alignment in i915_request_add trace point
Cc: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 3 ++
drivers/gpu/drm/i915/i915_request.c | 3
On 7/16/2021 13:16, Matthew Brost wrote:
From: John Harrison
The serial number tracking of engines happens at the backend of
request submission and was expecting to only be given physical
engines. However, in GuC submission mode, the decomposition of virtual
to physical engines does not happen
On 1/9/2019 03:51, Chris Wilson wrote:
Quoting Mika Kuoppala (2019-01-09 09:23:53)
I should have been more specific. My concern was on documenting
the changing return values.
The interface isn't documented, there's nothing in the header about the
functions? Where else would it be?
I think Mik
On 1/9/2019 03:16, Mika Kuoppala wrote:
Chris Wilson writes:
diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index 16693dd4d019..bc230e43b98f 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@
On 1/7/2019 03:54, Chris Wilson wrote:
Frequently, we use intel_runtime_pm_get/_put around a small block.
Formalise that usage by providing a macro to define such a block with an
automatic closure to scope the intel_runtime_pm wakeref to that block,
i.e. macro abuse smelling of python.
Signed-of
On 1/7/2019 03:54, Chris Wilson wrote:
The majority of runtime-pm operations are bounded and scoped within a
function; these are easy to verify that the wakeref are handled
correctly. We can employ the compiler to help us, and reduce the number
of wakerefs tracked when debugging, by passing aroun
On 1/9/2019 16:24, John Harrison wrote:
On 1/7/2019 03:54, Chris Wilson wrote:
Frequently, we use intel_runtime_pm_get/_put around a small block.
Formalise that usage by providing a macro to define such a block with an
automatic closure to scope the intel_runtime_pm wakeref to that block,
i.e
On 1/10/2019 02:11, Chris Wilson wrote:
On module load and unload, we grab the POWER_DOMAIN_INIT powerwells and
transfer them to the runtime-pm code. We can use our wakeref tracking to
verify that the wakeref is indeed passed from init to enable, and
disable to fini; and across suspend.
Signed-o
(intel_dp);
Any particular reason for leaving these as dev_priv when the earlier
patches converted everything in sight to i915?
Otherwise:
Reviewed-by: John Harrison
+ intel_wakeref_t wakeref;
/*
* See intel_power_sequencer_reset() why we need
* a power domain
}
void intel_gpu_ips_teardown(void)
{
- spin_lock_irq(&mchdev_lock);
- i915_mch_dev = NULL;
- spin_unlock_irq(&mchdev_lock);
+ rcu_assign_pointer(i915_mch_dev, NULL);
}
static void intel_init_emon(struct drm_i915_private *dev_priv)
I am somewhat ne
On 1/11/2019 09:31, Antonio Argenziano wrote:
On 11/01/19 00:22, Tvrtko Ursulin wrote:
On 11/01/2019 00:47, Antonio Argenziano wrote:
On 07/01/19 08:58, Tvrtko Ursulin wrote:
On 07/01/2019 13:57, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-07 13:43:29)
On 07/01/2019 11:58, Tvrtko
101 - 200 of 1003 matches
Mail list logo
