== Series Details ==
Series: series starting with [1/3] drm/i915: Check for error before calling
cmpxchg()
URL : https://patchwork.freedesktop.org/series/70568/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7500_full -> Patchwork_15630_full
===
== Series Details ==
Series: drm/i915: Fix the use-after-free between i915_active_ref and
__active_retire
URL : https://patchwork.freedesktop.org/series/70563/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7499_full -> Patchwork_15629_full
== Series Details ==
Series: series starting with [1/4] drm/i915/tgl: Select master transcoder for
MST stream
URL : https://patchwork.freedesktop.org/series/70581/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7506 -> Patchwork_15636
==
== Series Details ==
Series: drm/i915/guc: Update uncore access path in flush_ggtt_writes
URL : https://patchwork.freedesktop.org/series/70579/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7506 -> Patchwork_15635
Summary
-
> -Original Message-
> From: Chris Wilson
> Sent: Friday, December 6, 2019 8:15 PM
> To: Liu, Chuansheng ; intel-
> g...@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH] drm/i915: Fix the use-after-free between
> i915_active_ref and __active_retire
>
> Quoting Liu, Chuansheng (2
This function is only called from port sync and it is identical to
what will be executed again in intel_update_crtc() over port sync
pipes.
If it is really necessary it at least deserves a better name and a
comment, leaving it to people working on port sync.
Cc: Ville Syrjälä
Cc: Maarten Lankhors
The disable sequence after wait for transcoder off was not correctly
implemented.
The MST disable sequence is basically the same for HSW, SKL, ICL and
TGL, with just minor changes for TGL.
So here calling a new MST function to do the MST sequences, most of
the steps just moved from the post disabl
On TGL the blending of all the streams have moved from DDI to
transcoder, so now every transcoder working over the same MST port must
send its stream to a master transcoder and master will send to DDI
respecting the time slots.
So here adding all the CRTCs that shares the same MST stream if
needed
Due to DDB overlaps the pipe enabling sequence is not always crescent.
As the previous patch selects the first pipe/transcoder in the MST
stream to the MST master and it needs to be enabled first this
changes were needed to guarantee that.
So here it will first loop through all the MST masters and
This reverts commit 343aae776a58a67fa153825385e6fe90e3185c5b.
__for_each_physical_engine() reprograms the context, invalidating the
use of e->flags to select engines, necessitating e->index instead.
Withot also fixing up the engine selection, the result is that random
engines were being used to re
From: John Harrison
If a FW override is present then a version mis-match is actually
ignored. The warning notice was still being printed, though. Which
could confuse people by implying that the load had failed when it had
actually succeeded. Given that the whole point of the override is to
use di
From: Matthew Brost
The preferred way to access the uncore is through the GT structure.
Update the GuC function, flush_ggtt_writes, to use this path.
Signed-off-by: Matthew Brost
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 5 ++---
1 file changed, 2 insertions(+)
Hi Chris,
[...]
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> index 808eb327a29b..53e28e417cc9 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> @@ -187,21 +187,23 @@ int i91
Quoting Andi Shyti (2019-12-07 00:03:27)
> Hi Chris,
>
> [...]
>
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> > index 808eb327a29b..53e28e417cc9 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> > +++ b/drivers/gpu/drm
Hi Chris,
> All pinning must be done prior to i915_request_create, to avoid
> timeline->mutex inversions.
>
> Here we slightly abuse the context_barrier_task stages to utilise the
> 'skip' decision as an opportunity to acquire the pin on the new ppgtt.
> Consider it s/skip/prepare/. At the moment
Quoting Andi Shyti (2019-12-06 23:31:26)
> Hi Chris,
>
> > All pinning must be done prior to i915_request_create, to avoid
> > timeline->mutex inversions.
> >
> > Here we slightly abuse the context_barrier_task stages to utilise the
> > 'skip' decision as an opportunity to acquire the pin on the
On Fri, 2019-12-06 at 05:56 +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [v4,1/3] drm/i915/display: Do not check
> for the ddb allocations of turned off pipes
> URL : https://patchwork.freedesktop.org/series/70520/
> State : failure
>
> == Summary ==
>
> CI B
== Series Details ==
Series: drm/i915/gt: Replace I915_WRITE with its uncore counterpart
URL : https://patchwork.freedesktop.org/series/70575/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7503 -> Patchwork_15634
Summary
--
On Fri, 2019-12-06 at 04:02 +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Add new EHL/JSL PCI ids (rev4)
> URL : https://patchwork.freedesktop.org/series/70399/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_7492_full -> Patchwork_15611_full
> =
On Fri, 2019-12-06 at 04:02 +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Add new EHL/JSL PCI ids (rev4)
> URL : https://patchwork.freedesktop.org/series/70399/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_7492_full -> Patchwork_15611_full
> =
On Fri, Dec 06, 2019 at 07:23:43PM +, Patchwork wrote:
== Series Details ==
Series: series starting with [1/3] drm/i915/display: move clk off sanitize to
its own function
URL : https://patchwork.freedesktop.org/series/70535/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM
== Series Details ==
Series: drm/i915/gt: Replace I915_WRITE with its uncore counterpart
URL : https://patchwork.freedesktop.org/series/70575/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
addcad6b8cf1 drm/i915/gt: Replace I915_WRITE with its uncore counterpart
-:84: CHECK:PARE
From: Andi Shyti
Get rid of the last remaining I915_WRITEs and replace them with
intel_uncore_write().
Signed-off-by: Andi Shyti
---
.../gpu/drm/i915/gt/intel_ring_submission.c | 48 ++-
1 file changed, 25 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/i
== Series Details ==
Series: series starting with [1/5] drm/i915/gem: Flush the pwrite through the
chipset before signaling
URL : https://patchwork.freedesktop.org/series/70560/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7496_full -> Patchwork_15628_full
==
On Fri, Dec 06, 2019 at 02:35:38PM -0800, Souza, Jose wrote:
> On Fri, 2019-12-06 at 14:22 -0800, Matt Roper wrote:
> > On Thu, Dec 05, 2019 at 01:03:50PM -0800, José Roberto de Souza
> > wrote:
> > > Commit 9c722e17c1b9 ("drm/i915: Disable pipes in reverse order")
> > > reverted the order that pip
On Fri, 2019-12-06 at 14:22 -0800, Matt Roper wrote:
> On Thu, Dec 05, 2019 at 01:03:50PM -0800, José Roberto de Souza
> wrote:
> > Commit 9c722e17c1b9 ("drm/i915: Disable pipes in reverse order")
> > reverted the order that pipes gets disabled because of TGL
> > master/slave relationship between t
On Fri, Dec 06, 2019 at 11:05:52AM -0800, Lucas De Marchi wrote:
> Just like in 523e0cc89b83 ("drm/i915/tgl: allow DVI/HDMI on port A"),
> the port checks when reading the VBT can easily not match what the
> platform really exposes. However here we only have some additional debug
> messages that ar
On Thu, Dec 05, 2019 at 01:03:50PM -0800, José Roberto de Souza wrote:
> Commit 9c722e17c1b9 ("drm/i915: Disable pipes in reverse order")
> reverted the order that pipes gets disabled because of TGL
> master/slave relationship between transcoders in MST mode.
>
> But as stated in a comment in skl_
== Series Details ==
Series: series starting with [v3,1/2] drm/i915/perf: Allow non-privileged
access when OA buffer is not sampled
URL : https://patchwork.freedesktop.org/series/70573/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7503 -> Patchwork_15633
Quoting Andi Shyti (2019-12-06 21:24:17)
> From: Andi Shyti
>
> Get rid of the last remaining I915_WRITEs and replace them with
> intel_uncore_write().
>
> Signed-off-by: Andi Shyti
Straightforward translation,
Reviewed-by: Chris Wilson
-Chris
___
I
== Series Details ==
Series: drm/i915/bios: remove extra debug messages
URL : https://patchwork.freedesktop.org/series/70572/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7503 -> Patchwork_15632
Summary
---
**SUCCES
On 11/21/2019 02:43, Michal Wajdeczko wrote:
On Thu, 21 Nov 2019 01:27:23 +0100, wrote:
From: John Harrison
If a FW override is present then a version mis-match is actually
ignored. The warning message was still being printed, though. Which
It wasn't a "warning", just "notice"
could conf
On 11/20/2019 23:23, Chris Wilson wrote:
Quoting john.c.harri...@intel.com (2019-11-21 00:31:42)
From: John Harrison
Added gen & GT info to the error capture.
Signed-off-by: John Harrison
CC: Matthew Brost
---
drivers/gpu/drm/i915/i915_gpu_error.c | 2 ++
1 file changed, 2 insertions(+)
== Series Details ==
Series: drm/i915/bios: remove extra debug messages
URL : https://patchwork.freedesktop.org/series/70572/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
33b3ca89f687 drm/i915/bios: remove extra debug messages
-:6: ERROR:GIT_COMMIT_ID: Please use git commit de
Gen12 supports saving/restoring render counters per context. Apply OAR
configuration only for the context that is passed in to perf.
v2:
- Fix OACTXCONTROL value to only stop/resume counters.
- Remove gen12_update_reg_state_unlocked as power state is already
applied by the caller.
v3: (Lionel)
SAMPLE_OA_REPORT enables sampling of OA reports from the OA buffer.
Since reports from OA buffer had system wide visibility, collecting
samples from the OA buffer was a privileged operation on previous
platforms. Prior to TGL, it was also necessary to sample the OA buffer
to normalize reports from
== Series Details ==
Series: series starting with [1/3] drm/i915/display: move clk off sanitize to
its own function
URL : https://patchwork.freedesktop.org/series/70535/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7495_full -> Patchwork_15626_full
==
Just like in 523e0cc89b83 ("drm/i915/tgl: allow DVI/HDMI on port A"),
the port checks when reading the VBT can easily not match what the
platform really exposes. However here we only have some additional debug
messages that are not adding much value: in the previous debug message
we already print e
On Fri, 6 Dec 2019 at 16:04, Chris Wilson wrote:
>
> Only do the locked compare of the existing fence->error if we actually
> need to set an error. As we tend to call i915_sw_fence_set_error_once()
> unconditionally, it saves on typing to put the common has-error check
> into the inline.
>
> Signe
== Series Details ==
Series: drm/i915/gem: Parallel execbuf WIP.
URL : https://patchwork.freedesktop.org/series/70569/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7500 -> Patchwork_15631
Summary
---
**FAILURE**
Similar to (and in fact copied from) the preparations made to
gem_exec_parse_blt, use a fence to query the result of the execbuf to
accommodate asynchronous command parsing.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
tests/i915/gem_exec_parse.c | 36 ++--
== Series Details ==
Series: drm/i915/gem: Flush the pwrite through the chipset before signaling
URL : https://patchwork.freedesktop.org/series/70532/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7495_full -> Patchwork_15625_full
==
== Series Details ==
Series: drm/i915/gem: Parallel execbuf WIP.
URL : https://patchwork.freedesktop.org/series/70569/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
0c62594b8ba6 drm/i915: Drop inspection of execbuf flags during evict
39b1b1474c8a drm/i915/gem: Extract transient
== Series Details ==
Series: series starting with [1/3] drm/i915: Check for error before calling
cmpxchg()
URL : https://patchwork.freedesktop.org/series/70568/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7500 -> Patchwork_15630
=
From: Chris Wilson
For our convenience, and to avoid frequent allocations, we placed some
lists we use for execbuf inside the common i915_vma struct. As we look
to parallelise execbuf, such fields guarded by the struct_mutex BKL must
be pulled under local control. Instead of using the i915_vma as
i915_gem_ww_ctx is used to lock all gem bo's for pinning and memory
eviction. We don't use it yet, but lets start adding the definition
first.
To use it, we have to pass a non-NULL ww to gem_object_lock, and don't
unlock directly. It is done in i915_gem_ww_ctx_fini.
Signed-off-by: Maarten Lankhor
Execbuffer submission will perform its own WW locking, and we
cannot rely on the implicit lock there.
This also makes it clear that the GVT code will get a lockdep splat when
multiple batchbuffer shadows need to be performed in the same instance,
fix that up.
Signed-off-by: Maarten Lankhorst
---
Doesn't work yet, but shows the direction I'm going.
Instead of relying on struct_mutex, we rely on the object locks to
paralellize submission.
Currently we still have some issues because eb_lookup_vmas() pins the
vma, and parallel submission doesn't work yet completely. I'm hoping
to find out a
Posting this as a RFC, to get some feedback hopefully.
Chris Wilson (2):
drm/i915: Drop inspection of execbuf flags during evict
drm/i915/gem: Extract transient execbuf flags from i915_vma
Maarten Lankhorst (2):
drm/i915: Add an implementation for i915_gem_ww_ctx locking.
drm/i915: Remove
From: Chris Wilson
With the goal of removing the serialisation from around execbuf, we will
no longer have the privilege of there being a single execbuf in flight
at any time and so will only be able to inspect the user's flags within
the carefully controlled execbuf context. i915_gem_evict_for_n
Only do the locked compare of the existing fence->error if we actually
need to set an error. As we tend to call i915_sw_fence_set_error_once()
unconditionally, it saves on typing to put the common has-error check
into the inline.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_sw_fence
If we see an already signaled dma-fence that we want to await on, we skip
adding to the i915_sw_fence. However, we should pay attention to whether
there was an error on that fence and if so propagate it for our future
request.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_sw_fence.c
If we see an already signaled fence that we want to await on, we skip
adding to the i915_sw_fence. However, we should pay attention to whether
there was an error on that fence and if so propagate it for our future
request.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 8 +
== Series Details ==
Series: drm/i915/gt: Trim gen6 ppgtt updates to PD cachelines
URL : https://patchwork.freedesktop.org/series/70531/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7494_full -> Patchwork_15624_full
Summar
== Series Details ==
Series: drm/i915: Fix the use-after-free between i915_active_ref and
__active_retire
URL : https://patchwork.freedesktop.org/series/70563/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7499 -> Patchwork_15629
==
Hi,
i got a X freeze on while using jalv.gtk, dmesg said:
[ 224.178210] i915 :00:02.0: GPU HANG: ecode 4:1:0x9ffdfeff, in
jalv.gtk [2914], hang on rcs0
[ 224.178212] GPU hangs can indicate a bug anywhere in the entire gfx
stack, including userspace.
[ 224.178213] Please file a _new_ bug
== Series Details ==
Series: drm/i915: Avoid calling i915_gem_object_unbind holding object lock
(rev2)
URL : https://patchwork.freedesktop.org/series/70527/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7494_full -> Patchwork_15621_full
===
On Thu, Dec 05, 2019 at 09:33:19PM +0200, Ville Syrjälä wrote:
> On Tue, Dec 03, 2019 at 12:36:26PM -0500, Sean Paul wrote:
> > From: Sean Paul
> >
> > Currently we rely on intel_hdcp_disable() to disable HDCP signalling in
> > the DDI Function Control register. This patch adds a safety net by al
On Thu, Dec 05, 2019 at 09:39:35PM +0200, Ville Syrjälä wrote:
> On Tue, Dec 03, 2019 at 12:36:27PM -0500, Sean Paul wrote:
> > From: Sean Paul
> >
> > Now that we can rely on transcoder disable to toggle signalling off,
> > it's less of a catastrophe if get_hw_state() returns false.
> >
> > Onc
On 06/12/2019 15:22, Lionel Landwerlin wrote:
On 19/11/2019 00:24, Umesh Nerlige Ramappa wrote:
Gen12 supports saving/restoring render counters per context. Apply OAR
configuration only for the context that is passed in to perf.
v2:
- Fix OACTXCONTROL value to only stop/resume counters.
- Remov
On 19/11/2019 00:24, Umesh Nerlige Ramappa wrote:
SAMPLE_OA_REPORT enables sampling of OA reports from the OA buffer.
Since reports from OA buffer had system wide visibility, collecting
samples from the OA buffer was a privileged operation on previous
platforms. Prior to TGL, it was also necessar
On 19/11/2019 00:24, Umesh Nerlige Ramappa wrote:
Gen12 supports saving/restoring render counters per context. Apply OAR
configuration only for the context that is passed in to perf.
v2:
- Fix OACTXCONTROL value to only stop/resume counters.
- Remove gen12_update_reg_state_unlocked as power stat
== Series Details ==
Series: drm/i915/tgl: Program BW_BUDDY registers during display init (rev3)
URL : https://patchwork.freedesktop.org/series/70461/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7494_full -> Patchwork_15620_full
==
On 06/12/2019 12:32, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-11-29 10:54:36)
From: Tvrtko Ursulin
We used to report the minimum possible frequency as both requested and
active while GPU was in sleep state. This was a consequence of sampling
the value from the "current frequency" fiel
Quoting Tvrtko Ursulin (2019-11-29 10:54:36)
> From: Tvrtko Ursulin
>
> We used to report the minimum possible frequency as both requested and
> active while GPU was in sleep state. This was a consequence of sampling
> the value from the "current frequency" field in our software tracking.
>
> Th
Quoting Tvrtko Ursulin (2019-11-29 10:54:36)
> From: Tvrtko Ursulin
>
> We used to report the minimum possible frequency as both requested and
> active while GPU was in sleep state. This was a consequence of sampling
> the value from the "current frequency" field in our software tracking.
>
> Th
On Fri, Dec 06, 2019 at 12:10:15PM +0100, Daniel Vetter wrote:
> On Fri, Dec 6, 2019 at 11:22 AM Gerd Hoffmann wrote:
> >
> > > Guess you kicked CI? Just got CI mails, now reporting success, without
> > > doing anything. So I'll go push v3 to misc-next.
> >
> > Oops, spoke too soon. Next mail a
Quoting Liu, Chuansheng (2019-12-06 12:10:25)
> Chris,
>
> Thanks for reviewing, please see below comments.
>
> > -Original Message-
> > From: Chris Wilson
> > Sent: Friday, December 6, 2019 8:04 PM
> > To: Liu, Chuansheng ; intel-
> > g...@lists.freedesktop.org
> > Subject: Re: [Intel-g
Chris,
Thanks for reviewing, please see below comments.
> -Original Message-
> From: Chris Wilson
> Sent: Friday, December 6, 2019 8:04 PM
> To: Liu, Chuansheng ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Fix the use-after-free between
> i915_active
Quoting Chuansheng Liu (2019-12-06 11:56:35)
> We easily hit drm/i915 panic on TGL when running glmark2, and finally
> caught the race condition of use-after-free with enabling KASAN.
>
> The call stack is below:
> ===
> [ 534.472675] BUG: KASAN: use-after-free in
> __i915_active_fence_set+0x26d
We easily hit drm/i915 panic on TGL when running glmark2, and finally
caught the race condition of use-after-free with enabling KASAN.
The call stack is below:
===
[ 534.472675] BUG: KASAN: use-after-free in
__i915_active_fence_set+0x26d/0x3d0 [i915]
[ 534.472679] Write of size 8 at addr 88
On 06/12/2019 10:55, Chris Wilson wrote:
Before we signal the fence to indicate completion, ensure the pwrite
through the indirect GGTT is coherent (as best as we know) in memory.
Any listeners to the fence may start immediately and sample from the
backing store prior to the writes being posted,
== Series Details ==
Series: series starting with [1/5] drm/i915/gem: Flush the pwrite through the
chipset before signaling
URL : https://patchwork.freedesktop.org/series/70560/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7496 -> Patchwork_15628
On 06/12/2019 11:09, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-12-06 11:02:15)
On 05/12/2019 21:58, Chris Wilson wrote:
Take a wakeref on the intel_gt specifically for the enabled breadcrumb
interrupt so that we can safely process the mmio. If the intel_gt is
already asleep by the time
On 05/12/2019 21:41, Chris Wilson wrote:
Remove the vma we wish to destroy from the gt->closed_list to avoid
having two i915_vma_parked() try and free it.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_vma.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/d
Quoting Tvrtko Ursulin (2019-12-06 11:12:42)
>
> On 05/12/2019 21:41, Chris Wilson wrote:
> > Remove the vma we wish to destroy from the gt->closed_list to avoid
> > having two i915_vma_parked() try and free it.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_vma.c |
On Fri, Dec 6, 2019 at 11:22 AM Gerd Hoffmann wrote:
>
> On Fri, Dec 06, 2019 at 11:07:24AM +0100, Gerd Hoffmann wrote:
> > On Thu, Dec 05, 2019 at 11:15:23PM +0100, Daniel Vetter wrote:
> > > Looks like unrelated flukes, this happens occasionally. If you're paranoid
> > > hit the retest button on
Quoting Tvrtko Ursulin (2019-12-06 11:02:15)
>
> On 05/12/2019 21:58, Chris Wilson wrote:
> > Take a wakeref on the intel_gt specifically for the enabled breadcrumb
> > interrupt so that we can safely process the mmio. If the intel_gt is
> > already asleep by the time we try and setup the breadcru
== Series Details ==
Series: drm/i915/gem: Pin gen6_ppgtt prior to constructing the request (rev2)
URL : https://patchwork.freedesktop.org/series/70526/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7493_full -> Patchwork_15619_full
== Series Details ==
Series: series starting with [1/5] drm/i915/gem: Flush the pwrite through the
chipset before signaling
URL : https://patchwork.freedesktop.org/series/70560/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d30716cc3331 drm/i915/gem: Flush the pwrite through t
On 05/12/2019 21:58, Chris Wilson wrote:
Take a wakeref on the intel_gt specifically for the enabled breadcrumb
interrupt so that we can safely process the mmio. If the intel_gt is
already asleep by the time we try and setup the breadcrumb interrupt, by
a process of elimination we know the reque
On 05/12/2019 18:33, Chris Wilson wrote:
As __active_retire() does it's final atomic_dec() under the
ref->tree_lock spinlock, in order to prevent ourselves from reusing the
ref->cache and ref->tree as they are being destroyed, we need to
serialise with the retirement during i915_active_acquire()
In the extreme case, we may wish to wait on an rcu-barrier to reap stale
vm to purge the last of the object bindings. However, we are not allowed
to use rcu_barrier() beneath the dma_resv (i.e. object) lock and do not
take lightly the prospect of unlocking a mutex deep in the bowels of the
routine.
Remove the vma we wish to destroy from the gt->closed_list to avoid
having two i915_vma_parked() try and free it.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_vma.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/d
Take a wakeref on the intel_gt specifically for the enabled breadcrumb
interrupt so that we can safely process the mmio. If the intel_gt is
already asleep by the time we try and setup the breadcrumb interrupt, by
a process of elimination we know the request must have been completed
and we can skip
All pinning must be done prior to i915_request_create, to avoid
timeline->mutex inversions.
Here we slightly abuse the context_barrier_task stages to utilise the
'skip' decision as an opportunity to acquire the pin on the new ppgtt.
Consider it s/skip/prepare/. At the moment, we only have on user
Before we signal the fence to indicate completion, ensure the pwrite
through the indirect GGTT is coherent (as best as we know) in memory.
Any listeners to the fence may start immediately and sample from the
backing store prior to the writes being posted, thus seeing stale data.
Signed-off-by: Chr
On Fri, Dec 06, 2019 at 11:07:24AM +0100, Gerd Hoffmann wrote:
> On Thu, Dec 05, 2019 at 11:15:23PM +0100, Daniel Vetter wrote:
> > Looks like unrelated flukes, this happens occasionally. If you're paranoid
> > hit the retest button on patchwork to double-check.
> > -Daniel
>
> Guess you kicked CI
On Fri, Dec 6, 2019 at 11:07 AM Gerd Hoffmann wrote:
>
> On Thu, Dec 05, 2019 at 11:15:23PM +0100, Daniel Vetter wrote:
> > On Thu, Nov 28, 2019 at 12:39:30PM +0100, Gerd Hoffmann wrote:
> > > On Wed, Nov 27, 2019 at 10:25:22AM +0100, Gerd Hoffmann wrote:
> > > > The fake offset is going to stay,
== Series Details ==
Series: series starting with [1/4] drm/i915/selftests: Disable heartbeats
around long queues
URL : https://patchwork.freedesktop.org/series/70556/
State : failure
== Summary ==
Applying: drm/i915/selftests: Disable heartbeats around long queues
Applying: drm/i915/selftest
On Thu, Dec 05, 2019 at 11:15:23PM +0100, Daniel Vetter wrote:
> On Thu, Nov 28, 2019 at 12:39:30PM +0100, Gerd Hoffmann wrote:
> > On Wed, Nov 27, 2019 at 10:25:22AM +0100, Gerd Hoffmann wrote:
> > > The fake offset is going to stay, so change the calling convention for
> > > drm_gem_object_funcs.
== Series Details ==
Series: drm: mmap fixups (rev4)
URL : https://patchwork.freedesktop.org/series/69820/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7493_full -> Patchwork_15618_full
Summary
---
**FAILURE**
Se
For some execlists scheduler tests we assume very precise layout of the
inflight queue and become angry if the heartbeat interferes by
reprioritising our contexts (because we happen to be using the same
engine->kernel_context for our test).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt
Avoid spinning indefinitely waiting for the request to be submitted, and
instead apply a timeout. A secondary benefit is that the error message
will show which suspect is blocked.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 26 +-
1 file chang
Only signal the breadcrumbs from inside the irq_work, simplifying our
interface and calling conventions. The micro-optimisation here is that
by always using the irq_work interface, we know we are always inside an
irq-off critical section for the breadcrumb signaling and can ellide
save/restore of t
Skip useless priority bumping on adding a new dependency, but otherwise
prevent tasklet scheduling until we have completed all the potential
rescheduling.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_scheduler.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff -
== Series Details ==
Series: series starting with [v3,1/5] drm/i915/guc: Drop leftover preemption
code
URL : https://patchwork.freedesktop.org/series/70525/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7493_full -> Patchwork_15617_full
===
== Series Details ==
Series: series starting with [1/3] drm/i915/display: move clk off sanitize to
its own function
URL : https://patchwork.freedesktop.org/series/70535/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7495 -> Patchwork_15626
== Series Details ==
Series: drm/i915/gt: Acquire a GT wakeref for the breadcrumb interrupt
URL : https://patchwork.freedesktop.org/series/70524/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7493_full -> Patchwork_15616_full
===
99 matches
Mail list logo
