On Thu, Aug 06, 2020 at 03:43:02PM +0900, Tetsuo Handa wrote:
> As of commit 47ec5303d73ea344 ("Merge
> git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next") on linux.git ,
> my VMware environment cannot boot. Do I need to bisect?
That sounds like a good idea, but please start a new thr
== Series Details ==
Series: drm/i915/gt: Implement WA_1406941453 (rev2)
URL : https://patchwork.freedesktop.org/series/78243/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8846 -> Patchwork_18312
Summary
---
**FAILU
== Series Details ==
Series: drm/i915/gt: Implement WA_1406941453 (rev2)
URL : https://patchwork.freedesktop.org/series/78243/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
From: Clint Taylor
Enable HW Default flip for small PL.
bspec: 52890
bspec: 53508
bspec: 53273
v2: rebase to drm-tip
Reviewed-by: Matt Atwood
Signed-off-by: Clint Taylor
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files cha
== Series Details ==
Series: i915/tgl: Fix TC-cold block/unblock sequence
URL : https://patchwork.freedesktop.org/series/80302/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8845_full -> Patchwork_18311_full
Summary
---
Hi Anitha.
On Mon, Aug 03, 2020 at 09:02:24PM +, Chrisanthus, Anitha wrote:
> Hi Sam,
> I installed codespell, but the dictionary.txt in
> usr/share/codespell/dictionary.txt
> seems to be different from yours. Mine is version 1.8. Where can I get the
> dictionary.txt
> that you are using?
I
== Series Details ==
Series: Replace obj->mm.lock with reservation_ww_class
URL : https://patchwork.freedesktop.org/series/80291/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8845_full -> Patchwork_18310_full
Summary
-
== Series Details ==
Series: HDCP minor refactoring (rev3)
URL : https://patchwork.freedesktop.org/series/77224/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8845_full -> Patchwork_18309_full
Summary
---
**FAILURE**
Hi, Chris,
On 8/5/20 2:21 PM, Chris Wilson wrote:
Long story short, we need to manage evictions using dma_resv & dma_fence
tracking. The backing storage will then be managed using the ww_mutex
borrowed from (and shared via) obj->base.resv, rather than the current
obj->mm.lock.
Skipping over th
Hi, Chris,
On 8/5/20 2:22 PM, Chris Wilson wrote:
Acquire all the objects and their backing storage, and page directories,
as used by execbuf under a single common ww_mutex. Albeit we have to
restart the critical section a few times in order to handle various
restrictions (such as avoiding copy_
== Series Details ==
Series: i915/tgl: Fix TC-cold block/unblock sequence
URL : https://patchwork.freedesktop.org/series/80302/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8845 -> Patchwork_18311
Summary
---
**SUCC
== Series Details ==
Series: i915/tgl: Fix TC-cold block/unblock sequence
URL : https://patchwork.freedesktop.org/series/80302/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
___
== Series Details ==
Series: i915/tgl: Fix TC-cold block/unblock sequence
URL : https://patchwork.freedesktop.org/series/80302/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
26989606f3cd i915/tgl: Fix TC-cold block/unblock sequence
-:52: WARNING:MSLEEP: msleep < 20ms can sleep
On 05/08/2020 13:21, Chris Wilson wrote:
Since preempt-to-busy, we may unsubmit a request while it is still on
the HW and completes asynchronously. That means it may be retired and in
the process destroy the virtual engine (as the user has closed their
context), but that engine may still be hol
On 05/08/2020 13:21, Chris Wilson wrote:
Allow a brief period for continued access to a dead intel_context by
deferring the release of the struct until after an RCU grace period.
As we are using a dedicated slab cache for the contexts, we can defer
the release of the slab pages via RCU, with th
On 05/08/2020 13:21, Chris Wilson wrote:
As we now protect the timeline list using RCU, we can drop the
timeline->mutex for guarding the list iteration during context close, as
we are searching for an inflight request. Any new request will see the
context is banned and not be submitted. In doin
The command register is the low PCODE MBOX low register not the high
one as described by the spec. This left the system with the TC-cold
power state being blocked all the time. Fix things by using the correct
register.
Also to make sure we retry a request for at least 600usec, when the
PCODE MBOX
Hi Oleksandr,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-exynos/exynos-drm-next]
[also build test WARNING on drm-intel/for-linux-next
tegra-drm/drm/tegra/for-next drm-tip/drm-tip linus/master v5.8 next-20200804]
[cannot apply to xen-tip/linux-next drm/drm-ne
On 05/08/2020 13:22, Chris Wilson wrote:
Since we can control placement in the ppGTT explicitly, we can specify
our desired starting offset exactly on a per-vma basis. This prevents us
falling down a few corner cases where we confuse the user with our choices.
Signed-off-by: Chris Wilson
---
On 05/08/2020 13:22, Chris Wilson wrote:
Allocate a few dma fence context id that we can use to associate async work
[for the CPU] launched on behalf of this context. For extra fun, we allow
a configurable concurrency width.
A current example would be that we spawn an unbound worker for every
On 05/08/2020 13:22, Chris Wilson wrote:
Currently, if an error is raised we always call the cleanup locally
[and skip the main work callback]. However, some future users may need
to take a mutex to cleanup and so we cannot immediately execute the
cleanup as we may still be in interrupt context
On 05/08/2020 13:22, Chris Wilson wrote:
Directly seralise the atomic pinning with evicting the vma from unbind
with a pair of coupled cmpxchg to avoid fighting over vm->mutex.
Assumption being bind/unbind should never contend and create a
busy-spinny section? And motivation being.. ?
Sig
On 7/28/2020 3:04 AM, Daniel Vetter wrote:
On Mon, Jul 27, 2020 at 2:27 PM Michel Dänzer wrote:
On 2020-07-25 1:26 a.m., Paulo Zanoni wrote:
Em seg, 2020-07-20 às 17:01 +0530, Karthik B S escreveu:
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 1fa677
On 7/27/2020 5:57 PM, Michel Dänzer wrote:
On 2020-07-25 1:26 a.m., Paulo Zanoni wrote:
Em seg, 2020-07-20 às 17:01 +0530, Karthik B S escreveu:
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 1fa67700d8f4..95953b393941 100644
--- a/drivers/gpu/drm/i915/i
On 7/25/2020 4:56 AM, Paulo Zanoni wrote:
Em seg, 2020-07-20 às 17:01 +0530, Karthik B S escreveu:
Add enable/disable flip done functions and the flip done handler
function which handles the flip done interrupt.
Enable the flip done interrupt in IER.
Enable flip done function is called befor
On 2020-08-05 at 17:15:21 +0530, Anshuman Gupta wrote:
> HDCP code doesn't require to access power_well internal stuff,
> instead it should use the intel_display_power_well_is_enabled()
> to get the status of desired power_well.
> No functional change.
>
> v2:
> - used with_intel_runtime_pm instea
On 05/08/2020 13:22, Chris Wilson wrote:
The reloc_cache contains some details that are used outside of the
relocation handling, so lift those out of the embeddded struct into the
principle struct i915_execbuffer.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c
On 05/08/2020 13:22, Chris Wilson wrote:
Continuing the theme of calling the lists a foo_list, rename the relocs
list. This means that we can now use relocs for the old reloc_cache that
is not a cache anymore.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c |
On 2020-08-05 at 17:15:20 +0530, Anshuman Gupta wrote:
> Currently intel_hdcp_update_pipe() is also getting called for non-hdcp
> connectors and get through its conditional code flow, which is completely
> unnecessary for non-hdcp connectors, therefore it make sense to
> have an early return. No fu
== Series Details ==
Series: Replace obj->mm.lock with reservation_ww_class
URL : https://patchwork.freedesktop.org/series/80291/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8845 -> Patchwork_18310
Summary
---
**SU
== Series Details ==
Series: Replace obj->mm.lock with reservation_ww_class
URL : https://patchwork.freedesktop.org/series/80291/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
_
== Series Details ==
Series: Replace obj->mm.lock with reservation_ww_class
URL : https://patchwork.freedesktop.org/series/80291/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
fa0ff87bd9b0 drm/i915/gem: Reduce context termination list iteration guard to
RCU
-:20: WARNING:COMMI
== Series Details ==
Series: HDCP minor refactoring (rev3)
URL : https://patchwork.freedesktop.org/series/77224/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8845 -> Patchwork_18309
Summary
---
**SUCCESS**
No reg
Currently, if an error is raised we always call the cleanup locally
[and skip the main work callback]. However, some future users may need
to take a mutex to cleanup and so we cannot immediately execute the
cleanup as we may still be in interrupt context. For example, if we have
committed sensitive
One more list iterator variant, for when we want to unwind from inside
one list iterator with the intention of restarting from the current
entry as the new head of the list.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/i915_util
It is illegal to wait on an another vma while holding the vm->mutex, as
that easily leads to ABBA deadlocks (we wait on a second vma that waits
on us to release the vm->mutex). So while the vm->mutex exists, we
compute the required register transfer inside the i915_ggtt.mutex, setting
up a fence fo
Pull the individual acquisition of the context objects (state, ring,
timeline) under a common i915_acquire_ctx in preparation to allow the
context to evict memory (or rather the i915_acquire_ctx on its behalf).
The context objects maintain their semi-permanent status; that is they
are assumed to b
Obsolete, last user removed.
Signed-off-by: Chris Wilson
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_gem_evict.c | 57 ---
.../gpu/drm/i915/selftests/i915_gem_evict.c | 40 -
3 files chan
Our goal is to pull all memory reservations (next iteration
obj->ops->get_pages()) under a ww_mutex, and to align those reservations
with other drivers, i.e. control all such allocations with the
reservation_ww_class. Currently, this is under the purview of the
obj->mm.mutex, and while obj->mm rema
From: Matthew Auld
We need to general our accessor for the page directories and tables from
using the simple kmap_atomic to support local memory, and this setup
must be done on acquisition of the backing storage prior to entering
fence execution contexts. Here we replace the kmap with the object
Allocate a few dma fence context id that we can use to associate async work
[for the CPU] launched on behalf of this context. For extra fun, we allow
a configurable concurrency width.
A current example would be that we spawn an unbound worker for every
userptr get_pages. In the future, we wish to
As we now protect the timeline list using RCU, we can drop the
timeline->mutex for guarding the list iteration during context close, as
we are searching for an inflight request. Any new request will see the
context is banned and not be submitted. In doing so, pull the checks for
a concurrent submis
Pull the individual strands of creating a custom heartbeat requests into
a pair of common functions. This will reduce the number of changes we
will need to make in future.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 59 +--
1 file changed, 41 i
As we funnel more and more contexts into the breadcrumbs on an engine,
the hold time of b->irq_lock grows. As we may then contend with the
b->irq_lock during request submission, this increases the burden upon
the engine->active.lock and so directly impacts both our execution
latency and client late
Make b->signaled_requests a lockless-list so that we can manipulate it
outside of the b->irq_lock.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 28 +++
.../gpu/drm/i915/gt/intel_breadcrumbs_types.h | 2 +-
drivers/gpu/drm/i915/i915_request.h
Allow a brief period for continued access to a dead intel_context by
deferring the release of the struct until after an RCU grace period.
As we are using a dedicated slab cache for the contexts, we can defer
the release of the slab pages via RCU, with the caveat that individual
structs may be reuse
Continuing the theme of calling the lists a foo_list, rename the relocs
list. This means that we can now use relocs for the old reloc_cache that
is not a cache anymore.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 8
1 file changed, 4 insertions(+), 4
Remove the stub i915_vma_pin() used for incrementally pinning objects for
execbuf (under the severe restriction that they must not wait on a
resource as we may have already pinned it) and replace it with a
i915_vma_pin_inplace() that is only allowed to reclaim the currently
bound location for the v
Rename the current list of unbound objects so that we can track of all
objects that we need to bind, as well as the list of currently unbound
[unprocessed] objects.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_execb
Acquire all the objects and their backing storage, and page directories,
as used by execbuf under a single common ww_mutex. Albeit we have to
restart the critical section a few times in order to handle various
restrictions (such as avoiding copy_(from|to)_user and mmap_sem).
Signed-off-by: Chris W
On the fast path, we first try to pin the user pages and then attach the
mmu-notifier. On the slow path, we did it the opposite way around,
carrying the mmu-notifier over from the tail of the fast path. However,
if we are mapping a fresh batch of user pages, we will always hit a pmd
split operation
Since we can control placement in the ppGTT explicitly, we can specify
our desired starting offset exactly on a per-vma basis. This prevents us
falling down a few corner cases where we confuse the user with our choices.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c
Now that the page directories are backed by an object, and we wish to
acquire multiple objects together under the same acquire context, teach
i915_vm_map_pt_stash() to use i915_acquire_ctx.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +-
drivers/gpu/drm/i91
From: Maarten Lankhorst
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.
Chan
The reloc_cache contains some details that are used outside of the
relocation handling, so lift those out of the embeddded struct into the
principle struct i915_execbuffer.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 61 +++
.../i915/gem/selfte
Since preempt-to-busy, we may unsubmit a request while it is still on
the HW and completes asynchronously. That means it may be retired and in
the process destroy the virtual engine (as the user has closed their
context), but that engine may still be holding onto the unsubmitted
compelted request.
It is reasonably common for userspace (even modern drivers like iris) to
reuse an active address for a new buffer. This would cause the
application to stall under its mutex (originally struct_mutex) until the
old batches were idle and it could synchronously remove the stale PTE.
However, we can que
Pull the GGTT binding for the secure batch dispatch into the common vma
pinning routine for execbuf, so that there is just a single central
place for all i915_vma_pin().
Signed-off-by: Chris Wilson
Reviewed-by: Thomas Hellström
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 88 +++-
Directly seralise the atomic pinning with evicting the vma from unbind
with a pair of coupled cmpxchg to avoid fighting over vm->mutex.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_vma.c | 45 ++---
1 file changed, 14 insertions(+), 31 deletions(-)
diff
The prospect of locking the entire submission sequence under a wide
ww_mutex re-imposes some key restrictions, in particular that we must
not call copy_(from|to)_user underneath the mutex (as the faulthandlers
themselves may need to take the ww_mutex). To satisfy this requirement,
we need to split
Pull the cmdparser allocations in to the reservation phase, and then
they are included in the common vma pinning pass.
Signed-off-by: Chris Wilson
Reviewed-by: Thomas Hellström
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 360 +++---
drivers/gpu/drm/i915/gem/i915_gem_object.h
The Global GTT mmapings do not require any backing storage for the page
directories and so do not need extensive support for preallocations, or
for handling multiple bindings en masse. The Global GTT bindings also
need to take into account an eviction strategy for pinned vma, that we
want to explic
Long story short, we need to manage evictions using dma_resv & dma_fence
tracking. The backing storage will then be managed using the ww_mutex
borrowed from (and shared via) obj->base.resv, rather than the current
obj->mm.lock.
Skipping over the breadcrumbs, the first step is to remove the final
c
Move the register slow register write and readback from out of the
critical path for execlists submission and delay it until the following
worker, shaving off around 200us. Note that the same signal_irq_work() is
allowed to run concurrently on each CPU (but it will only be queued once,
once running
We currently want to keep the interrupt enabled until the interrupt after
which we have no more work to do. This heuristic was broken by us
kicking the irq-work on adding a completed request without attaching a
signaler -- hence it appearing to the irq-worker that an interrupt had
fired when we wer
Now that we have pushed the binding itself outside of the vm->mutex, we
are clear of the potential wakeref inversions and can take the wakeref
around the actual duration of the HW interaction.
Signed-off-by: Chris Wilson
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 3
The obj->resv->lock does not serialisation anything within
intel_unpin_fb_vma(), so remove the redundant contention point.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/display/intel_display.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display
As a prelude to the next step where we want to perform all the object
allocations together under the same lock, we first must delay the
i915_vma_pin() as that implicitly does the allocations for us, one by
one. As it only does the allocations one by one, it is not allowed to
wait/evict, whereas pul
Rather than synchronously wait for the context to be bound, within the
intel_context_pin(), we can track the pending completion of the bind
fence and only submit requests along the context when signaled.
Signed-off-by: Chris Wilson
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile
Our timeline lock is our defence against a concurrent execbuf
interrupting our request construction. we need hold it throughout or,
for example, a second thread may interject a relocation request in
between our own relocation request and execution in the ring.
A second, major benefit, is that it a
In preparation for making eb_vma bigger and heavy to run in parallel,
we need to stop applying an in-place swap() to reorder around ww_mutex
deadlocks. Keep the array intact and reorder the locks using a dedicated
list.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
Reviewed-by: Thomas
Quoting Thomas Hellström (Intel) (2020-07-29 14:44:41)
>
> On 7/29/20 2:17 PM, Tvrtko Ursulin wrote:
> >
> > On 28/07/2020 12:17, Thomas Hellström (Intel) wrote:
> >> On 7/16/20 5:53 PM, Tvrtko Ursulin wrote:
> >>> On 15/07/2020 16:43, Maarten Lankhorst wrote:
> Op 15-07-2020 om 13:51 schreef
Currently intel_hdcp_update_pipe() is also getting called for non-hdcp
connectors and get through its conditional code flow, which is completely
unnecessary for non-hdcp connectors, therefore it make sense to
have an early return. No functional change.
v2:
- rebased.
Reviewed-by: Uma Shankar
Sig
HDCP code doesn't require to access power_well internal stuff,
instead it should use the intel_display_power_well_is_enabled()
to get the status of desired power_well.
No functional change.
v2:
- used with_intel_runtime_pm instead of get/put. [Jani]
v3:
- rebased.
Cc: Jani Nikula
Signed-off-by:
No functional change.
Anshuman Gupta (2):
drm/i915/hdcp: Add update_pipe early return
drm/i915/hdcp: No direct access to power_well desc
drivers/gpu/drm/i915/display/intel_hdcp.c | 23 +--
1 file changed, 9 insertions(+), 14 deletions(-)
--
2.26.2
_
== Series Details ==
Series: drm/i915/gt: Prevent immediate reuse of the last context tag
URL : https://patchwork.freedesktop.org/series/80277/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8844 -> Patchwork_18308
Summary
-
drm-misc-next-fixes-2020-08-05:
drm-misc-next-fixes for v5.9-rc1:
- Fix drm_dp_mst_port refcount leaks in drm_dp_mst_allocate_vcpi
- Fix a fbcon OOB read in fbdev, found by syzbot.
- Mark vga_tryget static as it's not used elsewhere.
- Small fixes to xlnx.
- Remove null check for kfree in drm_dev_r
== Series Details ==
Series: drm/i915/gt: Prevent immediate reuse of the last context tag
URL : https://patchwork.freedesktop.org/series/80277/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
___
Quoting Chris Wilson (2020-08-05 09:37:51)
> While we only release the context tag after we have processed the
> context-switch event away from the context, be paranoid in case that
> value remains live in HW and so avoid reusing the last tag for the next
> context after a brief idle.
>
Fixes: 5c
While we only release the context tag after we have processed the
context-switch event away from the context, be paranoid in case that
value remains live in HW and so avoid reusing the last tag for the next
context after a brief idle.
Signed-off-by: Chris Wilson
Cc: Ramalingam C
---
drivers/gpu
Hi,
Here's to only include gvt fixes for 5.9-rc1. Two fixes to make
guest suspend/resume working gracefully are included.
Thanks
--
The following changes since commit e57bd05ec0d2d82d63725dedf9f5a063f879de25:
drm/i915: Update DRIVER_DATE to 20200715 (2020-07-15 14:18:02 +0300)
are available
81 matches
Mail list logo
