On 8/18/2021 11:16 PM, Matthew Brost wrote:
Rather than processing 1 G2H at a time and re-queuing the work queue if
more messages exist, process all the G2H in a single pass of the work
queue.
Signed-off-by: Matthew Brost
Cc: Daniel Vetter
Cc: Michal Wajdeczko
Reviewed-by: Daniele
On Thu, Aug 19, 2021 at 05:01:03PM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 8/18/2021 11:16 PM, Matthew Brost wrote:
> > Don't drop ce->guc_active.lock when unwinding a context after reset.
> > At one point we had to drop this because of a lock inversion but that is
> > no longer the case.
On 8/19/2021 4:53 PM, Matthew Brost wrote:
On Thu, Aug 19, 2021 at 04:54:00PM -0700, Daniele Ceraolo Spurio wrote:
On 8/18/2021 11:16 PM, Matthew Brost wrote:
When unwinding requests on a reset context, if other requests in the
context are in the priority list the requests could be
On 8/18/2021 11:16 PM, Matthew Brost wrote:
Don't drop ce->guc_active.lock when unwinding a context after reset.
At one point we had to drop this because of a lock inversion but that is
no longer the case. It is much safer to hold the lock so let's do that.
Fixes: eb5e7da736f3
On Thu, Aug 19, 2021 at 04:54:00PM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 8/18/2021 11:16 PM, Matthew Brost wrote:
> > When unwinding requests on a reset context, if other requests in the
> > context are in the priority list the requests could be resubmitted out
> > of seqno order.
On 8/18/2021 11:16 PM, Matthew Brost wrote:
When unwinding requests on a reset context, if other requests in the
context are in the priority list the requests could be resubmitted out
of seqno order. Traverse the list of active requests in reverse and
append to the head of the priority list
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
== Series Details ==
Series: drm/i915/dg1: remove __maybe_unused leftover
URL : https://patchwork.freedesktop.org/series/93842/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10499_full -> Patchwork_20857_full
Summary
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
== Series Details ==
Series: drm/i915/hdcp: HDCP2.2 MST dock fixes (rev7)
URL : https://patchwork.freedesktop.org/series/93570/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10499_full -> Patchwork_20856_full
Summary
== Series Details ==
Series: drm/i915/dg1: remove __maybe_unused leftover
URL : https://patchwork.freedesktop.org/series/93842/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10499 -> Patchwork_20857
Summary
---
On Thu, Aug 19, 2021 at 02:31:51PM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 8/18/2021 11:16 PM, Matthew Brost wrote:
> > A small race that could result in incorrect accounting of the number
> > of outstanding G2H. Basically prior to this patch we did not increment
> > the number of
On 8/18/2021 11:16 PM, Matthew Brost wrote:
A small race that could result in incorrect accounting of the number
of outstanding G2H. Basically prior to this patch we did not increment
the number of outstanding G2H if we encoutered a GT reset while sending
a H2G. This was incorrect as the
This was added in commit 05e265841f7e ("drm/i915/dg1: add initial DG-1
definitions") so we could continue to add support for DG1 without
risk to expose a broken UAPI. Now that we added DG1 to the PCI ID list
i915 may bind to, remove the leftover.
Fixes: d5ef86b38e4c ("drm/i915: Add pci ids and
== Series Details ==
Series: drm/i915/hdcp: HDCP2.2 MST dock fixes (rev7)
URL : https://patchwork.freedesktop.org/series/93570/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10499 -> Patchwork_20856
Summary
---
On Wed, 2021-08-18 at 11:51 +, Gupta, Anshuman wrote:
>
>
> > -Original Message-
> > From: Li, Juston
> > Sent: Friday, August 13, 2021 12:14 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: seanp...@chromium.org; Gupta, Anshuman <
> > anshuman.gu...@intel.com>;
> > C, Ramalingam
On some MST docking stations, rx_info can only be read after
RepeaterAuth_Send_ReceiverID_List and the RxStatus READY bit is set
otherwise the read will return -EIO.
This behavior causes the mst stream type1 capability test to fail to
read rx_info and determine if the topology supports type1 and
When reading RepeaterAuth_Send_ReceiverID_List, RxInfo is read by itself
once to retrieve the DEVICE_COUNT to calculate the size of the
ReceiverID list then read a second time as a part of reading ReceiverID
list.
On some MST docking stations, RxInfo can only be read after the RxStatus
READY bit
Update cp_irq_count_cached when reading messages rather than when
writing a message to make sure the value is up to date and not
stale from a previously handled CP_IRQ.
AKE flow doesn't always respond to a read with a ACK write msg.
E.g. AKE_Send_Pairing_Info will "timeout" because we received
a
Fixes to get HDCP2.2 over MST working on MST docking stations with
certain behaviors that cause the current flow to fail.
Tested with Dell WD-19 and Lenovo ThinkPad USB Type-C Dock Gen 2.
These fixes should make the flow more robust to handle behaviors that as
far as I can tell are unclear in the
On Wed, Aug 18, 2021 at 01:20:54PM +0200, Heiko Carstens wrote:
> On Sat, Aug 14, 2021 at 02:46:27PM +0200, Heiko Carstens wrote:
> > Hello,
> >
> > I have Fedora 33 running, and with the Fedore kernel update from 5.11
> > series to 5.12 my external monitor was not detected anymore. Same is
> >
On Wed, Aug 18, 2021 at 09:10:50PM +0300, Jani Nikula wrote:
> 128b/132b has a separate transcoder DDI mode, which also requires the
> MST transport select to be set. Note that we'll use DP MST also for
> single-stream 128b/132b.
>
> Having the FDI and 128b/132b modes share the register mode
On Wed, Aug 18, 2021 at 09:10:48PM +0300, Jani Nikula wrote:
> UHBR rates and 128b/132b channel encoding go hand in hand.
>
> Reviewed-by: Manasi Navare
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_dp_link_training.c | 3 ++-
> 1 file changed, 2 insertions(+), 1
On Wed, Aug 18, 2021 at 09:10:41PM +0300, Jani Nikula wrote:
> See if sink supports DP 2.0 128b/132b channel encoding, and update sink
> rates accordingly.
>
> FIXME: Also take LTTPR 128b/132b into account.
>
> Reviewed-by: Manasi Navare
> Signed-off-by: Jani Nikula
> ---
>
On Wed, Aug 18, 2021 at 09:10:40PM +0300, Jani Nikula wrote:
> The MST code uses actual link rates in the limits struct, while the DP
> code in general uses indexes to the ->common_rates[] array. Fix the
> confusion by using actual link rate values everywhere. This is a better
> abstraction than
On Wed, Aug 18, 2021 at 09:10:39PM +0300, Jani Nikula wrote:
> The DP 2.0 128b/132b channel coding uses TX FFE presets instead of
> vswing and pre-emphasis.
>
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_dp_helper.c
Re-reported.
Bug filed for the regression.
#4009 igt@kms_atomic_transition@plane-toggle-modeset-transition - incomplete -
No warnings/errors
Lakshmi.
-Original Message-
From: Matthew Auld
Sent: Thursday, August 19, 2021 6:40 AM
To: Intel Graphics Development
Cc: Thomas Hellström ;
On Fri, Aug 13, 2021 at 01:43:20PM +0300, Jani Nikula wrote:
> Extend the use of extended receiver cap at 0x2200 to cover
> MAIN_LINK_CHANNEL_CODING_CAP in 0x2206, in case an implementation hides
> the DP 2.0 128b/132b channel encoding cap.
>
> Cc: Manasi Navare
> Signed-off-by: Jani Nikula
>
== Series Details ==
Series: drm/i915: Ditch the i915_gem_ww_ctx loop member (rev2)
URL : https://patchwork.freedesktop.org/series/93711/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10490_full -> Patchwork_20834_full
Re-reported.
Following bugs are filed
#4007 SNB: igt@gem_ppgtt@blt-vs-render-ctxn - fail - VM Periodic Tas invoked
oom-killer
#4008 TGL: igt@gem_spin_batch@legacy@bsd1 - incomplete - No logs
Lakshmi.
-Original Message-
From: Matthew Auld
Sent: Thursday, August 19, 2021 6:31 AM
To:
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/buddy: add some pretty printing
URL : https://patchwork.freedesktop.org/series/93819/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10498_full -> Patchwork_20853_full
On Wed, Aug 18, 2021 at 09:10:36PM +0300, Jani Nikula wrote:
> The bw code equals link_rate / 0.27 Gbps only for 8b/10b link
> rates. Handle DP 2.0 UHBR rates as special cases, though this is not
> pretty.
Ugh. So if I'm reading the spec right the behaviour of this
register now changes
On Wed, Aug 18, 2021 at 01:11:09PM +0300, Jani Nikula wrote:
> There's no performance reason to have it as static inline; move it out
> of intel_display_types.h to reduce clutter and dependency on i915_drv.h.
>
> Signed-off-by: Jani Nikula
> ---
>
On Thu, Aug 19, 2021 at 01:14:55AM +0800, Kai-Heng Feng wrote:
> Users reported that after commit 2bbd6dba84d4 ("drm/i915: Try to use
> fast+narrow link on eDP again and fall back to the old max strategy on
> failure"), the screen starts to have wobbly effect.
>
> Commit a5c936add6a2
On Wed, Aug 18, 2021 at 07:48:03PM +, Souza, Jose wrote:
> On Wed, 2021-08-18 at 17:55 +0300, Ville Syrjälä wrote:
> > On Tue, Aug 17, 2021 at 05:42:15PM -0700, José Roberto de Souza wrote:
> > > By now all the userspace applications should have migrated to atomic
> > > or at least be calling
> -Original Message-
> From: Roper, Matthew D
> Sent: Tuesday, August 17, 2021 3:42 AM
> To: Siddiqui, Ayaz A
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH V2 4/5] drm/i915/gt: Initialize unused MOCS
> entries with device specific values
>
> On Mon, Aug 16,
Quoting Zhenyu Wang (2021-08-19 11:29:29)
> On 2021.08.17 13:22:03 +0800, Zhenyu Wang wrote:
> > > On 2021.08.16 19:34:58 +0200, Christoph Hellwig wrote:
> > > > Any updates on this? I'd really hate to miss this merge window.
> > >
> > > I'm still waiting for our validation team's report on
On 16-Aug-21 5:58 PM, Jani Nikula wrote:
On Mon, 16 Aug 2021, "Sharma, Swati2" wrote:
On 16-Aug-21 5:40 PM, Jani Nikula wrote:
On Mon, 16 Aug 2021, "Sharma, Swati2" wrote:
On 13-Aug-21 1:16 PM, Jani Nikula wrote:
On Thu, 12 Aug 2021, Swati Sharma wrote:
drm_dp_dpcd_read/write already
== Series Details ==
Series: MIPI DSI driver enhancements (rev7)
URL : https://patchwork.freedesktop.org/series/92695/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10498_full -> Patchwork_20855_full
Summary
---
On Tue, 17 Aug 2021 at 18:28, Patchwork
wrote:
>
> Patch Details
> Series:drm/i915: Ditch the i915_gem_ww_ctx loop member (rev2)
> URL:https://patchwork.freedesktop.org/series/93711/
> State:failure
> Details:https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20834/index.html
>
> CI Bug Log -
On Thu, 19 Aug 2021 at 14:04, Patchwork
wrote:
>
> Patch Details
> Series:series starting with [v2,1/2] drm/i915/buddy: add some pretty printing
> URL:https://patchwork.freedesktop.org/series/93819/
> State:failure
> Details:https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/index.html
>
>
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/buddy: add some pretty printing
URL : https://patchwork.freedesktop.org/series/93819/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10498_full -> Patchwork_20853_full
== Series Details ==
Series: MIPI DSI driver enhancements (rev7)
URL : https://patchwork.freedesktop.org/series/92695/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10498 -> Patchwork_20855
Summary
---
**SUCCESS**
On 8/19/21 11:34 AM, Matthew Auld wrote:
This should give a more complete view of the various bits of internal
resource manager state, for device local-memory.
v2(Thomas):
- Move the region printing into a nice helper
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
For the series
== Series Details ==
Series: MIPI DSI driver enhancements (rev7)
URL : https://patchwork.freedesktop.org/series/92695/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
== Series Details ==
Series: MIPI DSI driver enhancements (rev7)
URL : https://patchwork.freedesktop.org/series/92695/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7b7b4e96bce6 drm/i915/dsi: send correct gpio_number on gen11 platform
c45bb5984386 drm/i915/jsl: program DSI
On Thu, Aug 19, 2021 at 12:53 PM Desmond Cheong Zhi Xi
wrote:
>
> On 18/8/21 7:02 pm, Daniel Vetter wrote:
> > On Wed, Aug 18, 2021 at 03:38:22PM +0800, Desmond Cheong Zhi Xi wrote:
> >> In a future patch, a read lock on drm_device.master_rwsem is
> >> held in the ioctl handler before the check
Driver has to swap the endian before send brightness level value
to tcon.
v2: Use __be16 instead of u16 to fix sparse warning.
v3: Send one or two bytes brightness value depend on the precision.
Reported-by: kernel test robot
Cc: Ville Syrjala
Cc: Jani Nikula
Cc: Vandita Kulkarni
Cc: Cooper
== Series Details ==
Series: drm, kernel: update locking for DRM (rev2)
URL : https://patchwork.freedesktop.org/series/93782/
State : failure
== Summary ==
Applying: drm: move master_lookup_lock into drm_device
Applying: drm: hold master_lookup_lock when releasing a drm_file's master
Maybe that TODO comment could be moved into the code instead of leaving
it just into commit message?
Either way, patch look ok to me.
Reviewed-by: Juha-Pekka Heikkila
On 2.7.2021 23.46, Ville Syrjala wrote:
From: Ville Syrjälä
There's some kind of weird corner cases in FBC which requires
On 18/8/21 7:02 pm, Daniel Vetter wrote:
On Wed, Aug 18, 2021 at 03:38:22PM +0800, Desmond Cheong Zhi Xi wrote:
In a future patch, a read lock on drm_device.master_rwsem is
held in the ioctl handler before the check for ioctl
permissions. However, this produces the following lockdep splat:
Look ok to me.
Reviewed-by: Juha-Pekka Heikkila
On 2.7.2021 23.46, Ville Syrjala wrote:
From: Ville Syrjälä
Apply the same 512 byte FBC segment alignment to glk+ as we use
on skl+. The only real difference is that we now have a dedicated
register for the FBC override stride. Not 100% sure
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/buddy: add some pretty printing
URL : https://patchwork.freedesktop.org/series/93819/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10498 -> Patchwork_20853
== Series Details ==
Series: refactor the i915 GVT support
URL : https://patchwork.freedesktop.org/series/93816/
State : failure
== Summary ==
Patch is empty.
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To
On 19/8/21 5:26 pm, Christoph Hellwig wrote:
On Wed, Aug 18, 2021 at 03:38:23PM +0800, Desmond Cheong Zhi Xi wrote:
+EXPORT_SYMBOL(task_work_add);
EXPORT_SYMBOL_GPL for this kinds of functionality, please.
Thanks, I wasn't aware of the GPL-only export. I'll update this in a
future series
This should give a more complete view of the various bits of internal
resource manager state, for device local-memory.
v2(Thomas):
- Move the region printing into a nice helper
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/i915_debugfs.c| 4 ++--
Implement the debug hook for the buddy resource manager. For this we
want to print out the status of the memory manager, including how much
memory is still allocatable, what page sizes we have etc. This will be
triggered when TTM is unable to fulfil an allocation request for device
local-memory.
On Wed, Aug 18, 2021 at 03:38:23PM +0800, Desmond Cheong Zhi Xi wrote:
> +EXPORT_SYMBOL(task_work_add);
EXPORT_SYMBOL_GPL for this kinds of functionality, please.
== Series Details ==
Series: Clean up GuC CI failures, simplify locking, and kernel DOC (rev3)
URL : https://patchwork.freedesktop.org/series/93704/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10498_full -> Patchwork_20851_full
On 2021.08.17 13:22:03 +0800, Zhenyu Wang wrote:
> > On 2021.08.16 19:34:58 +0200, Christoph Hellwig wrote:
> > > Any updates on this? I'd really hate to miss this merge window.
> >
> > I'm still waiting for our validation team's report on this. I'm afraid
> > it might be missing for next
On Wed, Aug 18, 2021 at 04:44:44PM +, Souza, Jose wrote:
> On Wed, 2021-08-18 at 11:54 +0200, Daniel Vetter wrote:
> > On Tue, Aug 17, 2021 at 04:26:04PM -0700, José Roberto de Souza wrote:
> > > Cursors don't have a framebuffer so the fb comparisson was always
> > > failing and atomic state
On Wed, Aug 18, 2021 at 09:12:32PM +0200, Michal Wajdeczko wrote:
>
>
> On 18.08.2021 18:35, Daniel Vetter wrote:
> > On Wed, Aug 18, 2021 at 5:11 PM Michal Wajdeczko
> > wrote:
> >>
> >>
> >>
> >> On 18.08.2021 16:20, Daniel Vetter wrote:
> >>> On Thu, Jul 01, 2021 at 05:55:11PM +0200, Michal
On Thu, 19 Aug 2021 at 08:25, Thomas Hellström
wrote:
>
> On Wed, 2021-08-18 at 18:12 +0100, Matthew Auld wrote:
> > If the ttm_bo_init_reserved() call fails ensure we also release the
> > region, otherwise we leak the reference, or worse hit some uaf, when
> > we
> > start using the
== Series Details ==
Series: Clean up GuC CI failures, simplify locking, and kernel DOC (rev3)
URL : https://patchwork.freedesktop.org/series/93704/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10498 -> Patchwork_20851
On Wed, 2021-08-18 at 15:58 +0100, Matthew Auld wrote:
> This should give a more complete view of the various bits of internal
> resource manager state, for device local-memory.
>
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellström
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 12 +---
On Wed, 2021-08-18 at 18:12 +0100, Matthew Auld wrote:
> If the ttm_bo_init_reserved() call fails ensure we also release the
> region, otherwise we leak the reference, or worse hit some uaf, when
> we
> start using the objects.list. Also remove the make_unshrinkable call
> here, which doesn't do
== Series Details ==
Series: Clean up GuC CI failures, simplify locking, and kernel DOC (rev3)
URL : https://patchwork.freedesktop.org/series/93704/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: Clean up GuC CI failures, simplify locking, and kernel DOC (rev3)
URL : https://patchwork.freedesktop.org/series/93704/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
cdd86549dd1d drm/i915/guc: Fix blocked context accounting
de712a42478e
On Wed, 2021-08-18 at 15:58 +0100, Matthew Auld wrote:
> Implement the debug hook for the buddy resource manager. For this we
> want to print out the status of the memory manager, including how much
> memory is still allocatable, what page sizes we have etc. This will be
> triggered when TTM is
s/static inline/static/g + fix function argument alignment to make
checkpatch happy.
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 116 +-
1 file changed, 57 insertions(+), 59 deletions(-)
diff --git
Now that we have locking hierarchy of sched_engine->lock ->
ce->guc_state everything from guc_active can be moved into guc_state and
protected the guc_state.lock.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c | 10 +--
Drop pin count check trick between a sched_disable and re-pin, now rely
on the lock and counter of the number of committed requests to determine
if scheduling should be disabled on the context.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 2 +
Rework and simplify the locking with GuC subission. Drop
sched_state_no_lock and move all fields under the guc_state.sched_state
and protect all these fields with guc_state.lock . This requires
changing the locking hierarchy from guc_state.lock -> sched_engine.lock
to sched_engine.lock ->
To make ownership of locking clear move fields (guc_id, guc_id_ref,
guc_id_link) to sub structure guc_id in intel_context.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c | 4 +-
drivers/gpu/drm/i915/gt/intel_context_types.h | 18 +--
Lock the xarray and take ref to the context if needed.
v2:
(Checkpatch)
- Add new line after declaration
(Daniel Vetter)
- Correct put / get accounting in xa_for_loops
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 103 +++---
1 file changed,
It isn't safe to scrub for missing G2H or continue with the reset until
all G2H processing is complete. Flush the G2H work queue during reset to
ensure it is done running.
Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface")
Signed-off-by: Matthew Brost
---
Move GuC management fields in context under guc_active struct as this is
where the lock that protects theses fields lives. Also only set guc_prio
field once during context init.
Fixes: ee242ca704d3 ("drm/i915/guc: Implement GuC priority management")
Signed-off-by: Matthew Brost
Cc:
---
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
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 44 ++---
A context can get destroyed after cancelling a request so take a
reference to context when cancelling a request.
Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation")
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 5 -
1 file changed, 4
Move guc_blocked fence to struct guc_state as the lock which protects
the fence lives there.
s/ce->guc_blocked/ce->guc_state.blocked_fence/g
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c| 5 +++--
drivers/gpu/drm/i915/gt/intel_context_types.h | 5 ++---
Propagating errors to dependent fences is wrong, don't do it. A selftest
in the following exposed the propagating of an error to a dependent
fence after an engine reset.
This reverts commit 8e9f84cf5cac248a1c6a5daa4942879c8b765058.
v2:
(Daniel Vetter)
- Use revert
References: 3761baae908a
Error captures can now be done in a work queue processing G2H messages.
These messages need to be completely done being processed in the reset
path, to avoid races in the missing G2H cleanup, which create a
dependency on memory allocations and dma fences (i915_requests).
Requests depend on resets,
While debugging an issue with full GT resets I went down a rabbit hole
thinking the scrubbing of lost G2H wasn't working correctly. This proved
to be incorrect as this was working just fine but this chase inspired me
to write a selftest to prove that this works. This simple selftest
injects errors
Reset LRC descriptor if a context register returns -ENODEV as this means
we are mid-reset.
Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface")
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 6 --
1 file changed, 4
GuC submission has exposed an existing memory corruption in
live_lrc_isolation. We believe that some writes to the watchdog offsets
in the LRC (0x178 & 0x17c) can result in trashing of portions of the
address space. With GuC submission there are additional objects which
can move the context
A subsequent patch will flip the locking hierarchy from
ce->guc_state.lock -> sched_engine->lock to sched_engine->lock ->
ce->guc_state.lock. As such we need to release the submit fence for a
request from an IRQ to break a lock inversion - i.e. the fence must be
release went holding
Before we did some clever tricks to not use the a lock when touching
guc_state.sched_state in certain cases. Don't do that, enforce the use
of the lock.
Part of this is removing a dead code path from guc_lrc_desc_pin where a
context could be deregistered when the aforementioned function was
Kick tasklet after queuing a request so it submitted in a timely manner.
Fixes: 3a4cdf1982f0 ("drm/i915/guc: Implement GuC context operations for new
inteface")
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 1 +
1 file changed, 1 insertion(+)
diff --git
Rather than processing 1 G2H at a time and re-queuing the work queue if
more messages exist, process all the G2H in a single pass of the work
queue.
Signed-off-by: Matthew Brost
Cc: Daniel Vetter
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 6 +++---
1 file changed, 3
Daniel Vetter pointed out that locking in the GuC submission code was
overly complicated, let's clean this up a bit before introducing more
features in the GuC submission backend.
Also fix some CI failures, port fixes from our internal tree, and add a
few more selftests for coverage.
Lastly, add
Prior to this patch the blocked context counter was cleared on
init_sched_state (used during registering a context & resets) which is
incorrect. This state needs to be persistent or the counter can read the
incorrect value resulting in scheduling never getting enabled again.
Fixes: 62eaf0ae217d
If the context is reset as a result of the request cancelation the
context reset G2H is received after schedule disable done G2H which is
likely the wrong order. The schedule disable done G2H release the
waiting request cancelation code which resubmits the context. This races
with the context
When unblocking a context, do not enable scheduling if the context is
banned, guc_id invalid, or not registered.
Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation")
Signed-off-by: Matthew Brost
Cc:
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 3 +++
1 file changed, 3
Add a cancel request selftest that results in an engine reset to cancel
the request as it is non-preemptable. Also insert a NOP request after
the cancelled request and confirm that it completely successfully.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/selftests/i915_request.c | 100
A small race that could result in incorrect accounting of the number
of outstanding G2H. Basically prior to this patch we did not increment
the number of outstanding G2H if we encoutered a GT reset while sending
a H2G. This was incorrect as the context state had already been updated
to anticipate
When unwinding requests on a reset context, if other requests in the
context are in the priority list the requests could be resubmitted out
of seqno order. Traverse the list of active requests in reverse and
append to the head of the priority list to fix this.
Fixes: eb5e7da736f3 ("drm/i915/guc:
Don't drop ce->guc_active.lock when unwinding a context after reset.
At one point we had to drop this because of a lock inversion but that is
no longer the case. It is much safer to hold the lock so let's do that.
Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface")
97 matches
Mail list logo
