Chris Wilson writes:
> Repeat our sanitychecks from before execution to after execution. One
> expects that if we were to see these, the gpu would already be on fire,
> but the timing may be informative.
>
> Signed-off-by: Chris Wilson
> Reviewed-by: Tvrtko Ursulin
Noticed that it had a tag af
Chris Wilson writes:
> When running gem_exec_nop, it floods the system with many requests (with
> the goal of userspace submitting faster than the HW can process a single
> empty batch). This causes the driver to continually resubmit new
> requests onto the end of an active context, a flood of li
On 2020-10-16 14:37, Zhenyu Wang wrote:
On 2020.10.16 14:20:29 +0800, Colin Xu wrote:
On 2020-10-16 13:54, Zhenyu Wang wrote:
On 2020.10.16 13:59:59 +0800, Colin Xu wrote:
This patch save/restore necessary GVT info during i915 suspend/resume so
that GVT enabled QEMU VM can continue running.
This patchset enables GVT suspend/resume so that GVT enabled VM can
continue running after host resuming from suspend state.
V2:
- Change kzalloc/kfree to vzalloc/vfree since the space allocated
from kmalloc may not enough for all saved GGTT entries.
- Keep gvt suspend/resume wrapper in intel_gvt.
This patch save/restore necessary GVT info during i915 suspend/resume so
that GVT enabled QEMU VM can continue running.
Only GGTT and fence regs are saved/restored now. GVT will save GGTT
entries into GVT in suspend routine, and restore the saved entries
and re-init fence regs in resume routine.
This patch add gvt suspend/resume wrapper into i915: i915_drm_suspend()
and i915_drm_resume(). GVT relies on i915 so suspend gvt ahead of other
i915 sub-routine and resume gvt at last.
V2:
- Direct call into gvt suspend/resume wrapper in intel_gvt.h/intel_gvt.c.
The wrapper and implementation will
On 2020-10-16 16:13, Colin Xu wrote:
This patch add gvt suspend/resume wrapper into i915: i915_drm_suspend()
and i915_drm_resume(). GVT relies on i915 so suspend gvt ahead of other
i915 sub-routine and resume gvt at last.
V2:
- Direct call into gvt suspend/resume wrapper in intel_gvt.h/intel_g
Quoting Shi, Yang A (2020-10-16 02:08:24)
> Hi Chris:
>
> How to determine the length of the magic delay in here?
That is the question. I started with a large udelay, played with moving
it around and shortening (5us) to try and isolate what is going on. An
arbitrary delay is awful
On 16/10/2020 05:07, Zbigniew Kempczyński wrote:
> On Thu, Oct 15, 2020 at 09:09:02AM +0100, Tvrtko Ursulin wrote:
>>
>> On 15/10/2020 05:36, Zbigniew Kempczyński wrote:
>>> On Wed, Oct 14, 2020 at 11:48:53AM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Adding a new device sel
During error capture, we need to take a reference to the vma from the
before the reset in order to catpure the contents of the vma later.
Currently we are using both an active reference and a kref, but due to
nature of the i915_vma reference handling, that kref is on the vma->obj
and not the vma it
== Series Details ==
Series: drm/i915: Use the active reference on the vma while capturing
URL : https://patchwork.freedesktop.org/series/82763/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
edea817e95d8 drm/i915: Use the active reference on the vma while capturing
-:14: WARNIN
== Series Details ==
Series: drm/i915: Use the active reference on the vma while capturing
URL : https://patchwork.freedesktop.org/series/82763/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9145 -> Patchwork_18711
Summary
We're starting to require the reservation lock for pinning,
so wait until we have that.
Update the selftests to handle this correctly, and ensure pin is
called in live_hwsp_rollover_user() and mock_hwsp_freelist().
Changes since v1:
- Fix NULL + XX arithmatic, use casts. (kbuild)
Changes since v2
Take a simple lock so we hold ww around (un)pin_pages as needed.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 5aa037
Userptr should not need the kernel for a userspace memcpy, userspace
needs to call memcpy directly.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_object_types.h | 2 ++
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 20 +++
drivers/gpu/drm/i915/i915_gem.c
pin_map needs the ww lock, so ensure we pin both before submission.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_object.h| 3 +
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 12 +++
.../gpu/drm/i915/gt/selftest_workarounds.c| 76 ---
3 files c
We should not allow this any more, as it will break with the new userptr
implementation, it could still be made to work, but there's no point in
doing so.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +
drivers/gpu/drm/i915/gem/i915_gem_object.h| 4
vmap is using pin_pages, but needs to use ww locking,
add pin_pages_unlocked to correctly lock the mapping.
Also add ww locking to begin/end cpu access.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 60 --
1 file changed, 33 insertions(+),
Take the ww lock around engine_unpark. Because of the
many many places where rpm is used, I chose the safest option
and used a trylock to opportunistically take this lock for
__engine_unpark.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 4 +++-
1 file changed,
Pin in the caller, not in the work itself. This should also
work better for dma-fence annotations.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_ge
Finally there, just needs a lot of fixes!
A lot of places were calling certain calls without any object lock held,
with the removal of mm.lock we can no longer do this, and have to fix it.
Phys page handling has to be redone, as nothing protects obj->ops structure,
we have to remove swapping it,
Currently we have a lot of places where we hold the gem object lock,
but haven't yet been converted to the ww dance. Complain loudly about
those places.
i915_vma_pin shouldn't have the obj lock held, so we can do a ww dance,
while i915_vma_pin_ww should.
Signed-off-by: Maarten Lankhorst
---
dri
Because of the long lifetime of the mapping, we cannot wrap this in a
simple limited ww lock. Just use the unlocked version of pin_map,
because we'll likely release the mapping a lot later, in a different
thread.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_dsb.c | 2 +
Instead of sharing pages with breadcrumbs, give each timeline a
single page. This allows unrelated timelines not to share locks
any more during command submission.
As an additional benefit, seqno wraparound no longer requires
i915_vma_pin, which means we no longer need to worry about a
potential -
Convert a single pin_pages call to use the unlocked version.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_object.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_object.c
b/drivers/gpu/drm/i915/
We want to remove the changing of ops structure for attaching
phys pages, so we need to kill off HAS_STRUCT_PAGE from ops->flags,
and put it in the bo.
This will remove a potential race of dereferencing the wrong obj->ops
without ww mutex held.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/d
As soon as we install fences, we should stop allocating memory
in order to prevent any potential deadlocks.
This is required later on, when we start adding support for
dma-fence annotations.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 24 ++--
By default, we assume that it's called inside igt_create_request
to keep existing selftests working, but allow for manual pinning
when passing a ww context.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/selftests/igt_spinner.c | 136 ---
drivers/gpu/drm/i915/selftests
i915_vma_pin may fail with -EDEADLK when we start locking page tables,
so ensure we handle this correctly.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 23 +++
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i
Use pin_pages_unlocked() where we don't have a lock.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/self
We are removing obj->mm.lock, and need to take the reservation lock
before we can pin pages. Move the pinning pages into the helper, and
merge gtt pwrite/pread preparation and cleanup paths.
The fence lock is also removed; it will conflict with fence annotations,
because of memory allocations done
We map the initial context during first pin.
This allows us to remove pin_map from state allocation, which saves
us a few retry loops. We won't need this until first pin anyway.
intel_ring_submission_setup() is also reworked slightly to do all
pinning in a single ww loop.
Changes since v1:
- Han
We need to lock a few more objects, some temporarily,
add ww lock where needed.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_perf.c | 56
1 file changed, 43 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/
Straightforward conversion, just convert a bunch of calls to
unlocked versions.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_co
Straightforward conversion, just convert a bunch of calls to
unlocked versions.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coheren
Also quite simple, a single call needs to use the unlocked version.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_execbuffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_execbuffer.c
b/driver
Make creation separate from pinning, in order to take the lock only
once, and pin the mapping with the lock held.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 43 ++---
1 file changed, 33 insertions(+), 10 deletions(-)
diff --git a/drivers/g
We need to get rid of allocations in the cmd parser, because it needs
to be called from a signaling context, first move all pinning to
execbuf, where we already hold all locks.
Allocate jump_whitelist in the execbuffer, and add annotations around
intel_engine_cmd_parser(), to ensure we only call t
Simple adding of i915_gem_object_lock, we may start to pass ww to
get_pages() in the future, but that won't be the case here;
We override shmem's get_pages() handling by calling
i915_gem_object_get_pages_phys(), no ww is needed.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_
Quick fix, just use the unlocked version.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/shmem_utils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/shmem_utils.c
b/drivers/gpu/drm/i915/gt/shmem_utils.c
index 43c7acbdc79d..8c8dfa41e032
Use the unlocked variants for pin_map and pin_pages, and add lock
around unpinning/putting pages.
Signed-off-by: Maarten Lankhorst
---
.../drm/i915/selftests/intel_memory_region.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/selft
Use pin_map_unlocked when we're not holding locks.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/selftest_mocs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_mocs.c
b/drivers/gpu/drm/i915/gt/selftest_mocs.c
index b25eba50c88
Straightforward conversion, just convert a bunch of calls to
unlocked versions.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/selftests/huge_pages.c | 28 ++-
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_page
i915_gem_object_pin_map potentially needs a ww context, so ensure we
have one we can revoke.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_g
Ensure we hold the lock around put_pages, and use the unlocked wrappers
for pinning pages and mappings.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/
Same as other tests, use pin_map_unlocked.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_engine_cs.c
b/drivers/gpu/drm/i915/gt/selftest_engine_cs.c
index
Try to pin to ggtt first, and use a full ww loop to handle
eviction correctly.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 37 +++
1 file changed, 24 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b
We need to lock the global gtt dma_resv, use i915_vm_lock_objects
to handle this correctly. Add ww handling for this where required.
Add the object lock around unpin/put pages, and use the unlocked
versions of pin_pages and pin_map where required.
Signed-off-by: Maarten Lankhorst
---
drivers/gp
Convert a few calls to use the unlocked versions.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
b/drivers/gpu/drm/i915/gt/selftest_hangche
Convert normal functions to unlocked versions where needed.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/
It doesn't make sense to export a memory address, we will prevent
allowing access this way to different address spaces when we
rework userptr handling, so best to explicitly disable it.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 5 ++---
1 file changed, 2
We need to take the obj lock to pin pages, so wait until the callers
have done so, before making the object unshrinkable.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +
.../gpu/drm/i915/gem/i915_gem_object_blt.c| 6 +++
.../gpu/drm/i915/gt/intel_g
Only needs to convert a single call to the unlocked version.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/selftest_context.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_context.c
b/drivers/gpu/drm/i915/gt/selftest_cont
Doesn't need the full ww lock, only checking if pages are bound.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_gem.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index bb0c12975f38..3
In the ucode functions, the calls are done before userspace runs,
when debugging using debugfs, or when creating semi-permanent mappings;
we can safely use the unlocked versions that does the ww dance for us.
Because there is no pin_pages_unlocked yet, add it as convenience function.
This removes
We can no longer call intel_timeline_pin with a null argument,
so add a ww loop that locks the backing object.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/selftest_timeline.c | 26 ++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/d
Straightforward conversion, just convert a bunch of calls to
unlocked versions.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_cl
This should be done as part of the ww loop, in order to remove a
i915_vma_pin that needs ww held.
Now only i915_ggtt_pin() callers remaining.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 24 --
.../gpu/drm/i915/gt/selftest_workarounds.c
We need to lock the object to move it to the correct domain,
add the missing lock.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/d
Use unlocked versions when the ww lock is not held.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/selftest_ring_submission.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_ring_submission.c
b/drivers/gpu/drm/i915/gt/selfte
igt_emit_store_dw needs to use the unlocked version, as it's not
holding a lock. This fixes igt_gpu_fill_dw() which is used by
some other selftests.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/selftests/igt_gem_utils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Instead of multiple lockings, lock the object once,
and perform the ww dance around attach_phys and pin_pages.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_display.c | 69 ---
drivers/gpu/drm/i915/display/intel_display.h | 2 +-
drivers/gpu/drm/i915/
We may create page table objects on the fly, but we may need to
wait with the ww lock held. Instead of waiting on a freed obj
lock, ensure we have the same lock for each object to keep
-EDEADLK working. This ensures that i915_vma_pin_ww can lock
the page tables when required.
Signed-off-by: Maarte
With all callers and selftests fixed to use ww locking, we can now
finally remove this lock.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_object.c| 2 -
drivers/gpu/drm/i915/gem/i915_gem_object.h| 5 +--
.../gpu/drm/i915/gem/i915_gem_object_types.h | 1 -
dr
From: Thomas Hellström
Stolen objects need to lock, and we may call put_pages when
refcount drops to 0, ensure all calls are handled correctly.
Idea-from: Thomas Hellström
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 14 ++
drivers/gpu/drm/i915
We previously complained when ww == NULL.
This function is now only used in selftests to pin an object,
and ww locking is now fixed.
Signed-off-by: Maarten Lankhorst
---
.../i915/gem/selftests/i915_gem_coherency.c | 14 +
drivers/gpu/drm/i915/i915_gem.c | 6 +-
Instead of creating a separate object type, we make changes to
the shmem type, to clear struct page backing. This will allow us to
ensure we never run into a race when we exchange obj->ops with other
function pointers.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_object
With userptr fixed, there is no need for all separate lockdep classes
now, and we can remove all lockdep tricks used. A trylock in the
shrinker is all we need now to flatten the locking hierarchy.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 6 +---
driver
Allow set_domain to fail silently, waiting for idle should be good enough.
set_tiling and set_caching are rejected with -ENXIO, there's no valid reason
to allow it.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_domain.
Instead of doing what we do currently, which will never work with
PROVE_LOCKING, do the same as AMD does, and something similar to
relocation slowpath. When all locks are dropped, we acquire the
pages for pinning. When the locks are taken, we transfer those
pages in .get_pages() to the bo. As a fin
Use some unlocked versions where we're not holding the ww lock.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c
b/driv
Instead of force unbinding and rebinding every time, we try to check
if our notifier seqcount is still correct when pages are bound. This
way we only rebind userptr when we need to, and prevent stalls.
Changes since v1:
- Missing mutex_unlock, reported by kbuild.
Reported-by: kernel test robot
R
This allows us to remove pin_map from state allocation, which saves
us a few retry loops. We won't need this until first pin, anyway.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 13 ++-
drivers/gpu/drm/i915/gt/intel_lrc.c | 107 +---
Straightforward conversion by using unlocked versions.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/selftests/i915_request.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c
b/drivers/gpu/drm/i915/selftests
== Series Details ==
Series: drm/i915: Remove obj->mm.lock! (rev4)
URL : https://patchwork.freedesktop.org/series/82337/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/generated/compile.h
CC [M] d
Instead of sharing pages with breadcrumbs, give each timeline a
single page. This allows unrelated timelines not to share locks
any more during command submission.
As an additional benefit, seqno wraparound no longer requires
i915_vma_pin, which means we no longer need to worry about a
potential -
+ Lionel
Can you please take a look at best resolving the below problem.
Maybe we should eliminate the duplicate declarations? Updating such
a list manually seems error prone to me.
Regards, Joonas
Quoting Mauro Carvalho Chehab (2020-10-13 14:53:59)
> As reported by Sphinx:
>
> ./Docum
== Series Details ==
Series: drm/i915: Remove obj->mm.lock! (rev5)
URL : https://patchwork.freedesktop.org/series/82337/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/generated/compile.h
CC [M] d
== Series Details ==
Series: drm/i915: Use the active reference on the vma while capturing
URL : https://patchwork.freedesktop.org/series/82763/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9145_full -> Patchwork_18711_full
When allocating objects from stolen, memset() the backing store to
POISON_INUSE (0x5a) to help identify any uninitialised use of a stolen
object.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 45 ++
1 file changed, 45
The GPU is trashing the low pages of its reserved memory upon reset. If
we are using this memory for ringbuffers, then we will dutiful resubmit
the trashed rings after the reset causing further resets, and worse. We
must exclude this range from our own use. The value of 128KiB was found
by empirica
On 16/10/2020 14:37, Mauro Carvalho Chehab wrote:
Em Fri, 16 Oct 2020 14:01:07 +0300
Joonas Lahtinen escreveu:
+ Lionel
Can you please take a look at best resolving the below problem.
Maybe we should eliminate the duplicate declarations? Updating such
a list manually seems error prone to me.
On Fri, 16 Oct 2020, Lionel Landwerlin wrote:
> On 16/10/2020 14:37, Mauro Carvalho Chehab wrote:
>> Em Fri, 16 Oct 2020 14:01:07 +0300
>> Joonas Lahtinen escreveu:
>>
>>> + Lionel
>>>
>>> Can you please take a look at best resolving the below problem.
>>>
>>> Maybe we should eliminate the duplic
On Fri, Oct 16, 2020 at 10:11:04AM +0100, Tvrtko Ursulin wrote:
>
> On 16/10/2020 05:07, Zbigniew Kempczyński wrote:
> > On Thu, Oct 15, 2020 at 09:09:02AM +0100, Tvrtko Ursulin wrote:
> >>
> >> On 15/10/2020 05:36, Zbigniew Kempczyński wrote:
> >>> On Wed, Oct 14, 2020 at 11:48:53AM +0100, Tvrtko
== Series Details ==
Series: series starting with [1/2] drm/i915/gem: Poison stolen pages before use
URL : https://patchwork.freedesktop.org/series/82769/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
66cd9f3821f0 drm/i915/gem: Poison stolen pages before use
-:38: WARNING:MEMOR
On 16/10/2020 14:50, Jani Nikula wrote:
On Fri, 16 Oct 2020, Lionel Landwerlin wrote:
On 16/10/2020 14:37, Mauro Carvalho Chehab wrote:
Em Fri, 16 Oct 2020 14:01:07 +0300
Joonas Lahtinen escreveu:
+ Lionel
Can you please take a look at best resolving the below problem.
Maybe we should eli
== Series Details ==
Series: series starting with [1/2] drm/i915/gem: Poison stolen pages before use
URL : https://patchwork.freedesktop.org/series/82769/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separa
On 13/10/2020 14:53, Mauro Carvalho Chehab wrote:
As reported by Sphinx:
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1147:
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_oa_wait_unlocked'.
./Documentation/gpu/i915:
== Series Details ==
Series: series starting with [1/2] drm/i915/gem: Poison stolen pages before use
URL : https://patchwork.freedesktop.org/series/82769/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9147 -> Patchwork_18714
We're starting to require the reservation lock for pinning,
so wait until we have that.
Update the selftests to handle this correctly, and ensure pin is
called in live_hwsp_rollover_user() and mock_hwsp_freelist().
Changes since v1:
- Fix NULL + XX arithmatic, use casts. (kbuild)
Changes since v2
== Series Details ==
Series: drm/i915: Remove obj->mm.lock! (rev6)
URL : https://patchwork.freedesktop.org/series/82337/
State : failure
== Summary ==
Applying: drm/i915: Move cmd parser pinning to execbuffer
Applying: drm/i915: Add missing -EDEADLK handling to execbuf pinning
Applying: drm/i9
To try and avoid too rapid change causing premature heart attacks, let
us flush the old heartbeat before changing the interval.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/d
== Series Details ==
Series: drm/i915/gt: Flush the old heartbeat on interval change
URL : https://patchwork.freedesktop.org/series/82772/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9147 -> Patchwork_18716
Summary
--
On Fri, 16 Oct 2020 at 10:25, Chris Wilson wrote:
>
> During error capture, we need to take a reference to the vma from the
> before the reset in order to catpure the contents of the vma later.
> Currently we are using both an active reference and a kref, but due to
> nature of the i915_vma refere
Take the ww lock around engine_unpark. Because of the
many many places where rpm is used, I chose the safest option
and used a trylock to opportunistically take this lock for
__engine_unpark.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 4
1 file changed,
We're starting to require the reservation lock for pinning,
so wait until we have that.
Update the selftests to handle this correctly, and ensure pin is
called in live_hwsp_rollover_user() and mock_hwsp_freelist().
Changes since v1:
- Fix NULL + XX arithmatic, use casts. (kbuild)
Changes since v2
If linux is running as a guest and the host is doing igd pass-through
with VT-d enabled, this message is logged dozens of times per second.
Cc: sta...@vger.kernel.org
Signed-off-by: Stefan Fritsch
---
The i915 driver should also detect VT-d in this case, but that is a
different issue. I have se
Dear Ville Syrjälä,
Thank you for responding so quickly.
I was occupied with work and life for the past two weeks, sorry about
the wait, but have now managed to find some time to continue pursuing
this issue again.
On Thu, 2020-10-01 at 18:23 +0300, Ville Syrjälä wrote:
> Argh. If only I had mana
Hi,
if Linux is running as a guest and the host is doing igd-pass-thorugh with
VT-d enabled, the i915 driver does not work all that great. The most
obvious problem is that there are dozens of 'Fault errors on pipe A'
errrors logged per second, but depending on the hardware there can be
other i
Em Fri, 16 Oct 2020 14:01:07 +0300
Joonas Lahtinen escreveu:
> + Lionel
>
> Can you please take a look at best resolving the below problem.
>
> Maybe we should eliminate the duplicate declarations? Updating such
> a list manually seems error prone to me.
For Kernel 5.10, IMO the best is to app
1 - 100 of 130 matches
Mail list logo
