Re: [Intel-gfx] [PATCH v2 1/4] i915: Move list_count() to list.h for broader use
>-Original Message-
>From: dri-devel On Behalf Of
>Andy Shevchenko
>Sent: Monday, November 14, 2022 11:22 AM
>To: Jakob Koschel ; Andy Shevchenko
>; Greg Kroah-Hartman
>; Mathias Nyman
>; intel-gfx@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org; linux-ker...@vger.kernel.org; linux-
>u...@vger.kernel.org
>Cc: Tvrtko Ursulin ; Kevin Cernekee
>; Nyman, Mathias ; Vivi,
>Rodrigo ; Andrew Morton foundation.org>
>Subject: [PATCH v2 1/4] i915: Move list_count() to list.h for broader use
>
>Some of the existing users, and definitely will be new ones, want to
>count existing nodes in the list. Provide a generic API for that by
>moving code from i915 to list.h.
>
>Signed-off-by: Andy Shevchenko
>---
>v2: dropped the duplicate code in i915 (LKP)
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 13 +
> include/linux/list.h | 13 +
> 2 files changed, 14 insertions(+), 12 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>index 6ae8b07cfaa1..b5d474be564d 100644
>--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>@@ -2085,17 +2085,6 @@ static void print_request_ring(struct drm_printer
>*m, struct i915_request *rq)
> }
> }
>
>-static unsigned long list_count(struct list_head *list)
>-{
>- struct list_head *pos;
>- unsigned long count = 0;
>-
>- list_for_each(pos, list)
>- count++;
>-
>- return count;
>-}
>-
> static unsigned long read_ul(void *p, size_t x)
> {
> return *(unsigned long *)(p + x);
>@@ -2270,7 +2259,7 @@ void intel_engine_dump(struct intel_engine_cs
>*engine,
> spin_lock_irqsave(>sched_engine->lock, flags);
> engine_dump_active_requests(engine, m);
>
>- drm_printf(m, "\tOn hold?: %lu\n",
>+ drm_printf(m, "\tOn hold?: %zu\n",
> list_count(>sched_engine->hold));
> spin_unlock_irqrestore(>sched_engine->lock, flags);
>
>diff --git a/include/linux/list.h b/include/linux/list.h
>index 61762054b4be..098eccf8c1b6 100644
>--- a/include/linux/list.h
>+++ b/include/linux/list.h
>@@ -655,6 +655,19 @@ static inline void list_splice_tail_init(struct list_head
>*list,
>!list_is_head(pos, (head)); \
>pos = n, n = pos->prev)
>
>+/**
>+ * list_count - count nodes in the list
>+ * @head: the head for your list.
>+ */
>+#define list_count(head) \
>+({\
>+ struct list_head *__tmp;\
>+ size_t __i = 0; \
>+ list_for_each(__tmp, head) \
>+ __i++; \
>+ __i;\
>+})
So all of the non-list_for_each code appears to be an inline.
This which, resembles the non-list_for_each pattern is a macro?
Just curious as to why the macro rather than inline?
Mike
+
> /**
> * list_entry_is_head - test if the entry points to the head of the list
> * @pos: the type * to cursor
>--
>2.35.1
Re: [Intel-gfx] [PATCH v2 2/4] drm/i915/selftests: exercise GPU access from the importer
>-Original Message-
>From: Auld, Matthew
>Sent: Friday, October 28, 2022 11:50 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Landwerlin, Lionel G ; Tvrtko Ursulin
>; Ville Syrjälä
>;
>Ruhl, Michael J
>Subject: [PATCH v2 2/4] drm/i915/selftests: exercise GPU access from the
>importer
>
>Using PAGE_SIZE here potentially hides issues so bump that to something
>larger. This should also make it possible for iommu to coalesce entries
>for us. With that in place verify we can write from the GPU using the
>importers sg_table, followed by checking that our writes match when read
>from the CPU side.
>
>v2: Switch over to igt_gpu_fill_dw(), which looks to be more widely
>supported than the migrate stuff (at least OOTB).
>
>References: https://gitlab.freedesktop.org/drm/intel/-/issues/7306
>Signed-off-by: Matthew Auld
>Cc: Lionel Landwerlin
>Cc: Tvrtko Ursulin
>Cc: Ville Syrjälä
>Cc: Michael J. Ruhl
>---
> .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 79
>++-
> 1 file changed, 78 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>index f2f3cfad807b..e57f9390076c 100644
>--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>@@ -6,8 +6,12 @@
>
> #include "i915_drv.h"
> #include "i915_selftest.h"
>+#include "gem/i915_gem_context.h"
>
>+#include "mock_context.h"
> #include "mock_dmabuf.h"
>+#include "igt_gem_utils.h"
>+#include "selftests/mock_drm.h"
> #include "selftests/mock_gem_device.h"
>
> static int igt_dmabuf_export(void *arg)
>@@ -140,6 +144,75 @@ static int
>igt_dmabuf_import_same_driver_lmem(void *arg)
> return err;
> }
>
>+static int verify_access(struct drm_i915_private *i915,
>+ struct drm_i915_gem_object *native_obj,
>+ struct drm_i915_gem_object *import_obj)
>+{
>+ struct i915_gem_engines_iter it;
>+ struct i915_gem_context *ctx;
>+ struct intel_context *ce;
>+ struct i915_vma *vma;
>+ struct file *file;
>+ u32 *vaddr;
>+ int err = 0, i;
>+
>+ file = mock_file(i915);
>+ if (IS_ERR(file))
>+ return PTR_ERR(file);
>+
>+ ctx = live_context(i915, file);
>+ if (IS_ERR(ctx)) {
>+ err = PTR_ERR(ctx);
>+ goto out_file;
>+ }
>+
>+ for_each_gem_engine(ce, i915_gem_context_lock_engines(ctx), it) {
>+ if (intel_engine_can_store_dword(ce->engine))
>+ break;
>+ }
>+ i915_gem_context_unlock_engines(ctx);
>+ if (!ce)
>+ goto out_file;
>+
>+ vma = i915_vma_instance(import_obj, ce->vm, NULL);
>+ if (IS_ERR(vma)) {
>+ err = PTR_ERR(vma);
>+ goto out_file;
>+ }
>+
>+ err = i915_vma_pin(vma, 0, 0, PIN_USER);
>+ if (err)
>+ goto out_file;
>+
>+ err = igt_gpu_fill_dw(ce, vma, 0,
>+vma->size >> PAGE_SHIFT, 0xdeadbeaf);
>+ i915_vma_unpin(vma);
>+ if (err)
>+ goto out_file;
>+
>+ err = i915_gem_object_wait(import_obj, 0,
>MAX_SCHEDULE_TIMEOUT);
>+ if (err)
>+ goto out_file;
>+
>+ vaddr = i915_gem_object_pin_map_unlocked(native_obj,
>I915_MAP_WB);
>+ if (IS_ERR(vaddr)) {
>+ err = PTR_ERR(vaddr);
>+ goto out_file;
>+ }
>+
>+ for (i = 0; i < native_obj->base.size / sizeof(u32); i += PAGE_SIZE /
>sizeof(u32)) {
>+ if (vaddr[i] != 0xdeadbeaf) {
>+ pr_err("Data mismatch [%d]=%u\n", i, vaddr[i]);
>+ err = -EINVAL;
>+ goto out_file;
>+ }
Not sure what timing issues are related to this test, but this loop could have
some impact (takes a long time, assuming the object is LMEM).
Would checking the beginning, middle and end of each page be any less
beneficial than the current check?
Not a suggested change, but just a thought to ponder if the timing becomes
an issue...
This test looks reasonable to me.
Reviewed-by: Michael J. Ruhl
M
>+ }
>+
>+out_file:
>+ fput(file);
>+ return err;
>+}
>+
> static int igt_dmabuf_import_same_driver(struct drm_i915_private *i915,
>struct intel_memory_region
>**regions,
>unsigned int num_regions)
>@@ -154,7 +227,7
Re: [Intel-gfx] [PATCH v2 1/4] drm/i915/dmabuf: fix sg_table handling in map_dma_buf
>-Original Message-
>From: Auld, Matthew
>Sent: Friday, October 28, 2022 11:50 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Landwerlin, Lionel G ; Tvrtko Ursulin
>; Ville Syrjälä
>;
>Ruhl, Michael J
>Subject: [PATCH v2 1/4] drm/i915/dmabuf: fix sg_table handling in
>map_dma_buf
>
>We need to iterate over the original entries here for the sg_table,
>pulling out the struct page for each one, to be remapped. However
>currently this incorrectly iterates over the final dma mapped entries,
>which is likely just one gigantic sg entry if the iommu is enabled,
>leading to us only mapping the first struct page (and any physically
>contiguous pages following it), even if there is potentially lots more
>data to follow.
I like this patch set a lot better.
Reviewed-by: Michael J. Ruhl
M
>Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7306
>Signed-off-by: Matthew Auld
>Cc: Lionel Landwerlin
>Cc: Tvrtko Ursulin
>Cc: Ville Syrjälä
>Cc: Michael J. Ruhl
>---
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>index 07eee1c09aaf..05ebbdfd3b3b 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>@@ -40,13 +40,13 @@ static struct sg_table *i915_gem_map_dma_buf(struct
>dma_buf_attachment *attachme
> goto err;
> }
>
>- ret = sg_alloc_table(st, obj->mm.pages->nents, GFP_KERNEL);
>+ ret = sg_alloc_table(st, obj->mm.pages->orig_nents, GFP_KERNEL);
> if (ret)
> goto err_free;
>
> src = obj->mm.pages->sgl;
> dst = st->sgl;
>- for (i = 0; i < obj->mm.pages->nents; i++) {
>+ for (i = 0; i < obj->mm.pages->orig_nents; i++) {
> sg_set_page(dst, sg_page(src), src->length, 0);
> dst = sg_next(dst);
> src = sg_next(src);
>--
>2.37.3
Re: [Intel-gfx] [PATCH 1/2] drm/i915/dmabuf: fix sg_table handling in map_dma_buf
>-Original Message-
>From: Intel-gfx On Behalf Of
>Matthew Auld
>Sent: Thursday, October 27, 2022 11:27 AM
>To: intel-gfx@lists.freedesktop.org
>Subject: [Intel-gfx] [PATCH 1/2] drm/i915/dmabuf: fix sg_table handling in
>map_dma_buf
>
>We need to iterate over the original entries here for the sg_table,
>pulling out the struct page for each one, to be remapped. However
>currently this incorrectly iterates over the final dma mapped entries,
>which is likely just one gigantic sg entry if the iommu is enabled,
>leading to us only mapping the first struct page (and any physically
>contiguous pages following it), even if there is potentially lots more
>data to follow.
>
>Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7306
>Signed-off-by: Matthew Auld
>Cc: Lionel Landwerlin
>Cc: Tvrtko Ursulin
>Cc: Ville Syrjälä
>---
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>index 07eee1c09aaf..05ebbdfd3b3b 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>@@ -40,13 +40,13 @@ static struct sg_table *i915_gem_map_dma_buf(struct
>dma_buf_attachment *attachme
> goto err;
> }
>
>- ret = sg_alloc_table(st, obj->mm.pages->nents, GFP_KERNEL);
>+ ret = sg_alloc_table(st, obj->mm.pages->orig_nents, GFP_KERNEL);
> if (ret)
> goto err_free;
>
> src = obj->mm.pages->sgl;
> dst = st->sgl;
>- for (i = 0; i < obj->mm.pages->nents; i++) {
>+ for (i = 0; i < obj->mm.pages->orig_nents; i++) {
This really should use the for_each_sg() macro.
I proposed a clean up patch a while back that looked like this:
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index e2cdc2640c08..ccc5d46aa749 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include "gem/i915_gem_dmabuf.h"
#include "i915_drv.h"
@@ -41,12 +42,10 @@ static struct sg_table *i915_gem_map_dma_buf(struct
dma_buf_attachment *attach,
if (ret)
goto err_free;
- src = obj->mm.pages->sgl;
dst = sgt->sgl;
- for (i = 0; i < obj->mm.pages->nents; i++) {
+ for_each_sg(obj->mm.pages->sgl, src, obj->mm.pages->nents, i) {
sg_set_page(dst, sg_page(src), src->length, 0);
dst = sg_next(dst);
- src = sg_next(src);
}
If you are updating the for loop, this might be a reasonable update as well.
Mike
> sg_set_page(dst, sg_page(src), src->length, 0);
> dst = sg_next(dst);
> src = sg_next(src);
>--
>2.37.3
Re: [Intel-gfx] [PATCH v5 06/21] drm/i915: Prepare to dynamic dma-buf locking specification
>-Original Message-
>From: Dmitry Osipenko
>Sent: Tuesday, September 13, 2022 3:28 PM
>To: David Airlie ; Gerd Hoffmann ;
>Gurchetan Singh ; Chia-I Wu
>; Daniel Vetter ; Daniel Almeida
>; Gert Wollny ;
>Gustavo Padovan ; Daniel Stone
>; Tomeu Vizoso ;
>Maarten Lankhorst ; Maxime Ripard
>; Thomas Zimmermann ;
>Rob Clark ; Sumit Semwal
>; Christian König ;
>Pan, Xinhui ; Thierry Reding
>; Tomasz Figa ; Marek
>Szyprowski ; Mauro Carvalho Chehab
>; Alex Deucher ; Jani
>Nikula ; Joonas Lahtinen
>; Vivi, Rodrigo ;
>Tvrtko Ursulin ; Thomas Hellström
>; Qiang Yu ; Srinivas
>Kandagatla ; Amol Maheshwari
>; Jason Gunthorpe ; Leon
>Romanovsky ; Gross, Jurgen ; Stefano
>Stabellini ; Oleksandr Tyshchenko
>; Tomi Valkeinen ;
>Russell King ; Lucas Stach ;
>Christian Gmeiner ; Ruhl, Michael J
>
>Cc: dri-de...@lists.freedesktop.org; linux-ker...@vger.kernel.org; Dmitry
>Osipenko ; linux-me...@vger.kernel.org; linaro-mm-
>s...@lists.linaro.org; amd-...@lists.freedesktop.org; intel-
>g...@lists.freedesktop.org; ker...@collabora.com; virtualization@lists.linux-
>foundation.org; linux-r...@vger.kernel.org; linux-arm-
>m...@vger.kernel.org
>Subject: [PATCH v5 06/21] drm/i915: Prepare to dynamic dma-buf locking
>specification
>
>Prepare i915 driver to the common dynamic dma-buf locking convention
>by starting to use the unlocked versions of dma-buf API functions
>and handling cases where importer now holds the reservation lock.
>
>Acked-by: Christian König
>Signed-off-by: Dmitry Osipenko
>---
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_object.c | 14 ++
> .../gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 16
> 3 files changed, 23 insertions(+), 9 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>index f5062d0c6333..07eee1c09aaf 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>@@ -72,7 +72,7 @@ static int i915_gem_dmabuf_vmap(struct dma_buf
>*dma_buf,
> struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
> void *vaddr;
>
>- vaddr = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB);
>+ vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
> if (IS_ERR(vaddr))
> return PTR_ERR(vaddr);
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>index 85482a04d158..7cab89618bad 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>@@ -290,7 +290,21 @@ void __i915_gem_object_pages_fini(struct
>drm_i915_gem_object *obj)
> __i915_gem_object_free_mmaps(obj);
>
> atomic_set(>mm.pages_pin_count, 0);
>+
>+ /*
>+ * dma_buf_unmap_attachment() requires reservation to be
>+ * locked. The imported GEM shouldn't share reservation lock
>+ * and ttm_bo_cleanup_memtype_use() shouldn't be invoked for
>+ * dma-buf, so it's safe to take the lock.
>+ */
>+ if (obj->base.import_attach)
>+ i915_gem_object_lock(obj, NULL);
>+
> __i915_gem_object_put_pages(obj);
>+
>+ if (obj->base.import_attach)
>+ i915_gem_object_unlock(obj);
>+
> GEM_BUG_ON(i915_gem_object_has_pages(obj));
> }
Hi Dmitry,
I think that this looks correct and reasonable.
Reviewed-by: Michael J. Ruhl
m
>diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>index 51ed824b020c..f2f3cfad807b 100644
>--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>@@ -213,7 +213,7 @@ static int igt_dmabuf_import_same_driver(struct
>drm_i915_private *i915,
> goto out_import;
> }
>
>- st = dma_buf_map_attachment(import_attach,
>DMA_BIDIRECTIONAL);
>+ st = dma_buf_map_attachment_unlocked(import_attach,
>DMA_BIDIRECTIONAL);
> if (IS_ERR(st)) {
> err = PTR_ERR(st);
> goto out_detach;
>@@ -226,7 +226,7 @@ static int igt_dmabuf_import_same_driver(struct
>drm_i915_private *i915,
> timeout = -ETIME;
> }
> err = timeout > 0 ? 0 : timeout;
>- dma_buf_unmap_attachment(import_attach, st,
>DMA_BIDIRECTIONAL);
>+ dma_buf_unmap_attachment_unlocked(import_attach, st,
>DMA_BIDIRECTIONAL);
> out_detach:
> dma_buf_detach(dmabuf, import_attach);
> out_import:
>@@ -296,7 +296,7 @@ static int igt_dmabuf_import(void *arg)
> goto out_obj
Re: [Intel-gfx] [PATCH v2 01/12] drm/i915: Move locking and unclaimed check into mmio_debug_{suspend, resume}
>-Original Message-
>From: Roper, Matthew D
>Sent: Tuesday, September 6, 2022 1:09 PM
>To: Ruhl, Michael J
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Sripada,
>Radhakrishna
>Subject: Re: [PATCH v2 01/12] drm/i915: Move locking and unclaimed check
>into mmio_debug_{suspend, resume}
>
>On Tue, Sep 06, 2022 at 06:39:14AM -0700, Ruhl, Michael J wrote:
>> >-Original Message-
>> >From: dri-devel On Behalf Of
>> >Matt Roper
>> >Sent: Friday, September 2, 2022 7:33 PM
>> >To: intel-gfx@lists.freedesktop.org
>> >Cc: dri-de...@lists.freedesktop.org; Sripada, Radhakrishna
>> >
>> >Subject: [PATCH v2 01/12] drm/i915: Move locking and unclaimed check
>into
>> >mmio_debug_{suspend, resume}
>> >
>> >Moving the locking for MMIO debug (and the final check for unclaimed
>> >accesses when resuming debug after a userspace-initiated forcewake) will
>> >make it simpler to completely skip MMIO debug handling on uncores that
>> >don't support it in future patches.
>> >
>> >Signed-off-by: Matt Roper
>> >Reviewed-by: Radhakrishna Sripada
>> >---
>> > drivers/gpu/drm/i915/intel_uncore.c | 41 +++--
>> > 1 file changed, 21 insertions(+), 20 deletions(-)
>> >
>> >diff --git a/drivers/gpu/drm/i915/intel_uncore.c
>> >b/drivers/gpu/drm/i915/intel_uncore.c
>> >index 9b81b2543ce2..e717ea55484a 100644
>> >--- a/drivers/gpu/drm/i915/intel_uncore.c
>> >+++ b/drivers/gpu/drm/i915/intel_uncore.c
>> >@@ -50,23 +50,33 @@ intel_uncore_mmio_debug_init_early(struct
>> >intel_uncore_mmio_debug *mmio_debug)
>> >mmio_debug->unclaimed_mmio_check = 1;
>> > }
>> >
>> >-static void mmio_debug_suspend(struct intel_uncore_mmio_debug
>> >*mmio_debug)
>> >+static void mmio_debug_suspend(struct intel_uncore *uncore)
>>
>> /bike-shedding...
>>
>> It seems like there has been a tend to name functions with the
>>
>> _unlocked
>>
>> postfix when the lock is being taken within the function.
>>
>> Would this be a reasonable name update for these changes?
>
>I think foo_unlocked() naming is usually used when there's also a
>separate foo() that can be called if/when locks are already held (or
>sometimes it's foo() and foo_locked() if the situation is the other way
>around). In this case we still only have one version of the function,
>and it's only called from a single place in the code
>(intel_uncore_forcewake_user_get) so I don't think the special naming is
>necessary. It might actually add confusion here since there's a
>different lock (the general uncore lock) that is still held by the
>caller. It's just the mmio_debug-specific lock that's been moved into
>the mmio-debug specific function here.
Got it. That makes sense.
Thanks,
Mike
>
>Matt
>
>>
>> M
>>
>> > {
>> >- lockdep_assert_held(_debug->lock);
>> >+ spin_lock(>debug->lock);
>> >
>> >/* Save and disable mmio debugging for the user bypass */
>> >- if (!mmio_debug->suspend_count++) {
>> >- mmio_debug->saved_mmio_check = mmio_debug-
>> >>unclaimed_mmio_check;
>> >- mmio_debug->unclaimed_mmio_check = 0;
>> >+ if (!uncore->debug->suspend_count++) {
>> >+ uncore->debug->saved_mmio_check = uncore->debug-
>> >>unclaimed_mmio_check;
>> >+ uncore->debug->unclaimed_mmio_check = 0;
>> >}
>> >+
>> >+ spin_unlock(>debug->lock);
>> > }
>> >
>> >-static void mmio_debug_resume(struct intel_uncore_mmio_debug
>> >*mmio_debug)
>> >+static bool check_for_unclaimed_mmio(struct intel_uncore *uncore);
>> >+
>> >+static void mmio_debug_resume(struct intel_uncore *uncore)
>> > {
>> >- lockdep_assert_held(_debug->lock);
>> >+ spin_lock(>debug->lock);
>> >+
>> >+ if (!--uncore->debug->suspend_count)
>> >+ uncore->debug->unclaimed_mmio_check = uncore->debug-
>> >>saved_mmio_check;
>> >
>> >- if (!--mmio_debug->suspend_count)
>> >- mmio_debug->unclaimed_mmio_check = mmio_debug-
>> >>saved_mmio_check;
>> >+ if (check_for_unclaimed_mmio(uncore))
>> >+ drm_info(>i915->drm,
>> >+"Invalid mmio detected during user access\n");
>> >+
>&
Re: [Intel-gfx] [PATCH v2 01/12] drm/i915: Move locking and unclaimed check into mmio_debug_{suspend, resume}
>-Original Message-
>From: dri-devel On Behalf Of
>Matt Roper
>Sent: Friday, September 2, 2022 7:33 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: dri-de...@lists.freedesktop.org; Sripada, Radhakrishna
>
>Subject: [PATCH v2 01/12] drm/i915: Move locking and unclaimed check into
>mmio_debug_{suspend, resume}
>
>Moving the locking for MMIO debug (and the final check for unclaimed
>accesses when resuming debug after a userspace-initiated forcewake) will
>make it simpler to completely skip MMIO debug handling on uncores that
>don't support it in future patches.
>
>Signed-off-by: Matt Roper
>Reviewed-by: Radhakrishna Sripada
>---
> drivers/gpu/drm/i915/intel_uncore.c | 41 +++--
> 1 file changed, 21 insertions(+), 20 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_uncore.c
>b/drivers/gpu/drm/i915/intel_uncore.c
>index 9b81b2543ce2..e717ea55484a 100644
>--- a/drivers/gpu/drm/i915/intel_uncore.c
>+++ b/drivers/gpu/drm/i915/intel_uncore.c
>@@ -50,23 +50,33 @@ intel_uncore_mmio_debug_init_early(struct
>intel_uncore_mmio_debug *mmio_debug)
> mmio_debug->unclaimed_mmio_check = 1;
> }
>
>-static void mmio_debug_suspend(struct intel_uncore_mmio_debug
>*mmio_debug)
>+static void mmio_debug_suspend(struct intel_uncore *uncore)
/bike-shedding...
It seems like there has been a tend to name functions with the
_unlocked
postfix when the lock is being taken within the function.
Would this be a reasonable name update for these changes?
M
> {
>- lockdep_assert_held(_debug->lock);
>+ spin_lock(>debug->lock);
>
> /* Save and disable mmio debugging for the user bypass */
>- if (!mmio_debug->suspend_count++) {
>- mmio_debug->saved_mmio_check = mmio_debug-
>>unclaimed_mmio_check;
>- mmio_debug->unclaimed_mmio_check = 0;
>+ if (!uncore->debug->suspend_count++) {
>+ uncore->debug->saved_mmio_check = uncore->debug-
>>unclaimed_mmio_check;
>+ uncore->debug->unclaimed_mmio_check = 0;
> }
>+
>+ spin_unlock(>debug->lock);
> }
>
>-static void mmio_debug_resume(struct intel_uncore_mmio_debug
>*mmio_debug)
>+static bool check_for_unclaimed_mmio(struct intel_uncore *uncore);
>+
>+static void mmio_debug_resume(struct intel_uncore *uncore)
> {
>- lockdep_assert_held(_debug->lock);
>+ spin_lock(>debug->lock);
>+
>+ if (!--uncore->debug->suspend_count)
>+ uncore->debug->unclaimed_mmio_check = uncore->debug-
>>saved_mmio_check;
>
>- if (!--mmio_debug->suspend_count)
>- mmio_debug->unclaimed_mmio_check = mmio_debug-
>>saved_mmio_check;
>+ if (check_for_unclaimed_mmio(uncore))
>+ drm_info(>i915->drm,
>+ "Invalid mmio detected during user access\n");
>+
>+ spin_unlock(>debug->lock);
> }
>
> static const char * const forcewake_domain_names[] = {
>@@ -677,9 +687,7 @@ void intel_uncore_forcewake_user_get(struct
>intel_uncore *uncore)
> spin_lock_irq(>lock);
> if (!uncore->user_forcewake_count++) {
> intel_uncore_forcewake_get__locked(uncore,
>FORCEWAKE_ALL);
>- spin_lock(>debug->lock);
>- mmio_debug_suspend(uncore->debug);
>- spin_unlock(>debug->lock);
>+ mmio_debug_suspend(uncore);
> }
> spin_unlock_irq(>lock);
> }
>@@ -695,14 +703,7 @@ void intel_uncore_forcewake_user_put(struct
>intel_uncore *uncore)
> {
> spin_lock_irq(>lock);
> if (!--uncore->user_forcewake_count) {
>- spin_lock(>debug->lock);
>- mmio_debug_resume(uncore->debug);
>-
>- if (check_for_unclaimed_mmio(uncore))
>- drm_info(>i915->drm,
>- "Invalid mmio detected during user
>access\n");
>- spin_unlock(>debug->lock);
>-
>+ mmio_debug_resume(uncore);
> intel_uncore_forcewake_put__locked(uncore,
>FORCEWAKE_ALL);
> }
> spin_unlock_irq(>lock);
>--
>2.37.2
Re: [Intel-gfx] [PATCH v4 06/21] drm/i915: Prepare to dynamic dma-buf locking specification
>-Original Message- >From: Dmitry Osipenko >Sent: Friday, September 2, 2022 6:39 AM >To: Ruhl, Michael J ; Dmitry Osipenko >; Jani Nikula ; >Joonas Lahtinen ; Vivi, Rodrigo >; Tvrtko Ursulin ; >Thomas Hellström ; Christian König >; Chris Wilson >Cc: dri-de...@lists.freedesktop.org; linux-ker...@vger.kernel.org; linux- >me...@vger.kernel.org; linaro-mm-...@lists.linaro.org; amd- >g...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; >ker...@collabora.com; virtualizat...@lists.linux-foundation.org; linux- >r...@vger.kernel.org; linux-arm-...@vger.kernel.org; David Airlie >; Gerd Hoffmann ; Gurchetan Singh >; Chia-I Wu ; Daniel >Vetter ; Daniel Almeida ; >Gert Wollny ; Gustavo Padovan >; Daniel Stone ; >Tomeu Vizoso ; Maarten Lankhorst >; Maxime Ripard >; Thomas Zimmermann ; >Rob Clark ; Sumit Semwal >; Pan, Xinhui ; Thierry >Reding ; Tomasz Figa ; >Marek Szyprowski ; Mauro Carvalho Chehab >; Alex Deucher ; >Qiang Yu ; Srinivas Kandagatla >; Amol Maheshwari >; Jason Gunthorpe ; Leon >Romanovsky ; Gross, Jurgen ; Stefano >Stabellini ; Oleksandr Tyshchenko >; Tomi Valkeinen ; >Russell King ; Lucas Stach ; >Christian Gmeiner >Subject: Re: [PATCH v4 06/21] drm/i915: Prepare to dynamic dma-buf locking >specification > >02.09.2022 13:31, Dmitry Osipenko пишет: >> 01.09.2022 17:02, Ruhl, Michael J пишет: >> ... >>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c >>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c >>>> @@ -331,7 +331,19 @@ static void __i915_gem_free_objects(struct >>>> drm_i915_private *i915, >>>>continue; >>>>} >>>> >>>> + /* >>>> + * dma_buf_unmap_attachment() requires reservation to be >>>> + * locked. The imported GEM shouldn't share reservation lock, >>>> + * so it's safe to take the lock. >>>> + */ >>>> + if (obj->base.import_attach) >>>> + i915_gem_object_lock(obj, NULL); >>> >>> There is a lot of stuff going here. Taking the lock may be premature... >>> >>>>__i915_gem_object_pages_fini(obj); >>> >>> The i915_gem_dmabuf.c:i915_gem_object_put_pages_dmabuf is where >>> unmap_attachment is actually called, would it make more sense to make >>> do the locking there? >> >> The __i915_gem_object_put_pages() is invoked with a held reservation >> lock, while freeing object is a special time when we know that GEM is >> unused. >> >> The __i915_gem_free_objects() was taking the lock two weeks ago until >> the change made Chris Wilson [1] reached linux-next. >> >> [1] >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux- >next.git/commit/?id=2826d447fbd60e6a05e53d5f918bceb8c04e315c >> >> I don't think we can take the lock within >> i915_gem_object_put_pages_dmabuf(), it may/should deadlock other code >paths. > >On the other hand, we can check whether the GEM's refcount number is >zero in i915_gem_object_put_pages_dmabuf() and then take the lock if >it's zero. > >Also, seems it should be possible just to bail out from >i915_gem_object_put_pages_dmabuf() if refcount=0. The further >drm_prime_gem_destroy() will take care of unmapping. Perhaps this could >be the best option, I'll give it a test. i915_gem_object_put_pages() is uses the SG, and the usage for drm_prim_gem_destroy() from __i915_gem_free_objects() doesn't use the SG because it has been "freed" already, I am not sure if that would work... Hmm.. with that in mind, maybe moving the base.import_attach check to __i915_gem_object_put_pages with your attach check? atomic_set(>mm.pages_pin_count, 0); if (obj->base.import) i915_gem_object_lock(obj, NULL); __i915_gem_object_put_pages(obj); if (obj->base.import) i915_gem_object_unlock(obj, NULL); GEM_BUG_ON(i915_gem_object_has_pages(obj)); Pretty much one step up from the dmabuf interface, but we are guaranteed to not have any pinned pages? The other caller of __i915_gem_object_pages_fini is the i915_ttm move_notify which should not conflict (export side, not import side). Since it appears that not locking during the clean up is desirable, trying to make sure take the lock is taken at the last moment might be the right path? M
Re: [Intel-gfx] [PATCH v4 06/21] drm/i915: Prepare to dynamic dma-buf locking specification
>-Original Message-
>From: Dmitry Osipenko
>Sent: Wednesday, August 31, 2022 11:38 AM
>To: David Airlie ; Gerd Hoffmann ;
>Gurchetan Singh ; Chia-I Wu
>; Daniel Vetter ; Daniel Almeida
>; Gert Wollny ;
>Gustavo Padovan ; Daniel Stone
>; Tomeu Vizoso ;
>Maarten Lankhorst ; Maxime Ripard
>; Thomas Zimmermann ;
>Rob Clark ; Sumit Semwal
>; Christian König ;
>Pan, Xinhui ; Thierry Reding
>; Tomasz Figa ; Marek
>Szyprowski ; Mauro Carvalho Chehab
>; Alex Deucher ; Jani
>Nikula ; Joonas Lahtinen
>; Vivi, Rodrigo ;
>Tvrtko Ursulin ; Thomas Hellström
>; Qiang Yu ; Srinivas
>Kandagatla ; Amol Maheshwari
>; Jason Gunthorpe ; Leon
>Romanovsky ; Gross, Jurgen ; Stefano
>Stabellini ; Oleksandr Tyshchenko
>; Tomi Valkeinen ;
>Russell King ; Lucas Stach ;
>Christian Gmeiner
>Cc: dri-de...@lists.freedesktop.org; linux-ker...@vger.kernel.org; Dmitry
>Osipenko ; linux-me...@vger.kernel.org; linaro-mm-
>s...@lists.linaro.org; amd-...@lists.freedesktop.org; intel-
>g...@lists.freedesktop.org; ker...@collabora.com; virtualization@lists.linux-
>foundation.org; linux-r...@vger.kernel.org; linux-arm-
>m...@vger.kernel.org
>Subject: [PATCH v4 06/21] drm/i915: Prepare to dynamic dma-buf locking
>specification
>
>Prepare i915 driver to the common dynamic dma-buf locking convention
>by starting to use the unlocked versions of dma-buf API functions
>and handling cases where importer now holds the reservation lock.
>
>Signed-off-by: Dmitry Osipenko
>---
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_object.c | 12
> .../gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 16
> 3 files changed, 21 insertions(+), 9 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>index f5062d0c6333..07eee1c09aaf 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>@@ -72,7 +72,7 @@ static int i915_gem_dmabuf_vmap(struct dma_buf
>*dma_buf,
> struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
> void *vaddr;
>
>- vaddr = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB);
>+ vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
> if (IS_ERR(vaddr))
> return PTR_ERR(vaddr);
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>index 389e9f157ca5..7e2a9b02526c 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>@@ -331,7 +331,19 @@ static void __i915_gem_free_objects(struct
>drm_i915_private *i915,
> continue;
> }
>
>+ /*
>+ * dma_buf_unmap_attachment() requires reservation to be
>+ * locked. The imported GEM shouldn't share reservation lock,
>+ * so it's safe to take the lock.
>+ */
>+ if (obj->base.import_attach)
>+ i915_gem_object_lock(obj, NULL);
There is a lot of stuff going here. Taking the lock may be premature...
> __i915_gem_object_pages_fini(obj);
The i915_gem_dmabuf.c:i915_gem_object_put_pages_dmabuf is where
unmap_attachment is actually called, would it make more sense to make
do the locking there?
Mike
>+
>+ if (obj->base.import_attach)
>+ i915_gem_object_unlock(obj);
>+
> __i915_gem_free_object(obj);
>
> /* But keep the pointer alive for RCU-protected lookups */
>diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>index 62c61af77a42..9e3ed634aa0e 100644
>--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>@@ -213,7 +213,7 @@ static int igt_dmabuf_import_same_driver(struct
>drm_i915_private *i915,
> goto out_import;
> }
>
>- st = dma_buf_map_attachment(import_attach,
>DMA_BIDIRECTIONAL);
>+ st = dma_buf_map_attachment_unlocked(import_attach,
>DMA_BIDIRECTIONAL);
> if (IS_ERR(st)) {
> err = PTR_ERR(st);
> goto out_detach;
>@@ -226,7 +226,7 @@ static int igt_dmabuf_import_same_driver(struct
>drm_i915_private *i915,
> timeout = -ETIME;
> }
> err = timeout > 0 ? 0 : timeout;
>- dma_buf_unmap_attachment(import_attach, st,
>DMA_BIDIRECTIONAL);
>+ dma_buf_unmap_attachment_unlocked(import_attach, st,
>DMA_BIDIRECTIONAL);
> out_detach:
> dma_buf_detach(dmabuf, import_attach);
> out_import:
>@@ -296,7 +296,7 @@ static int igt_dmabuf_import(void *arg)
> goto out_obj;
> }
>
>- err = dma_buf_vmap(dmabuf, );
>+ err = dma_buf_vmap_unlocked(dmabuf, );
> dma_map = err ? NULL : map.vaddr;
> if (!dma_map) {
> pr_err("dma_buf_vmap failed\n");
>@@ -337,7 +337,7 @@ static int
Re: [Intel-gfx] [PATCH 6/6] drm/ttm: stop allocating a dummy resource for pipelined gutting
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, July 7, 2022 6:25 AM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>nouv...@lists.freedesktop.org; amd-...@lists.freedesktop.org
>Cc: Christian König
>Subject: [PATCH 6/6] drm/ttm: stop allocating a dummy resource for pipelined
>gutting
>
>That should not be necessary any more when drivers should at least be
>able to handle a move without a resource.
>
>Signed-off-by: Christian König
Reviewed-by: Michael J. Ruhl
M
>---
> drivers/gpu/drm/ttm/ttm_bo_util.c | 15 ++-
> 1 file changed, 2 insertions(+), 13 deletions(-)
>
>diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
>b/drivers/gpu/drm/ttm/ttm_bo_util.c
>index 1530982338e9..1e76149c62ff 100644
>--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
>+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
>@@ -603,16 +603,10 @@ EXPORT_SYMBOL(ttm_bo_move_sync_cleanup);
> */
> int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
> {
>- static const struct ttm_place sys_mem = { .mem_type =
>TTM_PL_SYSTEM };
> struct ttm_buffer_object *ghost;
>- struct ttm_resource *sys_res;
> struct ttm_tt *ttm;
> int ret;
>
>- ret = ttm_resource_alloc(bo, _mem, _res);
>- if (ret)
>- return ret;
>-
> /* If already idle, no need for ghost object dance. */
> ret = ttm_bo_wait(bo, false, true);
> if (ret != -EBUSY) {
>@@ -620,14 +614,13 @@ int ttm_bo_pipeline_gutting(struct
>ttm_buffer_object *bo)
> /* See comment below about clearing. */
> ret = ttm_tt_create(bo, true);
> if (ret)
>- goto error_free_sys_mem;
>+ return ret;
> } else {
> ttm_tt_unpopulate(bo->bdev, bo->ttm);
> if (bo->type == ttm_bo_type_device)
> ttm_tt_mark_for_clear(bo->ttm);
> }
> ttm_resource_free(bo, >resource);
>- ttm_bo_assign_mem(bo, sys_res);
> return 0;
> }
>
>@@ -644,7 +637,7 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object
>*bo)
> ret = ttm_tt_create(bo, true);
> swap(bo->ttm, ttm);
> if (ret)
>- goto error_free_sys_mem;
>+ return ret;
>
> ret = ttm_buffer_object_transfer(bo, );
> if (ret)
>@@ -658,13 +651,9 @@ int ttm_bo_pipeline_gutting(struct
>ttm_buffer_object *bo)
> dma_resv_unlock(>base._resv);
> ttm_bo_put(ghost);
> bo->ttm = ttm;
>- ttm_bo_assign_mem(bo, sys_res);
> return 0;
>
> error_destroy_tt:
> ttm_tt_destroy(bo->bdev, ttm);
>-
>-error_free_sys_mem:
>- ttm_resource_free(bo, _res);
> return ret;
> }
>--
>2.25.1
Re: [Intel-gfx] [PATCH 5/6] drm/ttm: stop allocating dummy resources during BO creation
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, July 7, 2022 6:25 AM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>nouv...@lists.freedesktop.org; amd-...@lists.freedesktop.org
>Cc: Christian König
>Subject: [PATCH 5/6] drm/ttm: stop allocating dummy resources during BO
>creation
>
>That should not be necessary any more when drivers should at least be
>able to handle the move without a resource.
>
>Signed-off-by: Christian König
Reviewed-by: Michael J. Ruhl
M
>---
> drivers/gpu/drm/ttm/ttm_bo.c | 7 ---
> 1 file changed, 7 deletions(-)
>
>diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>index a2f49bdda8a1..f491be751a2f 100644
>--- a/drivers/gpu/drm/ttm/ttm_bo.c
>+++ b/drivers/gpu/drm/ttm/ttm_bo.c
>@@ -960,7 +960,6 @@ int ttm_bo_init_reserved(struct ttm_device *bdev,
>struct ttm_buffer_object *bo,
>struct sg_table *sg, struct dma_resv *resv,
>void (*destroy) (struct ttm_buffer_object *))
> {
>- static const struct ttm_place sys_mem = { .mem_type =
>TTM_PL_SYSTEM };
> int ret;
>
> kref_init(>kref);
>@@ -978,12 +977,6 @@ int ttm_bo_init_reserved(struct ttm_device *bdev,
>struct ttm_buffer_object *bo,
> bo->base.resv = >base._resv;
> atomic_inc(_glob.bo_count);
>
>- ret = ttm_resource_alloc(bo, _mem, >resource);
>- if (unlikely(ret)) {
>- ttm_bo_put(bo);
>- return ret;
>- }
>-
> /*
>* For ttm_bo_type_device buffers, allocate
>* address space from the device.
>--
>2.25.1
Re: [Intel-gfx] [PATCH 4/6] drm/ttm: audit bo->resource usage v2
>-Original Message-
>From: Intel-gfx On Behalf Of
>Christian König
>Sent: Thursday, July 7, 2022 6:25 AM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>nouv...@lists.freedesktop.org; amd-...@lists.freedesktop.org
>Cc: Christian König
>Subject: [Intel-gfx] [PATCH 4/6] drm/ttm: audit bo->resource usage v2
>
>Allow BOs to exist without backing store.
>
>v2: handle ttm_bo_move_memcpy as well.
>
>Signed-off-by: Christian König
Reviewed-by: Michael J. Ruhl
M
>---
> drivers/gpu/drm/ttm/ttm_bo.c | 16
> drivers/gpu/drm/ttm/ttm_bo_util.c | 7 +--
> 2 files changed, 13 insertions(+), 10 deletions(-)
>
>diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>index 984535d6a2d0..a2f49bdda8a1 100644
>--- a/drivers/gpu/drm/ttm/ttm_bo.c
>+++ b/drivers/gpu/drm/ttm/ttm_bo.c
>@@ -117,12 +117,13 @@ static int ttm_bo_handle_move_mem(struct
>ttm_buffer_object *bo,
> struct ttm_operation_ctx *ctx,
> struct ttm_place *hop)
> {
>- struct ttm_resource_manager *old_man, *new_man;
> struct ttm_device *bdev = bo->bdev;
>+ bool old_use_tt, new_use_tt;
> int ret;
>
>- old_man = ttm_manager_type(bdev, bo->resource->mem_type);
>- new_man = ttm_manager_type(bdev, mem->mem_type);
>+ old_use_tt = bo->resource &&
>+ ttm_manager_type(bdev, bo->resource->mem_type)-
>>use_tt;
>+ new_use_tt = ttm_manager_type(bdev, mem->mem_type)->use_tt;
>
> ttm_bo_unmap_virtual(bo);
>
>@@ -130,11 +131,11 @@ static int ttm_bo_handle_move_mem(struct
>ttm_buffer_object *bo,
>* Create and bind a ttm if required.
>*/
>
>- if (new_man->use_tt) {
>+ if (new_use_tt) {
> /* Zero init the new TTM structure if the old location should
>* have used one as well.
>*/
>- ret = ttm_tt_create(bo, old_man->use_tt);
>+ ret = ttm_tt_create(bo, old_use_tt);
> if (ret)
> goto out_err;
>
>@@ -160,8 +161,7 @@ static int ttm_bo_handle_move_mem(struct
>ttm_buffer_object *bo,
> return 0;
>
> out_err:
>- new_man = ttm_manager_type(bdev, bo->resource->mem_type);
>- if (!new_man->use_tt)
>+ if (!old_use_tt)
> ttm_bo_tt_destroy(bo);
>
> return ret;
>@@ -904,7 +904,7 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
> /*
>* Check whether we need to move buffer.
>*/
>- if (!ttm_resource_compat(bo->resource, placement)) {
>+ if (!bo->resource || !ttm_resource_compat(bo->resource,
>placement)) {
> ret = ttm_bo_move_buffer(bo, placement, ctx);
> if (ret)
> return ret;
>diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
>b/drivers/gpu/drm/ttm/ttm_bo_util.c
>index 1cbfb00c1d65..1530982338e9 100644
>--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
>+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
>@@ -137,8 +137,7 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object
>*bo,
> ttm_manager_type(bo->bdev, dst_mem->mem_type);
> struct ttm_tt *ttm = bo->ttm;
> struct ttm_resource *src_mem = bo->resource;
>- struct ttm_resource_manager *src_man =
>- ttm_manager_type(bdev, src_mem->mem_type);
>+ struct ttm_resource_manager *src_man;
> union {
> struct ttm_kmap_iter_tt tt;
> struct ttm_kmap_iter_linear_io io;
>@@ -147,6 +146,10 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object
>*bo,
> bool clear;
> int ret = 0;
>
>+ if (!src_mem)
>+ return 0;
>+
>+ src_man = ttm_manager_type(bdev, src_mem->mem_type);
> if (ttm && ((ttm->page_flags & TTM_TT_FLAG_SWAPPED) ||
> dst_man->use_tt)) {
> ret = ttm_tt_populate(bdev, ttm, ctx);
>--
>2.25.1
Re: [Intel-gfx] [PATCH 3/6] drm/nouveau: audit bo->resource usage
>-Original Message-
>From: Intel-gfx On Behalf Of
>Christian König
>Sent: Thursday, July 7, 2022 6:25 AM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>nouv...@lists.freedesktop.org; amd-...@lists.freedesktop.org
>Cc: Christian König
>Subject: [Intel-gfx] [PATCH 3/6] drm/nouveau: audit bo->resource usage
>
>Make sure we can at least move and release BOs without backing store.
>
>Signed-off-by: Christian König
Reviewed-by: Michael J. Ruhl
M
>---
> drivers/gpu/drm/nouveau/nouveau_bo.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
>b/drivers/gpu/drm/nouveau/nouveau_bo.c
>index 92cd19021084..f83fb43b2e44 100644
>--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
>+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
>@@ -1006,7 +1006,8 @@ nouveau_bo_move(struct ttm_buffer_object *bo,
>bool evict,
> }
>
> /* Fake bo copy. */
>- if (old_reg->mem_type == TTM_PL_SYSTEM && !bo->ttm) {
>+ if (!old_reg || (old_reg->mem_type == TTM_PL_SYSTEM &&
>+ !bo->ttm)) {
> ttm_bo_move_null(bo, new_reg);
> goto out;
> }
>--
>2.25.1
Re: [Intel-gfx] [PATCH 2/6] drm/amdgpu: audit bo->resource usage
>-Original Message-
>From: Intel-gfx On Behalf Of
>Christian König
>Sent: Thursday, July 7, 2022 6:25 AM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>nouv...@lists.freedesktop.org; amd-...@lists.freedesktop.org
>Cc: Christian König
>Subject: [Intel-gfx] [PATCH 2/6] drm/amdgpu: audit bo->resource usage
>
>Make sure we can at least move and release BOs without backing store.
>
>Signed-off-by: Christian König
Reviewed-by: Michael J. Ruhl
M
>---
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 3 ++-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>index d9cfe259f2a9..677d1dfab37f 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>@@ -1305,7 +1305,7 @@ void amdgpu_bo_release_notify(struct
>ttm_buffer_object *bo)
> if (bo->base.resv == >base._resv)
> amdgpu_amdkfd_remove_fence_on_pt_pd_bos(abo);
>
>- if (bo->resource->mem_type != TTM_PL_VRAM ||
>+ if (!bo->resource || bo->resource->mem_type != TTM_PL_VRAM ||
> !(abo->flags &
>AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE) ||
> adev->in_suspend || adev->shutdown)
> return;
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>index be6f76a30ac6..3bddf266e8b5 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>@@ -471,7 +471,8 @@ static int amdgpu_bo_move(struct ttm_buffer_object
>*bo, bool evict,
>
> adev = amdgpu_ttm_adev(bo->bdev);
>
>- if (old_mem->mem_type == TTM_PL_SYSTEM && bo->ttm == NULL) {
>+ if (!old_mem || (old_mem->mem_type == TTM_PL_SYSTEM &&
>+ bo->ttm == NULL)) {
> ttm_bo_move_null(bo, new_mem);
> goto out;
> }
>--
>2.25.1
Re: [Intel-gfx] [PATCH 1/6] drm/ttm: rename and cleanup ttm_bo_init_reserved
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, July 7, 2022 6:25 AM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>nouv...@lists.freedesktop.org; amd-...@lists.freedesktop.org
>Cc: Christian König
>Subject: [PATCH 1/6] drm/ttm: rename and cleanup ttm_bo_init_reserved
>
>Rename ttm_bo_init_reserved to ttm_bo_init_validate since that better
>matches what the function is actually doing.
>
>Remove the unused size parameter, move the function's kerneldoc to the
>implementation and cleanup the whole error handling.
>
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
> drivers/gpu/drm/drm_gem_vram_helper.c | 6 +-
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 5 +-
> drivers/gpu/drm/nouveau/nouveau_bo.c | 6 +-
> drivers/gpu/drm/qxl/qxl_object.c | 2 +-
> drivers/gpu/drm/radeon/radeon_object.c | 6 +-
> drivers/gpu/drm/ttm/ttm_bo.c | 147 +++--
> drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 12 +-
> include/drm/ttm/ttm_bo_api.h | 93 ++---
> 9 files changed, 129 insertions(+), 150 deletions(-)
>
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>index 2c82b1d5a0d7..d9cfe259f2a9 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>@@ -591,7 +591,7 @@ int amdgpu_bo_create(struct amdgpu_device *adev,
> if (!bp->destroy)
> bp->destroy = _bo_destroy;
>
>- r = ttm_bo_init_reserved(>mman.bdev, >tbo, size, bp-
>>type,
>+ r = ttm_bo_init_reserved(>mman.bdev, >tbo, bp->type,
>>placement, page_align, , NULL,
>bp->resv, bp->destroy);
> if (unlikely(r != 0))
>diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
>b/drivers/gpu/drm/drm_gem_vram_helper.c
>index d607043716d3..125160b534be 100644
>--- a/drivers/gpu/drm/drm_gem_vram_helper.c
>+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
>@@ -226,9 +226,9 @@ struct drm_gem_vram_object
>*drm_gem_vram_create(struct drm_device *dev,
>* A failing ttm_bo_init will call ttm_buffer_object_destroy
>* to release gbo->bo.base and kfree gbo.
>*/
>- ret = ttm_bo_init(bdev, >bo, size, ttm_bo_type_device,
>->placement, pg_align, false, NULL, NULL,
>-ttm_buffer_object_destroy);
>+ ret = ttm_bo_init_validate(bdev, >bo, ttm_bo_type_device,
>+ >placement, pg_align, false, NULL,
>NULL,
>+ ttm_buffer_object_destroy);
> if (ret)
> return ERR_PTR(ret);
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>index 4c25d9b2f138..70e2ed4e99df 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>@@ -1229,9 +1229,8 @@ int __i915_gem_ttm_object_init(struct
>intel_memory_region *mem,
>* Similarly, in delayed_destroy, we can't call ttm_bo_put()
>* until successful initialization.
>*/
>- ret = ttm_bo_init_reserved(>bdev, i915_gem_to_ttm(obj),
>size,
>- bo_type, _sys_placement,
>- page_size >> PAGE_SHIFT,
>+ ret = ttm_bo_init_reserved(>bdev, i915_gem_to_ttm(obj),
>bo_type,
>+ _sys_placement, page_size >>
>PAGE_SHIFT,
> , NULL, NULL, i915_ttm_bo_destroy);
> if (ret)
> return i915_ttm_err_to_gem(ret);
>diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
>b/drivers/gpu/drm/nouveau/nouveau_bo.c
>index 05076e530e7d..92cd19021084 100644
>--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
>+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
>@@ -307,9 +307,9 @@ nouveau_bo_init(struct nouveau_bo *nvbo, u64 size,
>int align, u32 domain,
> nouveau_bo_placement_set(nvbo, domain, 0);
> INIT_LIST_HEAD(>io_reserve_lru);
>
>- ret = ttm_bo_init(nvbo->bo.bdev, >bo, size, type,
>->placement, align >> PAGE_SHIFT, false, sg,
>-robj, nouveau_bo_del_ttm);
>+ ret = ttm_bo_init_validate(nvbo->bo.bdev, >bo, type,
>+ >placement, align >> PAGE_SHIFT,
>false,
>+ sg, robj, nouveau_bo_del_ttm);
> if (ret) {
> /* ttm will call nouveau_bo_del_ttm if it fails.. */
> return ret;
>diff --git a/drivers/gpu/drm/qxl/qxl_object.c
>b/drivers/gpu/drm/qxl/qxl_object.c
>index b42a657e4c2f..695d9308d1f0 100644
>--- a/drivers/gpu/drm/qxl/qxl_object.c
>+++ b/drivers/gpu/drm/qxl/qxl_object.c
>@@ -141,7 +141,7 @@ int qxl_bo_create(struct qxl_device *qdev, unsigned
>long size,
> qxl_ttm_placement_from_domain(bo, domain);
>
> bo->tbo.priority = priority;
>- r =
Re: [Intel-gfx] [RFC PATCH v2 1/1] drm/i915: Replace shmem memory region and object backend with TTM
Hi Adrian,
Sorry for the delayed response, this got buried in my inbox...
>-Original Message-
>From: Adrian Larumbe
>Sent: Monday, June 6, 2022 4:20 PM
>To: Ruhl, Michael J
>Cc: dan...@ffwll.ch; intel-gfx@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [RFC PATCH v2 1/1] drm/i915: Replace shmem memory
>region and object backend with TTM
>
>On 01.06.2022 19:43, Ruhl, Michael J wrote:
>>>-Original Message-
>>>From: Adrian Larumbe
>>>Sent: Friday, May 27, 2022 12:08 PM
>>>To: Ruhl, Michael J
>>>Cc: dan...@ffwll.ch; intel-gfx@lists.freedesktop.org
>>>Subject: Re: [Intel-gfx] [RFC PATCH v2 1/1] drm/i915: Replace shmem
>memory
>>>region and object backend with TTM
>>>
>>>On 17.05.2022 21:39, Ruhl, Michael J wrote:
>>>> >-Original Message-
>>>> >From: Intel-gfx On Behalf Of
>>>> >Adrian Larumbe
>>>> >Sent: Tuesday, May 17, 2022 4:45 PM
>>>> >To: dan...@ffwll.ch; intel-gfx@lists.freedesktop.org
>>>> >Cc: adrian.laru...@collabora.com
>>>> >Subject: [Intel-gfx] [RFC PATCH v2 1/1] drm/i915: Replace shmem
>memory
>>>> >region and object backend with TTM
>>>> >
>>>> >Remove shmem region and object backend code as they are now
>>>> >unnecessary.
>>>> >In the case of objects placed in SMEM and backed by kernel shmem
>files,
>>>the
>>>> >file pointer has to be retrieved from the ttm_tt structure, so change this
>>>> >as well. This means accessing an shmem-backed BO's file pointer
>requires
>>>> >getting its pages beforehand, unlike in the old shmem backend.
>>>> >
>>>> >Expand TTM BO creation by handling devices with no LLC so that their
>>>> >caching and coherency properties are set accordingly.
>>>> >
>>>> >Adapt phys backend to put pages of original shmem object in a 'TTM
>way',
>>>> >also making sure its pages are put when a TTM shmem object has no
>struct
>>>> >page.
>>>> >
>>>> >Signed-off-by: Adrian Larumbe
>>>> >---
>>>> > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 12 +-
>>>> > drivers/gpu/drm/i915/gem/i915_gem_mman.c | 32 +-
>>>> > drivers/gpu/drm/i915/gem/i915_gem_object.h | 4 +-
>>>> > drivers/gpu/drm/i915/gem/i915_gem_phys.c | 32 +-
>>>> > drivers/gpu/drm/i915/gem/i915_gem_shmem.c| 390 +--
>>>> > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 267 -
>>>> > drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 3 +
>>>> > drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 9 +-
>>>> > drivers/gpu/drm/i915/gt/shmem_utils.c| 64 ++-
>>>> > drivers/gpu/drm/i915/intel_memory_region.c | 7 +-
>>>> > 10 files changed, 398 insertions(+), 422 deletions(-)
>>>> >
>>>> >diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>>>> >b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>>>> >index f5062d0c6333..de04ce4210b3 100644
>>>> >--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>>>> >+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>>>> >@@ -12,6 +12,7 @@
>>>> > #include
>>>> >
>>>> > #include "gem/i915_gem_dmabuf.h"
>>>> >+#include "gem/i915_gem_ttm.h"
>>>> > #include "i915_drv.h"
>>>> > #include "i915_gem_object.h"
>>>> > #include "i915_scatterlist.h"
>>>> >@@ -94,22 +95,25 @@ static int i915_gem_dmabuf_mmap(struct
>dma_buf
>>>> >*dma_buf, struct vm_area_struct *
>>>> > {
>>>> > struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
>>>> > struct drm_i915_private *i915 = to_i915(obj->base.dev);
>>>> >+ struct file *filp = i915_gem_ttm_get_filep(obj);
>>>> > int ret;
>>>> >
>>>> >+ GEM_BUG_ON(obj->base.import_attach != NULL);
>>>> >+
>>>> > if (obj->base.size < vma->vm_end - vma->vm_start)
>>>> > return -EINVAL;
>>>> >
>>>> > if (HAS_LMEM(i915))
>>>> > return drm_gem_prime_mmap(>base, vma);
>>>>
>>>> Since all of the devices that will have device memory will be true for
>>>HAS_LMEM,
>>>> wo
Re: [Intel-gfx] [RFC PATCH v2 1/1] drm/i915: Replace shmem memory region and object backend with TTM
>-Original Message-
>From: Adrian Larumbe
>Sent: Friday, May 27, 2022 12:08 PM
>To: Ruhl, Michael J
>Cc: dan...@ffwll.ch; intel-gfx@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [RFC PATCH v2 1/1] drm/i915: Replace shmem memory
>region and object backend with TTM
>
>On 17.05.2022 21:39, Ruhl, Michael J wrote:
>> >-Original Message-
>> >From: Intel-gfx On Behalf Of
>> >Adrian Larumbe
>> >Sent: Tuesday, May 17, 2022 4:45 PM
>> >To: dan...@ffwll.ch; intel-gfx@lists.freedesktop.org
>> >Cc: adrian.laru...@collabora.com
>> >Subject: [Intel-gfx] [RFC PATCH v2 1/1] drm/i915: Replace shmem memory
>> >region and object backend with TTM
>> >
>> >Remove shmem region and object backend code as they are now
>> >unnecessary.
>> >In the case of objects placed in SMEM and backed by kernel shmem files,
>the
>> >file pointer has to be retrieved from the ttm_tt structure, so change this
>> >as well. This means accessing an shmem-backed BO's file pointer requires
>> >getting its pages beforehand, unlike in the old shmem backend.
>> >
>> >Expand TTM BO creation by handling devices with no LLC so that their
>> >caching and coherency properties are set accordingly.
>> >
>> >Adapt phys backend to put pages of original shmem object in a 'TTM way',
>> >also making sure its pages are put when a TTM shmem object has no struct
>> >page.
>> >
>> >Signed-off-by: Adrian Larumbe
>> >---
>> > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 12 +-
>> > drivers/gpu/drm/i915/gem/i915_gem_mman.c | 32 +-
>> > drivers/gpu/drm/i915/gem/i915_gem_object.h | 4 +-
>> > drivers/gpu/drm/i915/gem/i915_gem_phys.c | 32 +-
>> > drivers/gpu/drm/i915/gem/i915_gem_shmem.c| 390 +--
>> > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 267 -
>> > drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 3 +
>> > drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 9 +-
>> > drivers/gpu/drm/i915/gt/shmem_utils.c| 64 ++-
>> > drivers/gpu/drm/i915/intel_memory_region.c | 7 +-
>> > 10 files changed, 398 insertions(+), 422 deletions(-)
>> >
>> >diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> >b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> >index f5062d0c6333..de04ce4210b3 100644
>> >--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> >+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> >@@ -12,6 +12,7 @@
>> > #include
>> >
>> > #include "gem/i915_gem_dmabuf.h"
>> >+#include "gem/i915_gem_ttm.h"
>> > #include "i915_drv.h"
>> > #include "i915_gem_object.h"
>> > #include "i915_scatterlist.h"
>> >@@ -94,22 +95,25 @@ static int i915_gem_dmabuf_mmap(struct dma_buf
>> >*dma_buf, struct vm_area_struct *
>> > {
>> >struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
>> >struct drm_i915_private *i915 = to_i915(obj->base.dev);
>> >+ struct file *filp = i915_gem_ttm_get_filep(obj);
>> >int ret;
>> >
>> >+ GEM_BUG_ON(obj->base.import_attach != NULL);
>> >+
>> >if (obj->base.size < vma->vm_end - vma->vm_start)
>> >return -EINVAL;
>> >
>> >if (HAS_LMEM(i915))
>> >return drm_gem_prime_mmap(>base, vma);
>>
>> Since all of the devices that will have device memory will be true for
>HAS_LMEM,
>> won't your code path always go to drm_gem_prime_mmap()?
>
>This makes me wonder, how was mapping of a dmabuf BO working before, in
>the case
>of DG2 and DG1, when an object is smem-bound, and therefore backed by
>shmem?
LMEM is a new thing. DG2 and DG1 have it available, but the initial patch
sets did not support access via dma-buf.
With the TTM being used for the LMEM objects, I think that the drm_gem code
was able to be used.
>
>I guess in this case it might be more sensible to control for the case that
>it's
>an lmem-only object on a discrete platform as follows:
>
>static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct
>vm_area_struct *vma)
>{
> struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
> struct drm_i915_private *i915 = to_i915(obj->base.dev);
> struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
> struct file *filp = i915_gem_ttm_get_filep(obj);
> int ret;
>
> if (obj->base.size < vma->vm_end - vma->vm_start)
>
Re: [Intel-gfx] [PATCH 1/2] drm/i915/dmabuf: dmabuf cleanup
ping?
Any comments on this cleanup and the open coding fix (patch 2?)
Thanks,
Mike
>-Original Message-
>From: Ruhl, Michael J
>Sent: Friday, May 6, 2022 3:09 PM
>To: intel-gfx@lists.freedesktop.org; airl...@linux.ie; dan...@ffwll.ch
>Cc: tvrtko.ursu...@linux.intel.com; De Marchi, Lucas
>; Ruhl, Michael J ;
>Ursulin, Tvrtko
>Subject: [PATCH 1/2] drm/i915/dmabuf: dmabuf cleanup
>
>Some minor cleanup of some variables for consistency.
>
>Normalize struct sg_table to sgt.
>Normalize struct dma_buf_attachment to attach.
>checkpatch issues sizeof(), !NULL updates.
>
>Cc: Tvrtko Ursulin
>Signed-off-by: Michael J. Ruhl
>---
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 47 --
> 1 file changed, 25 insertions(+), 22 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>index f5062d0c6333..5f327eac26e6 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>@@ -25,43 +25,46 @@ static struct drm_i915_gem_object
>*dma_buf_to_obj(struct dma_buf *buf)
> return to_intel_bo(buf->priv);
> }
>
>-static struct sg_table *i915_gem_map_dma_buf(struct
>dma_buf_attachment *attachment,
>+static struct sg_table *i915_gem_map_dma_buf(struct
>dma_buf_attachment *attach,
>enum dma_data_direction dir)
> {
>- struct drm_i915_gem_object *obj = dma_buf_to_obj(attachment-
>>dmabuf);
>- struct sg_table *st;
>+ struct drm_i915_gem_object *obj = dma_buf_to_obj(attach-
>>dmabuf);
>+ struct sg_table *sgt;
> struct scatterlist *src, *dst;
> int ret, i;
>
>- /* Copy sg so that we make an independent mapping */
>- st = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
>- if (st == NULL) {
>+ /*
>+ * Make a copy of the object's sgt, so that we can make an
>independent
>+ * mapping
>+ */
>+ sgt = kmalloc(sizeof(*sgt), GFP_KERNEL);
>+ if (!sgt) {
> ret = -ENOMEM;
> goto err;
> }
>
>- ret = sg_alloc_table(st, obj->mm.pages->nents, GFP_KERNEL);
>+ ret = sg_alloc_table(sgt, obj->mm.pages->nents, GFP_KERNEL);
> if (ret)
> goto err_free;
>
> src = obj->mm.pages->sgl;
>- dst = st->sgl;
>+ dst = sgt->sgl;
> for (i = 0; i < obj->mm.pages->nents; i++) {
> sg_set_page(dst, sg_page(src), src->length, 0);
> dst = sg_next(dst);
> src = sg_next(src);
> }
>
>- ret = dma_map_sgtable(attachment->dev, st, dir,
>DMA_ATTR_SKIP_CPU_SYNC);
>+ ret = dma_map_sgtable(attach->dev, sgt, dir,
>DMA_ATTR_SKIP_CPU_SYNC);
> if (ret)
> goto err_free_sg;
>
>- return st;
>+ return sgt;
>
> err_free_sg:
>- sg_free_table(st);
>+ sg_free_table(sgt);
> err_free:
>- kfree(st);
>+ kfree(sgt);
> err:
> return ERR_PTR(ret);
> }
>@@ -236,15 +239,15 @@ struct dma_buf *i915_gem_prime_export(struct
>drm_gem_object *gem_obj, int flags)
> static int i915_gem_object_get_pages_dmabuf(struct drm_i915_gem_object
>*obj)
> {
> struct drm_i915_private *i915 = to_i915(obj->base.dev);
>- struct sg_table *pages;
>+ struct sg_table *sgt;
> unsigned int sg_page_sizes;
>
> assert_object_held(obj);
>
>- pages = dma_buf_map_attachment(obj->base.import_attach,
>- DMA_BIDIRECTIONAL);
>- if (IS_ERR(pages))
>- return PTR_ERR(pages);
>+ sgt = dma_buf_map_attachment(obj->base.import_attach,
>+ DMA_BIDIRECTIONAL);
>+ if (IS_ERR(sgt))
>+ return PTR_ERR(sgt);
>
> /*
>* DG1 is special here since it still snoops transactions even with
>@@ -261,16 +264,16 @@ static int
>i915_gem_object_get_pages_dmabuf(struct drm_i915_gem_object *obj)
> (!HAS_LLC(i915) && !IS_DG1(i915)))
> wbinvd_on_all_cpus();
>
>- sg_page_sizes = i915_sg_dma_sizes(pages->sgl);
>- __i915_gem_object_set_pages(obj, pages, sg_page_sizes);
>+ sg_page_sizes = i915_sg_dma_sizes(sgt->sgl);
>+ __i915_gem_object_set_pages(obj, sgt, sg_page_sizes);
>
> return 0;
> }
>
> static void i915_gem_object_put_pages_dmabuf(struct
>drm_i915_gem_object *obj,
>- struct sg_table *pages)
>+ struct sg_table *sgt)
> {
>- dma_buf_unmap_attachment(obj->base.import_attach, pages,
>+ dma_buf_unmap_attachment(obj->base.import_attach, sgt,
>DMA_BIDIRECTIONAL);
> }
>
>@@ -313,7 +316,7 @@ struct drm_gem_object
>*i915_gem_prime_import(struct drm_device *dev,
> get_dma_buf(dma_buf);
>
> obj = i915_gem_object_alloc();
>- if (obj == NULL) {
>+ if (!obj) {
> ret = -ENOMEM;
> goto fail_detach;
> }
>--
>2.31.1
Re: [Intel-gfx] [PATCH 09/11] drm/ttm: audit bo->resource usage
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, May 19, 2022 5:55 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: matthew.william.a...@gmail.com; Christian König
>; dri-de...@lists.freedesktop.org
>Subject: [PATCH 09/11] drm/ttm: audit bo->resource usage
>
>Allow BOs to exist without backing store.
Took me a while to figure out that only the last line is related to this commit
message.
Could you add something like:
Refactor usage information.
Allow BOs to exist without backing store.
?
Would make this patch a little easier to decipher.
M
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/ttm/ttm_bo.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
>diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>index 2b01cb30694a..a55564c8b57c 100644
>--- a/drivers/gpu/drm/ttm/ttm_bo.c
>+++ b/drivers/gpu/drm/ttm/ttm_bo.c
>@@ -117,12 +117,13 @@ static int ttm_bo_handle_move_mem(struct
>ttm_buffer_object *bo,
> struct ttm_operation_ctx *ctx,
> struct ttm_place *hop)
> {
>- struct ttm_resource_manager *old_man, *new_man;
> struct ttm_device *bdev = bo->bdev;
>+ bool old_use_tt, new_use_tt;
> int ret;
>
>- old_man = ttm_manager_type(bdev, bo->resource->mem_type);
>- new_man = ttm_manager_type(bdev, mem->mem_type);
>+ old_use_tt = bo->resource &&
>+ ttm_manager_type(bdev, bo->resource->mem_type)-
>>use_tt;
>+ new_use_tt = ttm_manager_type(bdev, mem->mem_type)->use_tt;
>
> ttm_bo_unmap_virtual(bo);
>
>@@ -130,11 +131,11 @@ static int ttm_bo_handle_move_mem(struct
>ttm_buffer_object *bo,
>* Create and bind a ttm if required.
>*/
>
>- if (new_man->use_tt) {
>+ if (new_use_tt) {
> /* Zero init the new TTM structure if the old location should
>* have used one as well.
>*/
>- ret = ttm_tt_create(bo, old_man->use_tt);
>+ ret = ttm_tt_create(bo, old_use_tt);
> if (ret)
> goto out_err;
>
>@@ -160,8 +161,7 @@ static int ttm_bo_handle_move_mem(struct
>ttm_buffer_object *bo,
> return 0;
>
> out_err:
>- new_man = ttm_manager_type(bdev, bo->resource->mem_type);
>- if (!new_man->use_tt)
>+ if (!old_use_tt)
> ttm_bo_tt_destroy(bo);
>
> return ret;
>@@ -898,7 +898,7 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
> /*
>* Check whether we need to move buffer.
>*/
>- if (!ttm_resource_compat(bo->resource, placement)) {
>+ if (!bo->resource || !ttm_resource_compat(bo->resource,
>placement)) {
> ret = ttm_bo_move_buffer(bo, placement, ctx);
> if (ret)
> return ret;
>--
>2.25.1
Re: [Intel-gfx] [PATCH 06/11] drm/ttm: rename and cleanup ttm_bo_init_reserved
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, May 19, 2022 5:55 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: matthew.william.a...@gmail.com; Christian König
>; dri-de...@lists.freedesktop.org
>Subject: [PATCH 06/11] drm/ttm: rename and cleanup ttm_bo_init_reserved
>
>Rename ttm_bo_init_reserved to ttm_bo_init_validate since that better
>matches what the function is actually doing.
>
>Remove the unused size parameter, move the function's kerneldoc to the
>implementation and cleanup the whole error handling.
>
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
> drivers/gpu/drm/drm_gem_vram_helper.c | 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 5 +-
> drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +-
> drivers/gpu/drm/qxl/qxl_object.c | 2 +-
> drivers/gpu/drm/radeon/radeon_object.c | 2 +-
> drivers/gpu/drm/ttm/ttm_bo.c | 92 ++
> drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 12 ++-
> include/drm/ttm/ttm_bo_api.h | 44 +--
> 9 files changed, 75 insertions(+), 88 deletions(-)
>
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>index 5444515c1476..116c8d31e646 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>@@ -590,7 +590,7 @@ int amdgpu_bo_create(struct amdgpu_device *adev,
> if (!bp->destroy)
> bp->destroy = _bo_destroy;
>
>- r = ttm_bo_init_reserved(>mman.bdev, >tbo, size, bp-
>>type,
>+ r = ttm_bo_init_validate(>mman.bdev, >tbo, bp->type,
>>placement, page_align, , NULL,
>bp->resv, bp->destroy);
> if (unlikely(r != 0))
>diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
>b/drivers/gpu/drm/drm_gem_vram_helper.c
>index 7449cbc2f925..73e91baccea0 100644
>--- a/drivers/gpu/drm/drm_gem_vram_helper.c
>+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
>@@ -226,7 +226,7 @@ struct drm_gem_vram_object
>*drm_gem_vram_create(struct drm_device *dev,
>* A failing ttm_bo_init will call ttm_buffer_object_destroy
>* to release gbo->bo.base and kfree gbo.
>*/
>- ret = ttm_bo_init_reserved(bdev, >bo, size,
>ttm_bo_type_device,
>+ ret = ttm_bo_init_validate(bdev, >bo, ttm_bo_type_device,
> >placement, pg_align, , NULL,
>NULL,
> ttm_buffer_object_destroy);
> if (ret)
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>index 4c25d9b2f138..253188da91eb 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>@@ -1229,9 +1229,8 @@ int __i915_gem_ttm_object_init(struct
>intel_memory_region *mem,
>* Similarly, in delayed_destroy, we can't call ttm_bo_put()
>* until successful initialization.
>*/
>- ret = ttm_bo_init_reserved(>bdev, i915_gem_to_ttm(obj),
>size,
>- bo_type, _sys_placement,
>- page_size >> PAGE_SHIFT,
>+ ret = ttm_bo_init_validate(>bdev, i915_gem_to_ttm(obj),
>bo_type,
>+ _sys_placement, page_size >>
>PAGE_SHIFT,
> , NULL, NULL, i915_ttm_bo_destroy);
> if (ret)
> return i915_ttm_err_to_gem(ret);
>diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
>b/drivers/gpu/drm/nouveau/nouveau_bo.c
>index 858b9382036c..666941804297 100644
>--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
>+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
>@@ -308,7 +308,7 @@ nouveau_bo_init(struct nouveau_bo *nvbo, u64 size,
>int align, u32 domain,
> nouveau_bo_placement_set(nvbo, domain, 0);
> INIT_LIST_HEAD(>io_reserve_lru);
>
>- ret = ttm_bo_init_reserved(nvbo->bo.bdev, >bo, size, type,
>+ ret = ttm_bo_init_validate(nvbo->bo.bdev, >bo, type,
> >placement, align >> PAGE_SHIFT,
>,
> sg, robj, nouveau_bo_del_ttm);
> if (ret) {
>diff --git a/drivers/gpu/drm/qxl/qxl_object.c
>b/drivers/gpu/drm/qxl/qxl_object.c
>index b42a657e4c2f..da3f76f508ea 100644
>--- a/drivers/gpu/drm/qxl/qxl_object.c
>+++ b/drivers/gpu/drm/qxl/qxl_object.c
>@@ -141,7 +141,7 @@ int qxl_bo_create(struct qxl_device *qdev, unsigned
>long size,
> qxl_ttm_placement_from_domain(bo, domain);
>
> bo->tbo.priority = priority;
>- r = ttm_bo_init_reserved(>mman.bdev, >tbo, size, type,
>+ r = ttm_bo_init_validate(>mman.bdev, >tbo, type,
>>placement, 0, , NULL, NULL,
>_ttm_bo_destroy);
> if (unlikely(r != 0)) {
>diff --git a/drivers/gpu/drm/radeon/radeon_object.c
>b/drivers/gpu/drm/radeon/radeon_object.c
>index 1d414ff4ab0c..550ca056b3ac 100644
>---
Re: [Intel-gfx] [PATCH 04/11] drm/ttm: move default BO destructor into VMWGFX
>-Original Message- >From: dri-devel On Behalf Of >Christian König >Sent: Thursday, May 19, 2022 5:55 AM >To: intel-gfx@lists.freedesktop.org >Cc: matthew.william.a...@gmail.com; Christian König >; dri-de...@lists.freedesktop.org >Subject: [PATCH 04/11] drm/ttm: move default BO destructor into VMWGFX > >It's the only driver using this. > >Signed-off-by: Christian König >--- > drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 3 +++ > 1 file changed, 3 insertions(+) > >diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c >b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c >index 85a66014c2b6..c4f376d5e1d0 100644 >--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c >+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c >@@ -462,6 +462,9 @@ int vmw_bo_create(struct vmw_private *vmw, > return -ENOMEM; > } > >+ if (!bo_free) >+ bo_free = vmw_bo_default_destroy; >+ vmw_bo_init has a WARN_ON if this is NULL. Also, all of the callers use vmw_bo_bo_free() or vmw_gem_destroy(). Both of those unmap, release and then free the object. It doesn't look like vmw_bo_default_destroy does this work. Is this the right "default" path? Or should the WARN_ON be used to check for this? M > ret = vmw_bo_init(vmw, *p_bo, size, > placement, interruptible, pin, > bo_free); >-- >2.25.1
Re: [Intel-gfx] [PATCH 02/11] drm/nouveau: switch over to ttm_bo_init_reserved
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, May 19, 2022 5:55 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: matthew.william.a...@gmail.com; Christian König
>; dri-de...@lists.freedesktop.org
>Subject: [PATCH 02/11] drm/nouveau: switch over to ttm_bo_init_reserved
>
>Use the new interface instead.
>
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/nouveau/nouveau_bo.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
>diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
>b/drivers/gpu/drm/nouveau/nouveau_bo.c
>index 05076e530e7d..858b9382036c 100644
>--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
>+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
>@@ -302,19 +302,23 @@ nouveau_bo_init(struct nouveau_bo *nvbo, u64
>size, int align, u32 domain,
> struct sg_table *sg, struct dma_resv *robj)
> {
> int type = sg ? ttm_bo_type_sg : ttm_bo_type_device;
>+ struct ttm_operation_ctx ctx = { false, false };
> int ret;
>
> nouveau_bo_placement_set(nvbo, domain, 0);
> INIT_LIST_HEAD(>io_reserve_lru);
>
>- ret = ttm_bo_init(nvbo->bo.bdev, >bo, size, type,
>->placement, align >> PAGE_SHIFT, false, sg,
>-robj, nouveau_bo_del_ttm);
>+ ret = ttm_bo_init_reserved(nvbo->bo.bdev, >bo, size, type,
>+ >placement, align >> PAGE_SHIFT,
>,
>+ sg, robj, nouveau_bo_del_ttm);
> if (ret) {
> /* ttm will call nouveau_bo_del_ttm if it fails.. */
> return ret;
> }
>
>+ if (!robj)
>+ ttm_bo_unreserve(>bo);
>+
Ok, this implies that patch 1 does have an issue.
I see this usage in patch 1, 2, and 3. Would it make sense to move this
_unreserve to ttm_bo_init_reserved?
Mike
> return 0;
> }
>
>--
>2.25.1
Re: [Intel-gfx] [PATCH 01/11] drm/radeon: switch over to ttm_bo_init_reserved
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, May 19, 2022 5:55 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: matthew.william.a...@gmail.com; Christian König
>; dri-de...@lists.freedesktop.org
>Subject: [PATCH 01/11] drm/radeon: switch over to ttm_bo_init_reserved
>
>Use the new interface instead.
>
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/radeon/radeon_object.c | 17 +++--
> 1 file changed, 11 insertions(+), 6 deletions(-)
>
>diff --git a/drivers/gpu/drm/radeon/radeon_object.c
>b/drivers/gpu/drm/radeon/radeon_object.c
>index 6c4a6802ca96..1d414ff4ab0c 100644
>--- a/drivers/gpu/drm/radeon/radeon_object.c
>+++ b/drivers/gpu/drm/radeon/radeon_object.c
>@@ -133,9 +133,12 @@ int radeon_bo_create(struct radeon_device *rdev,
>struct dma_resv *resv,
>struct radeon_bo **bo_ptr)
> {
>- struct radeon_bo *bo;
>- enum ttm_bo_type type;
> unsigned long page_align = roundup(byte_align, PAGE_SIZE) >>
>PAGE_SHIFT;
>+
>+ /* Kernel allocation are uninterruptible */
>+ struct ttm_operation_ctx ctx = { !kernel, false };
>+ enum ttm_bo_type type;
>+ struct radeon_bo *bo;
> int r;
>
> size = ALIGN(size, PAGE_SIZE);
>@@ -200,11 +203,13 @@ int radeon_bo_create(struct radeon_device *rdev,
> #endif
>
> radeon_ttm_placement_from_domain(bo, domain);
>- /* Kernel allocation are uninterruptible */
> down_read(>pm.mclk_lock);
>- r = ttm_bo_init(>mman.bdev, >tbo, size, type,
>- >placement, page_align, !kernel, sg, resv,
>- _ttm_bo_destroy);
>+ r = ttm_bo_init_reserved(>mman.bdev, >tbo, size, type,
>+ >placement, page_align, , sg, resv,
>+ _ttm_bo_destroy);
>+if (!r)
>+ ttm_bo_unreserve(>tbo);
>+
Hi Christian,
I am not understanding this unreserve.
The original code path does not have it. It looks like tt_bo_init will do
this, but only if !resv.
Should this be:
if (!resv)
ttm_bo_unreserve(>tbo);
?
M
> up_read(>pm.mclk_lock);
> if (unlikely(r != 0)) {
> return r;
>--
>2.25.1
Re: [Intel-gfx] [RFC PATCH v2 1/1] drm/i915: Replace shmem memory region and object backend with TTM
>-Original Message-
>From: Intel-gfx On Behalf Of
>Adrian Larumbe
>Sent: Tuesday, May 17, 2022 4:45 PM
>To: dan...@ffwll.ch; intel-gfx@lists.freedesktop.org
>Cc: adrian.laru...@collabora.com
>Subject: [Intel-gfx] [RFC PATCH v2 1/1] drm/i915: Replace shmem memory
>region and object backend with TTM
>
>Remove shmem region and object backend code as they are now
>unnecessary.
>In the case of objects placed in SMEM and backed by kernel shmem files, the
>file pointer has to be retrieved from the ttm_tt structure, so change this
>as well. This means accessing an shmem-backed BO's file pointer requires
>getting its pages beforehand, unlike in the old shmem backend.
>
>Expand TTM BO creation by handling devices with no LLC so that their
>caching and coherency properties are set accordingly.
>
>Adapt phys backend to put pages of original shmem object in a 'TTM way',
>also making sure its pages are put when a TTM shmem object has no struct
>page.
>
>Signed-off-by: Adrian Larumbe
>---
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 12 +-
> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 32 +-
> drivers/gpu/drm/i915/gem/i915_gem_object.h | 4 +-
> drivers/gpu/drm/i915/gem/i915_gem_phys.c | 32 +-
> drivers/gpu/drm/i915/gem/i915_gem_shmem.c| 390 +--
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 267 -
> drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 3 +
> drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 9 +-
> drivers/gpu/drm/i915/gt/shmem_utils.c| 64 ++-
> drivers/gpu/drm/i915/intel_memory_region.c | 7 +-
> 10 files changed, 398 insertions(+), 422 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>index f5062d0c6333..de04ce4210b3 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>@@ -12,6 +12,7 @@
> #include
>
> #include "gem/i915_gem_dmabuf.h"
>+#include "gem/i915_gem_ttm.h"
> #include "i915_drv.h"
> #include "i915_gem_object.h"
> #include "i915_scatterlist.h"
>@@ -94,22 +95,25 @@ static int i915_gem_dmabuf_mmap(struct dma_buf
>*dma_buf, struct vm_area_struct *
> {
> struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
> struct drm_i915_private *i915 = to_i915(obj->base.dev);
>+ struct file *filp = i915_gem_ttm_get_filep(obj);
> int ret;
>
>+ GEM_BUG_ON(obj->base.import_attach != NULL);
>+
> if (obj->base.size < vma->vm_end - vma->vm_start)
> return -EINVAL;
>
> if (HAS_LMEM(i915))
> return drm_gem_prime_mmap(>base, vma);
Since all of the devices that will have device memory will be true for HAS_LMEM,
won't your code path always go to drm_gem_prime_mmap()?
>- if (!obj->base.filp)
>+ if (!filp)
> return -ENODEV;
>
>- ret = call_mmap(obj->base.filp, vma);
>+ ret = call_mmap(filp, vma);
> if (ret)
> return ret;
>
>- vma_set_file(vma, obj->base.filp);
>+ vma_set_file(vma, filp);
>
> return 0;
> }
>@@ -224,6 +228,8 @@ struct dma_buf *i915_gem_prime_export(struct
>drm_gem_object *gem_obj, int flags)
> exp_info.priv = gem_obj;
> exp_info.resv = obj->base.resv;
>
>+ GEM_BUG_ON(obj->base.import_attach != NULL);
>+
> if (obj->ops->dmabuf_export) {
> int ret = obj->ops->dmabuf_export(obj);
> if (ret)
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>index 0c5c43852e24..d963cf35fdc9 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>@@ -64,7 +64,9 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void
>*data,
> struct drm_i915_private *i915 = to_i915(dev);
> struct drm_i915_gem_mmap *args = data;
> struct drm_i915_gem_object *obj;
>+ struct file *filp;
> unsigned long addr;
>+ int ret;
>
> /*
>* mmap ioctl is disallowed for all discrete platforms,
>@@ -83,12 +85,20 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void
>*data,
> if (!obj)
> return -ENOENT;
>
>- /* prime objects have no backing filp to GEM mmap
>- * pages from.
>- */
>- if (!obj->base.filp) {
>- addr = -ENXIO;
>- goto err;
>+ if (obj->base.import_attach)
>+ filp = obj->base.filp;
Why is this now ok? This is the imported object. And it used to give an error.
If you are importing from a different device, (i.e. an amd device is exporting
the object, and you are i915 here), can you even do this?
My understanding was that mmaping was only for the exported object.
Has this changed?
Thanks,
Mike
>+ else {
>+ ret = i915_gem_object_pin_pages_unlocked(obj);
>+ if (ret) {
>+ addr = ret;
>+ goto err_pin;
>+ }
>+
>+ filp = i915_gem_ttm_get_filep(obj);
>+
Re: [Intel-gfx] [PATCH 1/2] drm/i915/gem: Make our dma-buf exporter dynamic
>-Original Message-
>From: Daniel Vetter
>Sent: Wednesday, June 30, 2021 10:02 AM
>To: Thomas Hellström ; Christian König
>
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Auld,
>Matthew ; maarten.lankho...@linux.intel.com;
>dan...@ffwll.ch; Ruhl, Michael J
>Subject: Re: [PATCH 1/2] drm/i915/gem: Make our dma-buf exporter dynamic
>
>On Wed, Jun 30, 2021 at 03:07:00PM +0200, Thomas Hellström wrote:
>> If our exported dma-bufs are imported by another instance of our driver,
>> that instance will typically have the imported dma-bufs locked during
>> dma_buf_map_attachment(). But the exporter also locks the same
>reservation
>> object in the map_dma_buf() callback, which leads to recursive locking.
>>
>> Add a live selftest to exercise both dynamic and non-dynamic exports,
>> and as a workaround until we fully support dynamic import and export,
>> declare the exporter dynamic by providing pin() and unpin()
>implementations.
>> For dynamic importers, make sure we keep the pinning also in
>map_dma_buf(),
>> to ensure we never need to call dma_buf_move_notify().
>> Calling dma_buf_move_notify() is at the discretion of the exporter.
>>
>> v2:
>> - Extend the selftest with a fake dynamic importer.
>> - Provide real pin and unpin callbacks to not abuse the interface.
>>
>> Reported-by: Michael J. Ruhl
>> Signed-off-by: Thomas Hellström
>
>I'm not happy with this, because i915 is currently violating the dma-resv
>fencing rules for dynamic dma-buf.
>
>Yes since this is just the exporter we can probably get away with yolo'ing
>things, but Christian and me just spend a lot of angry typing figuring out
>what the rules actually are, so I really don't like bending them even more
>just because it's less typing.
>
>All we need for a quick interim fix is to not take the dma_resv_lock from
>our map/unamp callbacks. Pinning our backing storage from attach/detach
>callbacks (which are also called under dma_resv_lock) would also achieve
>that, without mudding any waters. So essentially just moving the
>pin/unpin_pages_unlocked and we should be good, which is almost as little
>typing.
>
>Michael, since Thomas is on vacations now, care to type that up? The
>selftest is imo solid.
Yes, I will get that done.
Mike
>This is also consistent with what all other ttm based drivers do (aside
>from amdgpu, which is fully dynamic), see drm_gem_map_attach in
>drm_prime.c
>
>Adding Christian as fyi.
>-Daniel
>
>> ---
>> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 31 -
>> .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 116
>+-
>> 2 files changed, 143 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> index 616c3a2f1baf..918c19df7b66 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> @@ -12,6 +12,8 @@
>> #include "i915_gem_object.h"
>> #include "i915_scatterlist.h"
>>
>> +I915_SELFTEST_DECLARE(static bool force_different_devices;)
>> +
>> static struct drm_i915_gem_object *dma_buf_to_obj(struct dma_buf
>*buf)
>> {
>> return to_intel_bo(buf->priv);
>> @@ -25,7 +27,14 @@ static struct sg_table
>*i915_gem_map_dma_buf(struct dma_buf_attachment *attachme
>> struct scatterlist *src, *dst;
>> int ret, i;
>>
>> -ret = i915_gem_object_pin_pages_unlocked(obj);
>> +assert_object_held(obj);
>> +
>> +/*
>> + * Note. In the dynamic importer case, the object is not yet pinned.
>> + * Let's pin it here to avoid having to call the move_notify
>> + * callback, The call of which is not yet implemented.
>> + */
>> +ret = i915_gem_object_pin_pages(obj);
>> if (ret)
>> goto err;
>>
>> @@ -168,6 +177,21 @@ static int i915_gem_end_cpu_access(struct
>dma_buf *dma_buf, enum dma_data_direct
>> return err;
>> }
>>
>> +static int i915_gem_dmabuf_pin(struct dma_buf_attachment *attach)
>> +{
>> +struct drm_i915_gem_object *obj = dma_buf_to_obj(attach-
>>dmabuf);
>> +
>> +assert_object_held(obj);
>> +return i915_gem_object_pin_pages(obj);
>> +}
>> +
>> +static void i915_gem_dmabuf_unpin(struct dma_buf_attachment *attach)
>> +{
>> +struct drm_i915_gem_object *obj = dma_buf_to_obj(attach-
>>dmabuf);
>> +
>> +i915_gem_object_unpin_pages(obj);
>> +}
>> +
>> static const struct
Re: [Intel-gfx] [PATCH v3 1/5] drm/i915/gem: Implement object migration
>-Original Message-
>From: Thomas Hellström
>Sent: Monday, June 28, 2021 3:54 PM
>To: Ruhl, Michael J ; intel-
>g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org
>Cc: Auld, Matthew ; lkp
>Subject: Re: [PATCH v3 1/5] drm/i915/gem: Implement object migration
>
>
>On 6/28/21 9:50 PM, Ruhl, Michael J wrote:
>>> -Original Message-
>>> From: Thomas Hellström
>>> Sent: Monday, June 28, 2021 3:03 PM
>>> To: Ruhl, Michael J ; intel-
>>> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org
>>> Cc: Auld, Matthew ; lkp
>>> Subject: Re: [PATCH v3 1/5] drm/i915/gem: Implement object migration
>>>
>>>
>>> On 6/28/21 8:11 PM, Ruhl, Michael J wrote:
>>>>> -Original Message-
>>>>> From: dri-devel On Behalf
>Of
>>>>> Thomas Hellström
>>>>> Sent: Monday, June 28, 2021 10:46 AM
>>>>> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
>>>>> Cc: Thomas Hellström ; Auld,
>>> Matthew
>>>>> ; lkp
>>>>> Subject: [PATCH v3 1/5] drm/i915/gem: Implement object migration
>>>>>
>>>>> Introduce an interface to migrate objects between regions.
>>>>> This is primarily intended to migrate objects to LMEM for display and
>>>>> to SYSTEM for dma-buf, but might be reused in one form or another for
>>>>> performance-based migration.
>>>>>
>>>>> v2:
>>>>> - Verify that the memory region given as an id really exists.
>>>>>(Reported by Matthew Auld)
>>>>> - Call i915_gem_object_{init,release}_memory_region() when switching
>>>>> region
>>>>>to handle also switching region lists. (Reported by Matthew Auld)
>>>>> v3:
>>>>> - Fix i915_gem_object_can_migrate() to return true if object is already
>in
>>>>>the correct region, even if the object ops doesn't have a migrate()
>>>>>callback.
>>>>> - Update typo in commit message.
>>>>> - Fix kerneldoc of i915_gem_object_wait_migration().
>>>>>
>>>>> Reported-by: kernel test robot
>>>>> Signed-off-by: Thomas Hellström
>>>>> ---
>>>>> drivers/gpu/drm/i915/gem/i915_gem_object.c| 96
>>>>> +++
>>>>> drivers/gpu/drm/i915/gem/i915_gem_object.h| 12 +++
>>>>> .../gpu/drm/i915/gem/i915_gem_object_types.h | 9 ++
>>>>> drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 69 +
>>>>> drivers/gpu/drm/i915/gem/i915_gem_wait.c | 19
>>>>> 5 files changed, 188 insertions(+), 17 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>>>>> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>>>>> index 07e8ff9a8aae..1c18be067b58 100644
>>>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>>>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>>>>> @@ -513,6 +513,102 @@ bool i915_gem_object_has_iomem(const
>struct
>>>>> drm_i915_gem_object *obj)
>>>>> return obj->mem_flags & I915_BO_FLAG_IOMEM;
>>>>> }
>>>>>
>>>>> +/**
>>>>> + * i915_gem_object_can_migrate - Whether an object likely can be
>>> migrated
>>>>> + *
>>>>> + * @obj: The object to migrate
>>>>> + * @id: The region intended to migrate to
>>>>> + *
>>>>> + * Check whether the object backend supports migration to the
>>>>> + * given region. Note that pinning may affect the ability to migrate.
>>>>> + *
>>>>> + * Return: true if migration is possible, false otherwise.
>>>>> + */
>>>>> +bool i915_gem_object_can_migrate(struct drm_i915_gem_object
>*obj,
>>>>> + enum intel_region_id id)
>>>>> +{
>>>>> + struct drm_i915_private *i915 = to_i915(obj->base.dev);
>>>>> + unsigned int num_allowed = obj->mm.n_placements;
>>>>> + struct intel_memory_region *mr;
>>>>> + unsigned int i;
>>>>> +
>>>>> + GEM_BUG_ON(id >= INTEL_REGION_UNKNOWN);
>>>>> + GEM_BUG_ON(obj->mm.madv != I915_MADV_WILLNEED);
>>>>> +
>>>>> + mr = i915->mm.regions[id];
>>>>> + if (!mr)
>>>>>
Re: [Intel-gfx] [PATCH v3 1/5] drm/i915/gem: Implement object migration
>-Original Message-
>From: Thomas Hellström
>Sent: Monday, June 28, 2021 3:03 PM
>To: Ruhl, Michael J ; intel-
>g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org
>Cc: Auld, Matthew ; lkp
>Subject: Re: [PATCH v3 1/5] drm/i915/gem: Implement object migration
>
>
>On 6/28/21 8:11 PM, Ruhl, Michael J wrote:
>>> -Original Message-
>>> From: dri-devel On Behalf Of
>>> Thomas Hellström
>>> Sent: Monday, June 28, 2021 10:46 AM
>>> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
>>> Cc: Thomas Hellström ; Auld,
>Matthew
>>> ; lkp
>>> Subject: [PATCH v3 1/5] drm/i915/gem: Implement object migration
>>>
>>> Introduce an interface to migrate objects between regions.
>>> This is primarily intended to migrate objects to LMEM for display and
>>> to SYSTEM for dma-buf, but might be reused in one form or another for
>>> performance-based migration.
>>>
>>> v2:
>>> - Verify that the memory region given as an id really exists.
>>> (Reported by Matthew Auld)
>>> - Call i915_gem_object_{init,release}_memory_region() when switching
>>> region
>>> to handle also switching region lists. (Reported by Matthew Auld)
>>> v3:
>>> - Fix i915_gem_object_can_migrate() to return true if object is already in
>>> the correct region, even if the object ops doesn't have a migrate()
>>> callback.
>>> - Update typo in commit message.
>>> - Fix kerneldoc of i915_gem_object_wait_migration().
>>>
>>> Reported-by: kernel test robot
>>> Signed-off-by: Thomas Hellström
>>> ---
>>> drivers/gpu/drm/i915/gem/i915_gem_object.c| 96
>>> +++
>>> drivers/gpu/drm/i915/gem/i915_gem_object.h| 12 +++
>>> .../gpu/drm/i915/gem/i915_gem_object_types.h | 9 ++
>>> drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 69 +
>>> drivers/gpu/drm/i915/gem/i915_gem_wait.c | 19
>>> 5 files changed, 188 insertions(+), 17 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>>> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>>> index 07e8ff9a8aae..1c18be067b58 100644
>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>>> @@ -513,6 +513,102 @@ bool i915_gem_object_has_iomem(const struct
>>> drm_i915_gem_object *obj)
>>> return obj->mem_flags & I915_BO_FLAG_IOMEM;
>>> }
>>>
>>> +/**
>>> + * i915_gem_object_can_migrate - Whether an object likely can be
>migrated
>>> + *
>>> + * @obj: The object to migrate
>>> + * @id: The region intended to migrate to
>>> + *
>>> + * Check whether the object backend supports migration to the
>>> + * given region. Note that pinning may affect the ability to migrate.
>>> + *
>>> + * Return: true if migration is possible, false otherwise.
>>> + */
>>> +bool i915_gem_object_can_migrate(struct drm_i915_gem_object *obj,
>>> +enum intel_region_id id)
>>> +{
>>> + struct drm_i915_private *i915 = to_i915(obj->base.dev);
>>> + unsigned int num_allowed = obj->mm.n_placements;
>>> + struct intel_memory_region *mr;
>>> + unsigned int i;
>>> +
>>> + GEM_BUG_ON(id >= INTEL_REGION_UNKNOWN);
>>> + GEM_BUG_ON(obj->mm.madv != I915_MADV_WILLNEED);
>>> +
>>> + mr = i915->mm.regions[id];
>>> + if (!mr)
>>> + return false;
>>> +
>>> + if (obj->mm.region == mr)
>>> + return true;
>>> +
>>> + if (!i915_gem_object_evictable(obj))
>>> + return false;
>>> +
>>> + if (!obj->ops->migrate)
>>> + return false;
>>> +
>>> + if (!(obj->flags & I915_BO_ALLOC_USER))
>>> + return true;
>>> +
>>> + if (num_allowed == 0)
>>> + return false;
>>> +
>>> + for (i = 0; i < num_allowed; ++i) {
>>> + if (mr == obj->mm.placements[i])
>>> + return true;
>>> + }
>> Hi Thomas,
>>
>> I am a little confused over the difference in checks between this function
>> and i915_gem_object_migrate().
>>
>> Why is the lack of an mr a BUG_ON in _object_migrate(), but here it just
>> false?
>>
>> So that means that under cert
Re: [Intel-gfx] [PATCH v3 5/5] drm/i915/gem: Migrate to system at dma-buf map time
>-Original Message- >From: dri-devel On Behalf Of >Thomas Hellström >Sent: Monday, June 28, 2021 10:46 AM >To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org >Cc: Thomas Hellström ; Auld, Matthew > >Subject: [PATCH v3 5/5] drm/i915/gem: Migrate to system at dma-buf map >time > >Until we support p2p dma or as a complement to that, migrate data >to system memory at dma-buf map time if possible. > >v2: >- Rebase on dynamic exporter. Update the igt_dmabuf_import_same_driver > selftest to migrate if we are LMEM capable. > >Signed-off-by: Thomas Hellström >--- > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 7 ++- > drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 4 +++- > 2 files changed, 9 insertions(+), 2 deletions(-) > >diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >index 1d1eeb167d28..5207aa3af009 100644 >--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >@@ -29,7 +29,12 @@ static struct sg_table *i915_gem_map_dma_buf(struct >dma_buf_attachment *attachme > > assert_object_held(obj); > >- ret = i915_gem_object_pin_pages(obj); >+ if (!i915_gem_object_can_migrate(obj, INTEL_REGION_SMEM)) >+ return ERR_PTR(-EOPNOTSUPP); >+ >+ ret = i915_gem_object_migrate(obj, NULL, INTEL_REGION_SMEM); >+ if (!ret) >+ ret = i915_gem_object_pin_pages(obj); > if (ret) > goto err; With the caveats of the previous patches this looks good. Reviewed-by: Michael J. Ruhl Mike >diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c >b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c >index 24735d6c12a2..b6278dba98d0 100644 >--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c >+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c >@@ -94,7 +94,9 @@ static int igt_dmabuf_import_same_driver(void *arg) > int err; > > force_different_devices = true; >- obj = i915_gem_object_create_shmem(i915, PAGE_SIZE); >+ obj = i915_gem_object_create_lmem(i915, PAGE_SIZE, 0); >+ if (IS_ERR(obj)) >+ obj = i915_gem_object_create_shmem(i915, PAGE_SIZE); > if (IS_ERR(obj)) > goto out_ret; > >-- >2.31.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 4/5] drm/i915/gem: Fix same-driver-another-instance dma-buf export
>-Original Message-
>From: Thomas Hellström
>Sent: Monday, June 28, 2021 10:46 AM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
>Cc: Auld, Matthew ;
>maarten.lankho...@linux.intel.com; Thomas Hellström
>; Ruhl; Ruhl, Michael J
>
>Subject: [PATCH v3 4/5] drm/i915/gem: Fix same-driver-another-instance
>dma-buf export
>
>If our exported dma-bufs are imported by another instance of our driver,
>that instance will typically have the imported dma-bufs locked during
>map_attachment(). But the exporter also locks the same reservation
>object in the map_dma_buf() callback, which leads to recursive locking.
>
>Add a live selftest to catch this case, and as a workaround until
>we fully support dynamic import and export, declare the exporter dynamic
>by providing NOP pin() and unpin() functions. This means our map_dma_buf()
>callback will *always* get called locked, and by pinning unconditionally
>in i915_gem_map_dma_buf() we make sure we don't need to use the
>move_notify() functionality which is not yet implemented.
An interesting abuse of the interface, but it seems reasonable (for now) to me.
Reviewed-by: Michael J. Ruhl
Mike
>Reported-by: Ruhl, Michael J
>Cc: Ruhl, Michael J
>Signed-off-by: Thomas Hellström
>---
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 31 ++-
> .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 81
>++-
> 2 files changed, 108 insertions(+), 4 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>index 616c3a2f1baf..1d1eeb167d28 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>@@ -12,6 +12,8 @@
> #include "i915_gem_object.h"
> #include "i915_scatterlist.h"
>
>+I915_SELFTEST_DECLARE(static bool force_different_devices;)
>+
> static struct drm_i915_gem_object *dma_buf_to_obj(struct dma_buf *buf)
> {
> return to_intel_bo(buf->priv);
>@@ -25,7 +27,9 @@ static struct sg_table *i915_gem_map_dma_buf(struct
>dma_buf_attachment *attachme
> struct scatterlist *src, *dst;
> int ret, i;
>
>- ret = i915_gem_object_pin_pages_unlocked(obj);
>+ assert_object_held(obj);
>+
>+ ret = i915_gem_object_pin_pages(obj);
> if (ret)
> goto err;
>
>@@ -168,6 +172,26 @@ static int i915_gem_end_cpu_access(struct dma_buf
>*dma_buf, enum dma_data_direct
> return err;
> }
>
>+/*
>+ * As a workaround until we fully support dynamic import and export,
>+ * declare the exporter dynamic by providing NOP pin() and unpin()
>functions.
>+ * This means our i915_gem_map_dma_buf() callback will *always* get
>called
>+ * locked, and by pinning unconditionally in i915_gem_map_dma_buf() we
>make
>+ * sure we don't need to use the move_notify() functionality which is
>+ * not yet implemented. Typically for the same-driver-another-instance case,
>+ * i915_gem_map_dma_buf() will be called at importer attach time and the
>+ * mapped sg_list will be cached by the dma-buf core for the
>+ * duration of the attachment.
>+ */
>+static int i915_gem_dmabuf_pin(struct dma_buf_attachment *attach)
>+{
>+ return 0;
>+}
>+
>+static void i915_gem_dmabuf_unpin(struct dma_buf_attachment *attach)
>+{
>+}
>+
> static const struct dma_buf_ops i915_dmabuf_ops = {
> .map_dma_buf = i915_gem_map_dma_buf,
> .unmap_dma_buf = i915_gem_unmap_dma_buf,
>@@ -177,6 +201,8 @@ static const struct dma_buf_ops i915_dmabuf_ops = {
> .vunmap = i915_gem_dmabuf_vunmap,
> .begin_cpu_access = i915_gem_begin_cpu_access,
> .end_cpu_access = i915_gem_end_cpu_access,
>+ .pin = i915_gem_dmabuf_pin,
>+ .unpin = i915_gem_dmabuf_unpin,
> };
>
> struct dma_buf *i915_gem_prime_export(struct drm_gem_object
>*gem_obj, int flags)
>@@ -241,7 +267,8 @@ struct drm_gem_object
>*i915_gem_prime_import(struct drm_device *dev,
> if (dma_buf->ops == _dmabuf_ops) {
> obj = dma_buf_to_obj(dma_buf);
> /* is it from our device? */
>- if (obj->base.dev == dev) {
>+ if (obj->base.dev == dev &&
>+ !I915_SELFTEST_ONLY(force_different_devices)) {
> /*
>* Importing dmabuf exported from out own gem
>increases
>* refcount on gem itself instead of f_count of
>dmabuf.
>diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>index dd74bc09ec88..24735d6c12a2 100644
>--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>+++ b/d
Re: [Intel-gfx] [PATCH v3 2/5] drm/i915/gem: Introduce a selftest for the gem object migrate functionality
>-Original Message-
>From: Thomas Hellström
>Sent: Monday, June 28, 2021 3:15 PM
>To: Ruhl, Michael J ; intel-
>g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org
>Cc: Auld, Matthew
>Subject: Re: [Intel-gfx] [PATCH v3 2/5] drm/i915/gem: Introduce a selftest for
>the gem object migrate functionality
>
>On Mon, 2021-06-28 at 18:53 +, Ruhl, Michael J wrote:
>> > -Original Message-
>> > From: Intel-gfx On Behalf
>> > Of
>> > Thomas Hellström
>> > Sent: Monday, June 28, 2021 10:46 AM
>> > To: intel-gfx@lists.freedesktop.org;
>> > dri-de...@lists.freedesktop.org
>> > Cc: Thomas Hellström ; Auld,
>> > Matthew
>> >
>> > Subject: [Intel-gfx] [PATCH v3 2/5] drm/i915/gem: Introduce a
>> > selftest for the
>> > gem object migrate functionality
>> >
>> > From: Matthew Auld
>> >
>> > A selftest for the gem object migrate functionality. Slightly
>> > adapted
>> > from the original by Matthew to the new interface and new fill blit
>> > code.
>> >
>> > Co-developed-by: Thomas Hellström
>> >
>> > Signed-off-by: Thomas Hellström
>> > Signed-off-by: Matthew Auld
>> > ---
>> > drivers/gpu/drm/i915/gem/i915_gem_object.c | 1 +
>> > .../drm/i915/gem/selftests/i915_gem_migrate.c | 237
>> > ++
>> > .../drm/i915/selftests/i915_live_selftests.h | 1 +
>> > 3 files changed, 239 insertions(+)
>> > create mode 100644
>> > drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
>> >
>> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> > b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> > index 1c18be067b58..ff147fd59874 100644
>> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> > @@ -649,6 +649,7 @@ static const struct drm_gem_object_funcs
>> > i915_gem_object_funcs = {
>> > #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
>> > #include "selftests/huge_gem_object.c"
>> > #include "selftests/huge_pages.c"
>> > +#include "selftests/i915_gem_migrate.c"
>> > #include "selftests/i915_gem_object.c"
>> > #include "selftests/i915_gem_coherency.c"
>> > #endif
>> > diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
>> > b/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
>> > new file mode 100644
>> > index ..a437b66f64d9
>> > --- /dev/null
>> > +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
>> > @@ -0,0 +1,237 @@
>> > +// SPDX-License-Identifier: MIT
>> > +/*
>> > + * Copyright © 2020-2021 Intel Corporation
>> > + */
>> > +
>> > +#include "gt/intel_migrate.h"
>> > +
>> > +static int igt_smem_create_migrate(void *arg)
>> > +{
>> > + struct intel_gt *gt = arg;
>> > + struct drm_i915_private *i915 = gt->i915;
>> > + struct drm_i915_gem_object *obj;
>> > + struct i915_gem_ww_ctx ww;
>> > + int err = 0;
>> > +
>> > + /* Switch object backing-store on create */
>> > + obj = i915_gem_object_create_lmem(i915, PAGE_SIZE, 0);
>> > + if (IS_ERR(obj))
>> > + return PTR_ERR(obj);
>> > +
>> > + for_i915_gem_ww(, err, true) {
>> > + err = i915_gem_object_lock(obj, );
>> > + if (err)
>> > + continue;
>> > +
>> > + if (!i915_gem_object_can_migrate(obj,
>> > INTEL_REGION_SMEM)) {
>> > + err = -EINVAL;
>> > + continue;
>> > + }
>> > +
>> > + err = i915_gem_object_migrate(obj, ,
>> > INTEL_REGION_SMEM);
>> > + if (err)
>> > + continue;
>> > +
>> > + err = i915_gem_object_pin_pages(obj);
>> > + if (err)
>> > + continue;
>> > +
>> > + if (i915_gem_object_can_migrate(obj,
>> > INTEL_REGION_LMEM))
>> > + err = -EINVAL;
>> > +
>> > + i915_gem_object_unpin_pages(obj);
>> > + }
>> > + i915_gem_object_put(obj);
>> > +
>> > +
Re: [Intel-gfx] [PATCH v3 2/5] drm/i915/gem: Introduce a selftest for the gem object migrate functionality
>-Original Message-
>From: Intel-gfx On Behalf Of
>Thomas Hellström
>Sent: Monday, June 28, 2021 10:46 AM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
>Cc: Thomas Hellström ; Auld, Matthew
>
>Subject: [Intel-gfx] [PATCH v3 2/5] drm/i915/gem: Introduce a selftest for the
>gem object migrate functionality
>
>From: Matthew Auld
>
>A selftest for the gem object migrate functionality. Slightly adapted
>from the original by Matthew to the new interface and new fill blit
>code.
>
>Co-developed-by: Thomas Hellström
>Signed-off-by: Thomas Hellström
>Signed-off-by: Matthew Auld
>---
> drivers/gpu/drm/i915/gem/i915_gem_object.c| 1 +
> .../drm/i915/gem/selftests/i915_gem_migrate.c | 237
>++
> .../drm/i915/selftests/i915_live_selftests.h | 1 +
> 3 files changed, 239 insertions(+)
> create mode 100644
>drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>index 1c18be067b58..ff147fd59874 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>@@ -649,6 +649,7 @@ static const struct drm_gem_object_funcs
>i915_gem_object_funcs = {
> #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
> #include "selftests/huge_gem_object.c"
> #include "selftests/huge_pages.c"
>+#include "selftests/i915_gem_migrate.c"
> #include "selftests/i915_gem_object.c"
> #include "selftests/i915_gem_coherency.c"
> #endif
>diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
>b/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
>new file mode 100644
>index ..a437b66f64d9
>--- /dev/null
>+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
>@@ -0,0 +1,237 @@
>+// SPDX-License-Identifier: MIT
>+/*
>+ * Copyright © 2020-2021 Intel Corporation
>+ */
>+
>+#include "gt/intel_migrate.h"
>+
>+static int igt_smem_create_migrate(void *arg)
>+{
>+ struct intel_gt *gt = arg;
>+ struct drm_i915_private *i915 = gt->i915;
>+ struct drm_i915_gem_object *obj;
>+ struct i915_gem_ww_ctx ww;
>+ int err = 0;
>+
>+ /* Switch object backing-store on create */
>+ obj = i915_gem_object_create_lmem(i915, PAGE_SIZE, 0);
>+ if (IS_ERR(obj))
>+ return PTR_ERR(obj);
>+
>+ for_i915_gem_ww(, err, true) {
>+ err = i915_gem_object_lock(obj, );
>+ if (err)
>+ continue;
>+
>+ if (!i915_gem_object_can_migrate(obj,
>INTEL_REGION_SMEM)) {
>+ err = -EINVAL;
>+ continue;
>+ }
>+
>+ err = i915_gem_object_migrate(obj, ,
>INTEL_REGION_SMEM);
>+ if (err)
>+ continue;
>+
>+ err = i915_gem_object_pin_pages(obj);
>+ if (err)
>+ continue;
>+
>+ if (i915_gem_object_can_migrate(obj,
>INTEL_REGION_LMEM))
>+ err = -EINVAL;
>+
>+ i915_gem_object_unpin_pages(obj);
>+ }
>+ i915_gem_object_put(obj);
>+
>+ return err;
>+}
>+
>+static int igt_lmem_create_migrate(void *arg)
>+{
>+ struct intel_gt *gt = arg;
>+ struct drm_i915_private *i915 = gt->i915;
>+ struct drm_i915_gem_object *obj;
>+ struct i915_gem_ww_ctx ww;
>+ int err = 0;
>+
>+ /* Switch object backing-store on create */
>+ obj = i915_gem_object_create_shmem(i915, PAGE_SIZE);
>+ if (IS_ERR(obj))
>+ return PTR_ERR(obj);
>+
>+ for_i915_gem_ww(, err, true) {
>+ err = i915_gem_object_lock(obj, );
>+ if (err)
>+ continue;
>+
>+ if (!i915_gem_object_can_migrate(obj,
>INTEL_REGION_LMEM)) {
>+ err = -EINVAL;
>+ continue;
>+ }
>+
>+ err = i915_gem_object_migrate(obj, ,
>INTEL_REGION_LMEM);
>+ if (err)
>+ continue;
>+
>+ err = i915_gem_object_pin_pages(obj);
>+ if (err)
>+ continue;
>+
>+ if (i915_gem_object_can_migrate(obj,
>INTEL_REGION_SMEM))
>+ err = -EINVAL;
>+
>+ i915_gem_object_unpin_pages(obj);
>+ }
>+ i915_gem_object_put(obj);
>+
>+ return err;
>+}
>+
>+static int lmem_pages_migrate_one(struct i915_gem_ww_ctx *ww,
>+struct drm_i915_gem_object *obj)
>+{
>+ int err;
>+
>+ err = i915_gem_object_lock(obj, ww);
>+ if (err)
>+ return err;
>+
>+ err = i915_gem_object_wait(obj,
>+ I915_WAIT_INTERRUPTIBLE |
>+ I915_WAIT_PRIORITY |
>+ I915_WAIT_ALL,
>+ MAX_SCHEDULE_TIMEOUT);
>+ if (err)
>+ return err;
>+
>+ if (i915_gem_object_is_lmem(obj)) {
>+ if
Re: [Intel-gfx] [PATCH v3 1/5] drm/i915/gem: Implement object migration
>-Original Message-
>From: dri-devel On Behalf Of
>Thomas Hellström
>Sent: Monday, June 28, 2021 10:46 AM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
>Cc: Thomas Hellström ; Auld, Matthew
>; lkp
>Subject: [PATCH v3 1/5] drm/i915/gem: Implement object migration
>
>Introduce an interface to migrate objects between regions.
>This is primarily intended to migrate objects to LMEM for display and
>to SYSTEM for dma-buf, but might be reused in one form or another for
>performance-based migration.
>
>v2:
>- Verify that the memory region given as an id really exists.
> (Reported by Matthew Auld)
>- Call i915_gem_object_{init,release}_memory_region() when switching
>region
> to handle also switching region lists. (Reported by Matthew Auld)
>v3:
>- Fix i915_gem_object_can_migrate() to return true if object is already in
> the correct region, even if the object ops doesn't have a migrate()
> callback.
>- Update typo in commit message.
>- Fix kerneldoc of i915_gem_object_wait_migration().
>
>Reported-by: kernel test robot
>Signed-off-by: Thomas Hellström
>---
> drivers/gpu/drm/i915/gem/i915_gem_object.c| 96
>+++
> drivers/gpu/drm/i915/gem/i915_gem_object.h| 12 +++
> .../gpu/drm/i915/gem/i915_gem_object_types.h | 9 ++
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 69 +
> drivers/gpu/drm/i915/gem/i915_gem_wait.c | 19
> 5 files changed, 188 insertions(+), 17 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>index 07e8ff9a8aae..1c18be067b58 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>@@ -513,6 +513,102 @@ bool i915_gem_object_has_iomem(const struct
>drm_i915_gem_object *obj)
> return obj->mem_flags & I915_BO_FLAG_IOMEM;
> }
>
>+/**
>+ * i915_gem_object_can_migrate - Whether an object likely can be migrated
>+ *
>+ * @obj: The object to migrate
>+ * @id: The region intended to migrate to
>+ *
>+ * Check whether the object backend supports migration to the
>+ * given region. Note that pinning may affect the ability to migrate.
>+ *
>+ * Return: true if migration is possible, false otherwise.
>+ */
>+bool i915_gem_object_can_migrate(struct drm_i915_gem_object *obj,
>+ enum intel_region_id id)
>+{
>+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
>+ unsigned int num_allowed = obj->mm.n_placements;
>+ struct intel_memory_region *mr;
>+ unsigned int i;
>+
>+ GEM_BUG_ON(id >= INTEL_REGION_UNKNOWN);
>+ GEM_BUG_ON(obj->mm.madv != I915_MADV_WILLNEED);
>+
>+ mr = i915->mm.regions[id];
>+ if (!mr)
>+ return false;
>+
>+ if (obj->mm.region == mr)
>+ return true;
>+
>+ if (!i915_gem_object_evictable(obj))
>+ return false;
>+
>+ if (!obj->ops->migrate)
>+ return false;
>+
>+ if (!(obj->flags & I915_BO_ALLOC_USER))
>+ return true;
>+
>+ if (num_allowed == 0)
>+ return false;
>+
>+ for (i = 0; i < num_allowed; ++i) {
>+ if (mr == obj->mm.placements[i])
>+ return true;
>+ }
Hi Thomas,
I am a little confused over the difference in checks between this function
and i915_gem_object_migrate().
Why is the lack of an mr a BUG_ON in _object_migrate(), but here it just
false?
So that means that under certain circumstances, you could not have a mr?
If that is the case, when?
Would that be when the I915_BO_ALLOC_USER is set?
If so, should there be a check for "non" user vs user?
Or maybe document this function pointing out why there are differences
and why?
>+ return false;
>+}
>+
>+/**
>+ * i915_gem_object_migrate - Migrate an object to the desired region id
>+ * @obj: The object to migrate.
>+ * @ww: An optional struct i915_gem_ww_ctx. If NULL, the backend may
>+ * not be successful in evicting other objects to make room for this object.
Is the ww for future consideration? (I don't see any use of it in the patch).
>+ * @id: The region id to migrate to.
>+ *
>+ * Attempt to migrate the object to the desired memory region. The
>+ * object backend must support migration and the object may not be
>+ * pinned, (explicitly pinned pages or pinned vmas). The object must
>+ * be locked.
>+ * On successful completion, the object will have pages pointing to
>+ * memory in the new region, but an async migration task may not have
>+ * completed yet, and to accomplish that,
>i915_gem_object_wait_migration()
>+ * must be called.
>+ *
>+ * Return: 0 on success. Negative error code on failure. In particular may
>+ * return -ENXIO on lack of region space, -EDEADLK for deadlock avoidance
>+ * if @ww is set, -EINTR or -ERESTARTSYS if signal pending, and
>+ * -EBUSY if the object is pinned.
>+ */
>+int i915_gem_object_migrate(struct drm_i915_gem_object *obj,
>+ struct
Re: [Intel-gfx] [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map time
>-Original Message- >From: Thomas Hellström >Sent: Friday, June 25, 2021 3:10 PM>To: Ruhl, Michael J >; intel- >g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org >Cc: Auld, Matthew >Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map >time > > >On 6/25/21 9:07 PM, Ruhl, Michael J wrote: >>> -Original Message- >>> From: Thomas Hellström >>> Sent: Friday, June 25, 2021 2:50 PM >>> To: Ruhl, Michael J ; intel- >>> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org >>> Cc: Auld, Matthew >>> Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf >map >>> time >>> >>> Hi, Mike, >>> >>> On 6/25/21 7:57 PM, Ruhl, Michael J wrote: >>>>> -Original Message- >>>>> From: Thomas Hellström >>>>> Sent: Friday, June 25, 2021 1:52 PM >>>>> To: Ruhl, Michael J ; intel- >>>>> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org >>>>> Cc: Auld, Matthew >>>>> Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf >>> map >>>>> time >>>>> >>>>> >>>>> On 6/25/21 7:38 PM, Ruhl, Michael J wrote: >>>>>>> -Original Message- >>>>>>> From: Thomas Hellström >>>>>>> Sent: Friday, June 25, 2021 12:18 PM >>>>>>> To: Ruhl, Michael J ; intel- >>>>>>> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org >>>>>>> Cc: Auld, Matthew >>>>>>> Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma- >buf >>>>> map >>>>>>> time >>>>>>> >>>>>>> Hi, Michael, >>>>>>> >>>>>>> thanks for looking at this. >>>>>>> >>>>>>> On 6/25/21 6:02 PM, Ruhl, Michael J wrote: >>>>>>>>> -Original Message- >>>>>>>>> From: dri-devel On >>> Behalf >>>>> Of >>>>>>>>> Thomas Hellström >>>>>>>>> Sent: Thursday, June 24, 2021 2:31 PM >>>>>>>>> To: intel-gfx@lists.freedesktop.org; dri- >de...@lists.freedesktop.org >>>>>>>>> Cc: Thomas Hellström ; Auld, >>>>>>> Matthew >>>>>>>>> >>>>>>>>> Subject: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf >>> map >>>>>>> time >>>>>>>>> Until we support p2p dma or as a complement to that, migrate data >>>>>>>>> to system memory at dma-buf map time if possible. >>>>>>>>> >>>>>>>>> Signed-off-by: Thomas Hellström >>> >>>>>>>>> --- >>>>>>>>> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 9 - >>>>>>>>> 1 file changed, 8 insertions(+), 1 deletion(-) >>>>>>>>> >>>>>>>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>>>>>>>> b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>>>>>>>> index 616c3a2f1baf..a52f885bc09a 100644 >>>>>>>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>>>>>>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>>>>>>>> @@ -25,7 +25,14 @@ static struct sg_table >>>>>>> *i915_gem_map_dma_buf(struct >>>>>>>>> dma_buf_attachment *attachme >>>>>>>>> struct scatterlist *src, *dst; >>>>>>>>> int ret, i; >>>>>>>>> >>>>>>>>> - ret = i915_gem_object_pin_pages_unlocked(obj); >>>>>>>>> + ret = i915_gem_object_lock_interruptible(obj, NULL); >>>>>>>> Hmm, I believe in most cases that the caller should be holding the >>>>>>>> lock (object dma-resv) on this object already. >>>>>>> Yes, I agree, In particular for other instances of our own driver, at >>>>>>> least since the dma_resv introduction. >>>>>>> >>>>>>> But I also think that's a pre-existing bug, since >>>>>>> i915_gem_object_pin_pages_unlocked() will also take the lock. >&g
Re: [Intel-gfx] [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map time
>-Original Message- >From: Thomas Hellström >Sent: Friday, June 25, 2021 2:50 PM >To: Ruhl, Michael J ; intel- >g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org >Cc: Auld, Matthew >Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map >time > >Hi, Mike, > >On 6/25/21 7:57 PM, Ruhl, Michael J wrote: >>> -Original Message- >>> From: Thomas Hellström >>> Sent: Friday, June 25, 2021 1:52 PM >>> To: Ruhl, Michael J ; intel- >>> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org >>> Cc: Auld, Matthew >>> Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf >map >>> time >>> >>> >>> On 6/25/21 7:38 PM, Ruhl, Michael J wrote: >>>>> -Original Message- >>>>> From: Thomas Hellström >>>>> Sent: Friday, June 25, 2021 12:18 PM >>>>> To: Ruhl, Michael J ; intel- >>>>> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org >>>>> Cc: Auld, Matthew >>>>> Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf >>> map >>>>> time >>>>> >>>>> Hi, Michael, >>>>> >>>>> thanks for looking at this. >>>>> >>>>> On 6/25/21 6:02 PM, Ruhl, Michael J wrote: >>>>>>> -Original Message- >>>>>>> From: dri-devel On >Behalf >>> Of >>>>>>> Thomas Hellström >>>>>>> Sent: Thursday, June 24, 2021 2:31 PM >>>>>>> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org >>>>>>> Cc: Thomas Hellström ; Auld, >>>>> Matthew >>>>>>> >>>>>>> Subject: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf >map >>>>> time >>>>>>> Until we support p2p dma or as a complement to that, migrate data >>>>>>> to system memory at dma-buf map time if possible. >>>>>>> >>>>>>> Signed-off-by: Thomas Hellström > >>>>>>> --- >>>>>>> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 9 - >>>>>>> 1 file changed, 8 insertions(+), 1 deletion(-) >>>>>>> >>>>>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>>>>>> b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>>>>>> index 616c3a2f1baf..a52f885bc09a 100644 >>>>>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>>>>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>>>>>> @@ -25,7 +25,14 @@ static struct sg_table >>>>> *i915_gem_map_dma_buf(struct >>>>>>> dma_buf_attachment *attachme >>>>>>> struct scatterlist *src, *dst; >>>>>>> int ret, i; >>>>>>> >>>>>>> - ret = i915_gem_object_pin_pages_unlocked(obj); >>>>>>> + ret = i915_gem_object_lock_interruptible(obj, NULL); >>>>>> Hmm, I believe in most cases that the caller should be holding the >>>>>> lock (object dma-resv) on this object already. >>>>> Yes, I agree, In particular for other instances of our own driver, at >>>>> least since the dma_resv introduction. >>>>> >>>>> But I also think that's a pre-existing bug, since >>>>> i915_gem_object_pin_pages_unlocked() will also take the lock. >>>> Ouch yes. Missed that. >>>> >>>>> I Think we need to initially make the exporter dynamic-capable to >>>>> resolve this, and drop the locking here completely, as dma-buf docs says >>>>> that we're then guaranteed to get called with the object lock held. >>>>> >>>>> I figure if we make the exporter dynamic, we need to migrate already at >>>>> dma_buf_pin time so we don't pin the object in the wrong location. >>>> The exporter as dynamic (ops->pin is available) is optional, but importer >>>> dynamic (ops->move_notify) is required. >>>> >>>> With that in mind, it would seem that there are three possible >combinations >>>> for the migrate to be attempted: >>>> >>>> 1) in the ops->pin function (export_dynamic != import_dynamic, during >>> attach) >>>> 2) in the ops->pin function (export_dynamic
Re: [Intel-gfx] [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map time
>-Original Message- >From: Thomas Hellström >Sent: Friday, June 25, 2021 1:52 PM >To: Ruhl, Michael J ; intel- >g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org >Cc: Auld, Matthew >Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map >time > > >On 6/25/21 7:38 PM, Ruhl, Michael J wrote: >>> -Original Message- >>> From: Thomas Hellström >>> Sent: Friday, June 25, 2021 12:18 PM >>> To: Ruhl, Michael J ; intel- >>> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org >>> Cc: Auld, Matthew >>> Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf >map >>> time >>> >>> Hi, Michael, >>> >>> thanks for looking at this. >>> >>> On 6/25/21 6:02 PM, Ruhl, Michael J wrote: >>>>> -Original Message- >>>>> From: dri-devel On Behalf >Of >>>>> Thomas Hellström >>>>> Sent: Thursday, June 24, 2021 2:31 PM >>>>> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org >>>>> Cc: Thomas Hellström ; Auld, >>> Matthew >>>>> >>>>> Subject: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map >>> time >>>>> Until we support p2p dma or as a complement to that, migrate data >>>>> to system memory at dma-buf map time if possible. >>>>> >>>>> Signed-off-by: Thomas Hellström >>>>> --- >>>>> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 9 - >>>>> 1 file changed, 8 insertions(+), 1 deletion(-) >>>>> >>>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>>>> b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>>>> index 616c3a2f1baf..a52f885bc09a 100644 >>>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>>>> @@ -25,7 +25,14 @@ static struct sg_table >>> *i915_gem_map_dma_buf(struct >>>>> dma_buf_attachment *attachme >>>>> struct scatterlist *src, *dst; >>>>> int ret, i; >>>>> >>>>> - ret = i915_gem_object_pin_pages_unlocked(obj); >>>>> + ret = i915_gem_object_lock_interruptible(obj, NULL); >>>> Hmm, I believe in most cases that the caller should be holding the >>>> lock (object dma-resv) on this object already. >>> Yes, I agree, In particular for other instances of our own driver, at >>> least since the dma_resv introduction. >>> >>> But I also think that's a pre-existing bug, since >>> i915_gem_object_pin_pages_unlocked() will also take the lock. >> Ouch yes. Missed that. >> >>> I Think we need to initially make the exporter dynamic-capable to >>> resolve this, and drop the locking here completely, as dma-buf docs says >>> that we're then guaranteed to get called with the object lock held. >>> >>> I figure if we make the exporter dynamic, we need to migrate already at >>> dma_buf_pin time so we don't pin the object in the wrong location. >> The exporter as dynamic (ops->pin is available) is optional, but importer >> dynamic (ops->move_notify) is required. >> >> With that in mind, it would seem that there are three possible combinations >> for the migrate to be attempted: >> >> 1) in the ops->pin function (export_dynamic != import_dynamic, during >attach) >> 2) in the ops->pin function (export_dynamic and >!CONFIG_DMABUF_MOVE_NOTIFY) during mapping >> 3) and possibly in ops->map_dma_buf (exort_dynamic iand >CONFIG_DMABUF_MOVE_NOTIFY) >> >> Since one possibility has to be in the mapping function, it seems that if we >> can figure out the locking, that the migrate should probably be available >here. >> >> Mike > >So perhaps just to initially fix the bug, we could just implement NOP >pin() and unpin() callbacks and drop the locking in map_attach() and >replace it with an assert_object_held(); That is the sticky part of the move notify API. If you do the attach_dynamic you have to have an ops with move_notify. (https://elixir.bootlin.com/linux/v5.13-rc7/source/drivers/dma-buf/dma-buf.c#L730) If you don't have that, i.e. just the pin interface, the attach will be rejected, and you will not get the callbacks. So I think that the only thing we can do for now is to dop the locking and add the assert_object_held(); M >/Thomas > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map time
>-Original Message- >From: Thomas Hellström >Sent: Friday, June 25, 2021 12:18 PM >To: Ruhl, Michael J ; intel- >g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org >Cc: Auld, Matthew >Subject: Re: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map >time > >Hi, Michael, > >thanks for looking at this. > >On 6/25/21 6:02 PM, Ruhl, Michael J wrote: >>> -Original Message- >>> From: dri-devel On Behalf Of >>> Thomas Hellström >>> Sent: Thursday, June 24, 2021 2:31 PM >>> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org >>> Cc: Thomas Hellström ; Auld, >Matthew >>> >>> Subject: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map >time >>> >>> Until we support p2p dma or as a complement to that, migrate data >>> to system memory at dma-buf map time if possible. >>> >>> Signed-off-by: Thomas Hellström >>> --- >>> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 9 - >>> 1 file changed, 8 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>> b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>> index 616c3a2f1baf..a52f885bc09a 100644 >>> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >>> @@ -25,7 +25,14 @@ static struct sg_table >*i915_gem_map_dma_buf(struct >>> dma_buf_attachment *attachme >>> struct scatterlist *src, *dst; >>> int ret, i; >>> >>> - ret = i915_gem_object_pin_pages_unlocked(obj); >>> + ret = i915_gem_object_lock_interruptible(obj, NULL); >> Hmm, I believe in most cases that the caller should be holding the >> lock (object dma-resv) on this object already. > >Yes, I agree, In particular for other instances of our own driver, at >least since the dma_resv introduction. > >But I also think that's a pre-existing bug, since >i915_gem_object_pin_pages_unlocked() will also take the lock. Ouch yes. Missed that. >I Think we need to initially make the exporter dynamic-capable to >resolve this, and drop the locking here completely, as dma-buf docs says >that we're then guaranteed to get called with the object lock held. > >I figure if we make the exporter dynamic, we need to migrate already at >dma_buf_pin time so we don't pin the object in the wrong location. The exporter as dynamic (ops->pin is available) is optional, but importer dynamic (ops->move_notify) is required. With that in mind, it would seem that there are three possible combinations for the migrate to be attempted: 1) in the ops->pin function (export_dynamic != import_dynamic, during attach) 2) in the ops->pin function (export_dynamic and !CONFIG_DMABUF_MOVE_NOTIFY) during mapping 3) and possibly in ops->map_dma_buf (exort_dynamic iand CONFIG_DMABUF_MOVE_NOTIFY) Since one possibility has to be in the mapping function, it seems that if we can figure out the locking, that the migrate should probably be available here. Mike >/Thomas > > >> >> I know for the dynamic version of dma-buf, there is a check to make >> sure that the lock is held when called. >> >> I think you will run into some issues if you try to get it here as well. >> >> Mike >> >>> + if (ret) >>> + return ERR_PTR(ret); >>> + >>> + ret = i915_gem_object_migrate(obj, NULL, INTEL_REGION_SMEM); >>> + if (!ret) >>> + ret = i915_gem_object_pin_pages(obj); >>> + i915_gem_object_unlock(obj); >>> if (ret) >>> goto err; >>> >>> -- >>> 2.31.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map time
>-Original Message- >From: dri-devel On Behalf Of >Thomas Hellström >Sent: Thursday, June 24, 2021 2:31 PM >To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org >Cc: Thomas Hellström ; Auld, Matthew > >Subject: [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map time > >Until we support p2p dma or as a complement to that, migrate data >to system memory at dma-buf map time if possible. > >Signed-off-by: Thomas Hellström >--- > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > >diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >index 616c3a2f1baf..a52f885bc09a 100644 >--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >@@ -25,7 +25,14 @@ static struct sg_table *i915_gem_map_dma_buf(struct >dma_buf_attachment *attachme > struct scatterlist *src, *dst; > int ret, i; > >- ret = i915_gem_object_pin_pages_unlocked(obj); >+ ret = i915_gem_object_lock_interruptible(obj, NULL); Hmm, I believe in most cases that the caller should be holding the lock (object dma-resv) on this object already. I know for the dynamic version of dma-buf, there is a check to make sure that the lock is held when called. I think you will run into some issues if you try to get it here as well. Mike >+ if (ret) >+ return ERR_PTR(ret); >+ >+ ret = i915_gem_object_migrate(obj, NULL, INTEL_REGION_SMEM); >+ if (!ret) >+ ret = i915_gem_object_pin_pages(obj); >+ i915_gem_object_unlock(obj); > if (ret) > goto err; > >-- >2.31.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 1/5] drm/ast: Remove reference to struct drm_device.pdev
>-Original Message-
>From: dri-devel On Behalf Of
>Thomas Zimmermann
>Sent: Thursday, April 29, 2021 6:51 AM
>To: jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com; Vivi, Rodrigo
>; airl...@linux.ie; dan...@ffwll.ch; chris@chris-
>wilson.co.uk
>Cc: lkp ; intel-gfx@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org; Thomas Zimmermann
>; Dave Airlie
>Subject: [PATCH v8 1/5] drm/ast: Remove reference to struct
>drm_device.pdev
>
>Using struct drm_device.pdev is deprecated. Upcast with to_pci_dev()
>from struct drm_device.dev to get the PCI device structure.
Reviewed-by: Michael J. Ruhl
m
>Signed-off-by: Thomas Zimmermann
>Fixes: ba4e0339a6a3 ("drm/ast: Fixed CVE for DP501")
>Cc: KuoHsiang Chou
>Cc: kernel test robot
>Cc: Thomas Zimmermann
>Cc: Dave Airlie
>Cc: dri-de...@lists.freedesktop.org
>---
> drivers/gpu/drm/ast/ast_main.c | 1 -
> 1 file changed, 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/ast/ast_main.c
>b/drivers/gpu/drm/ast/ast_main.c
>index 189d783f6e2c..6b49a92dc75f 100644
>--- a/drivers/gpu/drm/ast/ast_main.c
>+++ b/drivers/gpu/drm/ast/ast_main.c
>@@ -411,7 +411,6 @@ struct ast_private *ast_device_create(const struct
>drm_driver *drv,
> return ast;
> dev = >base;
>
>- dev->pdev = pdev;
> pci_set_drvdata(pdev, dev);
>
> ast->regs = pcim_iomap(pdev, 1, 0);
>--
>2.31.1
>
>___
>dri-devel mailing list
>dri-de...@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 3/5] drm/i915: Remove reference to struct drm_device.pdev
>-Original Message-
>From: dri-devel On Behalf Of
>Thomas Zimmermann
>Sent: Thursday, April 29, 2021 6:51 AM
>To: jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com; Vivi, Rodrigo
>; airl...@linux.ie; dan...@ffwll.ch; chris@chris-
>wilson.co.uk
>Cc: intel-gfx@lists.freedesktop.org; Thomas Zimmermann
>; dri-de...@lists.freedesktop.org
>Subject: [PATCH v8 3/5] drm/i915: Remove reference to struct
>drm_device.pdev
>
>References to struct drm_device.pdev should not be used any longer as
>the field will be moved into the struct's legacy section. Fix a rsp
>comment.
>
>v8:
> * fix commit message (Michael)
Reviewed-by: Michael J. Ruhl
m
>Signed-off-by: Thomas Zimmermann
>---
> drivers/gpu/drm/i915/intel_runtime_pm.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.h
>b/drivers/gpu/drm/i915/intel_runtime_pm.h
>index 1e4ddd11c12b..183ea2b187fe 100644
>--- a/drivers/gpu/drm/i915/intel_runtime_pm.h
>+++ b/drivers/gpu/drm/i915/intel_runtime_pm.h
>@@ -49,7 +49,7 @@ enum i915_drm_suspend_mode {
> */
> struct intel_runtime_pm {
> atomic_t wakeref_count;
>- struct device *kdev; /* points to i915->drm.pdev->dev */
>+ struct device *kdev; /* points to i915->drm.dev */
> bool available;
> bool suspended;
> bool irqs_enabled;
>--
>2.31.1
>
>___
>dri-devel mailing list
>dri-de...@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 2/5] drm/i915/gt: Remove reference to struct drm_device.pdev
>-Original Message-
>From: Intel-gfx On Behalf Of
>Thomas Zimmermann
>Sent: Thursday, April 29, 2021 6:51 AM
>To: jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com; Vivi, Rodrigo
>; airl...@linux.ie; dan...@ffwll.ch; chris@chris-
>wilson.co.uk
>Cc: Winiarski, Michal ; Nikula, Jani
>; Daniel Vetter ; intel-
>g...@lists.freedesktop.org; De Marchi, Lucas ; dri-
>de...@lists.freedesktop.org; Auld, Matthew ;
>Thomas Zimmermann
>Subject: [Intel-gfx] [PATCH v8 2/5] drm/i915/gt: Remove reference to struct
>drm_device.pdev
>
>References to struct drm_device.pdev should not be used any longer as
>the field will be moved into the struct's legacy section. Add a fix
>for the rsp commit.
>
>v8:
> * fix commit message (Michael)
Reviewed-by: Michael J. Ruhl
m
>Signed-off-by: Thomas Zimmermann
>Fixes: a50ca39fbd01 ("drm/i915: setup the LMEM region")
>Cc: Lucas De Marchi
>Cc: Joonas Lahtinen
>Cc: Rodrigo Vivi
>Cc: Matthew Auld
>Cc: Jani Nikula
>Cc: Chris Wilson
>Cc: Daniel Vetter
>Cc: Tvrtko Ursulin
>Cc: Daniele Ceraolo Spurio
>Cc: Mika Kuoppala
>Cc: Maarten Lankhorst
>Cc: Venkata Sandeep Dhanalakota
>Cc: "Michał Winiarski"
>---
> drivers/gpu/drm/i915/gt/intel_region_lmem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
>b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
>index be6f2c8f5184..73fceb0c25fc 100644
>--- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
>+++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
>@@ -177,7 +177,7 @@ static struct intel_memory_region
>*setup_lmem(struct intel_gt *gt)
> {
> struct drm_i915_private *i915 = gt->i915;
> struct intel_uncore *uncore = gt->uncore;
>- struct pci_dev *pdev = i915->drm.pdev;
>+ struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> struct intel_memory_region *mem;
> resource_size_t io_start;
> resource_size_t lmem_size;
>--
>2.31.1
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/gem: Remove reference to struct drm_device.pdev
>-Original Message-
>From: Thomas Zimmermann
>Sent: Tuesday, April 27, 2021 1:49 PM
>To: jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com; Vivi, Rodrigo
>; airl...@linux.ie; dan...@ffwll.ch; Auld, Matthew
>; Ruhl, Michael J
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Thomas
>Zimmermann ; Nikula, Jani
>; Tang, CQ ; Tvrtko Ursulin
>; Liu, Xinyun ; Ursulin,
>Tvrtko ; Chris Wilson ;
>Mika Kuoppala ; Daniel Vetter
>; Maarten Lankhorst
>; Hellstrom, Thomas
>; Gustavo A. R. Silva
>; Dan Carpenter
>Subject: [PATCH v2] drm/i915/gem: Remove reference to struct
>drm_device.pdev
>
>References to struct drm_device.pdev should not be used any longer as
>the field will be moved into the struct's legacy section. Add a fix
>for the rsp commit.
Commit message match the patch.
Reviewed-by: Michael J. Ruhl v2:
> * fix an error in the commit description (Michael)
>
>Signed-off-by: Thomas Zimmermann
>Reviewed-by: Jani Nikula
>Fixes: d57d4a1daf5e ("drm/i915: Create stolen memory region from local
>memory")
>Cc: CQ Tang
>Cc: Matthew Auld
>Cc: Tvrtko Ursulin
>Cc: Xinyun Liu
>Cc: Tvrtko Ursulin
>Cc: Jani Nikula
>Cc: Joonas Lahtinen
>Cc: Rodrigo Vivi
>Cc: Chris Wilson
>Cc: Mika Kuoppala
>Cc: Daniel Vetter
>Cc: Maarten Lankhorst
>Cc: "Thomas Hellström"
>Cc: "Gustavo A. R. Silva"
>Cc: Dan Carpenter
>Cc: intel-gfx@lists.freedesktop.org
>---
> drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
>b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
>index c5b64b2400e8..e1a32672bbe8 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
>@@ -773,7 +773,7 @@ struct intel_memory_region *
> i915_gem_stolen_lmem_setup(struct drm_i915_private *i915)
> {
> struct intel_uncore *uncore = >uncore;
>- struct pci_dev *pdev = i915->drm.pdev;
>+ struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> struct intel_memory_region *mem;
> resource_size_t io_start;
> resource_size_t lmem_size;
>--
>2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gem: Remove reference to struct drm_device.pdev
>-Original Message-
>From: dri-devel On Behalf Of
>Thomas Zimmermann
>Sent: Tuesday, April 27, 2021 7:08 AM
>To: jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com; Vivi, Rodrigo
>; airl...@linux.ie; dan...@ffwll.ch; Auld, Matthew
>
>Cc: Tvrtko Ursulin ; Ursulin, Tvrtko
>; Mika Kuoppala
>; intel-gfx@lists.freedesktop.org; Gustavo
>A. R. Silva ; dri-de...@lists.freedesktop.org; Chris
>Wilson ; Tang, CQ ; Hellstrom,
>Thomas ; Thomas Zimmermann
>; Daniel Vetter ; Liu,
>Xinyun ; Dan Carpenter
>Subject: [PATCH] drm/i915/gem: Remove reference to struct
>drm_device.pdev
>
>References to struct drm_device.pdev should be used any longer as
should not be used
^^^
?
m
>the field will be moved into the struct's legacy section. Add a fix
>for the rsp commit.
>
>Signed-off-by: Thomas Zimmermann
>Fixes: d57d4a1daf5e ("drm/i915: Create stolen memory region from local
>memory")
>Cc: CQ Tang
>Cc: Matthew Auld
>Cc: Tvrtko Ursulin
>Cc: Xinyun Liu
>Cc: Tvrtko Ursulin
>Cc: Jani Nikula
>Cc: Joonas Lahtinen
>Cc: Rodrigo Vivi
>Cc: Chris Wilson
>Cc: Mika Kuoppala
>Cc: Daniel Vetter
>Cc: Maarten Lankhorst
>Cc: "Thomas Hellström"
>Cc: "Gustavo A. R. Silva"
>Cc: Dan Carpenter
>Cc: intel-gfx@lists.freedesktop.org
>---
> drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
>b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
>index c5b64b2400e8..e1a32672bbe8 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
>@@ -773,7 +773,7 @@ struct intel_memory_region *
> i915_gem_stolen_lmem_setup(struct drm_i915_private *i915)
> {
> struct intel_uncore *uncore = >uncore;
>- struct pci_dev *pdev = i915->drm.pdev;
>+ struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> struct intel_memory_region *mem;
> resource_size_t io_start;
> resource_size_t lmem_size;
>--
>2.31.1
>
>___
>dri-devel mailing list
>dri-de...@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gem: Allow importing of shmemfs objects into any device
>-Original Message- >From: Intel-gfx On Behalf Of >Matthew Auld >Sent: Wednesday, January 20, 2021 12:46 PM >To: Chris Wilson >Cc: Intel Graphics Development ; Auld, >Matthew >Subject: Re: [Intel-gfx] [PATCH] drm/i915/gem: Allow importing of shmemfs >objects into any device > >On Wed, 20 Jan 2021 at 15:40, Chris Wilson wrote: >> >> If we import a shmemfs object between devices, for example from >> Tigerlake to DG1, we can simply reuse the native object and its backing >> store. > >Hmmm interesting, so does that include re-using the actual sg mapping >for the backing pages? Does that work out-of-the-box between different >devices assuming we have iommu enabled? > >> >> Suggested-by: Imre Deak >> Signed-off-by: Chris Wilson >> Cc: Matthew Auld >> Cc: Imre Deak >> --- >> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 7 +++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >> index 04e9c04545ad..4816f08c4009 100644 >> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c >> @@ -242,6 +242,13 @@ struct drm_gem_object >*i915_gem_prime_import(struct drm_device *dev, >> */ >> return _gem_object_get(obj)->base; >> } >> + >> + /* >> +* If the object is in plain system memory, we can reuse the >> +* same backing store in any device. >> +*/ >> + if (i915_gem_object_is_shmem(obj)) >> + return _gem_object_get(obj)->base; >> } So this would mean sharing all of the object attributes between devices (pin count, etc)? I.e. vma list etc? Would that work? Mike >> /* need to attach */ >> -- >> 2.20.1 >> >> ___ >> Intel-gfx mailing list >> Intel-gfx@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx >___ >Intel-gfx mailing list >Intel-gfx@lists.freedesktop.org >https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [CI 2/2] drm/i915/gem: Pull phys pread/pwrite implementations to the backend
>-Original Message-
>From: Intel-gfx On Behalf Of Chris
>Wilson
>Sent: Thursday, November 5, 2020 10:50 AM
>To: intel-gfx@lists.freedesktop.org
>Subject: [Intel-gfx] [CI 2/2] drm/i915/gem: Pull phys pread/pwrite
>implementations to the backend
>
>Move the specialised interactions with the physical GEM object from the
>pread/pwrite ioctl handler into the phys backend.
>
>Signed-off-by: Chris Wilson
>Reviewed-by: Matthew Auld
>---
> drivers/gpu/drm/i915/gem/i915_gem_phys.c | 55
>
> drivers/gpu/drm/i915/i915_gem.c | 26 ---
> 2 files changed, 55 insertions(+), 26 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_phys.c
>b/drivers/gpu/drm/i915/gem/i915_gem_phys.c
>index 28147aab47b9..3a4dfe2ef1da 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_phys.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_phys.c
>@@ -134,6 +134,58 @@ i915_gem_object_put_pages_phys(struct
>drm_i915_gem_object *obj,
> vaddr, dma);
> }
>
>+static int
>+phys_pwrite(struct drm_i915_gem_object *obj,
>+ const struct drm_i915_gem_pwrite *args)
>+{
>+ void *vaddr = sg_page(obj->mm.pages->sgl) + args->offset;
>+ char __user *user_data = u64_to_user_ptr(args->data_ptr);
>+ int err;
>+
>+ err = i915_gem_object_wait(obj,
>+ I915_WAIT_INTERRUPTIBLE |
>+ I915_WAIT_ALL,
>+ MAX_SCHEDULE_TIMEOUT);
>+ if (err)
>+ return err;
>+
>+ /*
>+ * We manually control the domain here and pretend that it
>+ * remains coherent i.e. in the GTT domain, like shmem_pwrite.
>+ */
>+ i915_gem_object_invalidate_frontbuffer(obj, ORIGIN_CPU);
>+
>+ if (copy_from_user(vaddr, user_data, args->size))
>+ return -EFAULT;
>+
>+ drm_clflush_virt_range(vaddr, args->size);
>+ intel_gt_chipset_flush(_i915(obj->base.dev)->gt);
>+
>+ i915_gem_object_flush_frontbuffer(obj, ORIGIN_CPU);
>+ return 0;
So the original code path (through pwrite_ioctl()) includes a pin/unpin.
That doesn't need to be done here?
Thanks,
Mike
>+}
>+
>+static int
>+phys_pread(struct drm_i915_gem_object *obj,
>+ const struct drm_i915_gem_pread *args)
>+{
>+ void *vaddr = sg_page(obj->mm.pages->sgl) + args->offset;
>+ char __user *user_data = u64_to_user_ptr(args->data_ptr);
>+ int err;
>+
>+ err = i915_gem_object_wait(obj,
>+ I915_WAIT_INTERRUPTIBLE,
>+ MAX_SCHEDULE_TIMEOUT);
>+ if (err)
>+ return err;
>+
>+ drm_clflush_virt_range(vaddr, args->size);
>+ if (copy_to_user(user_data, vaddr, args->size))
>+ return -EFAULT;
>+
>+ return 0;
>+}
>+
> static void phys_release(struct drm_i915_gem_object *obj)
> {
> fput(obj->base.filp);
>@@ -144,6 +196,9 @@ static const struct drm_i915_gem_object_ops
>i915_gem_phys_ops = {
> .get_pages = i915_gem_object_get_pages_phys,
> .put_pages = i915_gem_object_put_pages_phys,
>
>+ .pread = phys_pread,
>+ .pwrite = phys_pwrite,
>+
> .release = phys_release,
> };
>
>diff --git a/drivers/gpu/drm/i915/i915_gem.c
>b/drivers/gpu/drm/i915/i915_gem.c
>index d58fe1ddc3e1..58276694c848 100644
>--- a/drivers/gpu/drm/i915/i915_gem.c
>+++ b/drivers/gpu/drm/i915/i915_gem.c
>@@ -179,30 +179,6 @@ int i915_gem_object_unbind(struct
>drm_i915_gem_object *obj,
> return ret;
> }
>
>-static int
>-i915_gem_phys_pwrite(struct drm_i915_gem_object *obj,
>- struct drm_i915_gem_pwrite *args,
>- struct drm_file *file)
>-{
>- void *vaddr = sg_page(obj->mm.pages->sgl) + args->offset;
>- char __user *user_data = u64_to_user_ptr(args->data_ptr);
>-
>- /*
>- * We manually control the domain here and pretend that it
>- * remains coherent i.e. in the GTT domain, like shmem_pwrite.
>- */
>- i915_gem_object_invalidate_frontbuffer(obj, ORIGIN_CPU);
>-
>- if (copy_from_user(vaddr, user_data, args->size))
>- return -EFAULT;
>-
>- drm_clflush_virt_range(vaddr, args->size);
>- intel_gt_chipset_flush(_i915(obj->base.dev)->gt);
>-
>- i915_gem_object_flush_frontbuffer(obj, ORIGIN_CPU);
>- return 0;
>-}
>-
> static int
> i915_gem_create(struct drm_file *file,
> struct intel_memory_region *mr,
>@@ -872,8 +848,6 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void
>*data,
> if (ret == -EFAULT || ret == -ENOSPC) {
> if (i915_gem_object_has_struct_page(obj))
> ret = i915_gem_shmem_pwrite(obj, args);
>- else
>- ret = i915_gem_phys_pwrite(obj, args, file);
> }
>
> i915_gem_object_unpin_pages(obj);
>--
>2.20.1
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
Re: [Intel-gfx] [PATCH 10/61] drm/i915: Disable userptr pread/pwrite support.
>-Original Message-
>From: Maarten Lankhorst
>Sent: Monday, October 12, 2020 10:14 AM
>To: Ruhl, Michael J ; intel-
>g...@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [PATCH 10/61] drm/i915: Disable userptr pread/pwrite
>support.
>
>Op 02-10-2020 om 22:14 schreef Ruhl, Michael J:
>>> -Original Message-
>>> From: Intel-gfx On Behalf Of
>>> Maarten Lankhorst
>>> Sent: Friday, October 2, 2020 8:59 AM
>>> To: intel-gfx@lists.freedesktop.org
>>> Subject: [Intel-gfx] [PATCH 10/61] drm/i915: Disable userptr pread/pwrite
>>> support.
>>>
>>> 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 | 5 +
>>> 3 files changed, 27 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
>>> b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
>>> index 62dde3585b51..dbb6f6171165 100644
>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
>>> @@ -57,6 +57,8 @@ struct drm_i915_gem_object_ops {
>>>
>>> int (*pwrite)(struct drm_i915_gem_object *obj,
>>> const struct drm_i915_gem_pwrite *arg);
>>> + int (*pread)(struct drm_i915_gem_object *obj,
>>> +const struct drm_i915_gem_pread *arg);
>>>
>>> int (*dmabuf_export)(struct drm_i915_gem_object *obj);
>>> void (*release)(struct drm_i915_gem_object *obj);
>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
>>> b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
>>> index 22008948be58..136a589e5d94 100644
>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
>>> @@ -700,6 +700,24 @@ i915_gem_userptr_dmabuf_export(struct
>>> drm_i915_gem_object *obj)
>>> return i915_gem_userptr_init__mmu_notifier(obj, 0);
>>> }
>>>
>>> +static int
>>> +i915_gem_userptr_pwrite(struct drm_i915_gem_object *obj,
>>> + const struct drm_i915_gem_pwrite *args)
>>> +{
>>> + drm_dbg(obj->base.dev, "pwrite to userptr no longer allowed\n");
>>> +
>>> + return -EINVAL;
>> I have seen ENOSYS used for unsupported pread/pwrite (see
>radeon_gem.c).
>>
>> I have also seen ENOTSUPP for similar return values.
>>
>> Is EINVAL the correct response?
>
>It seems for some other things we use -ENXIO, I don't think it matters in the
>end.
>
>As long as we fail in some recognisable way, I'm fine with it. :)
>
>I chose -EINVAL as we return the same error with r/o objects.
Hi Maarten,
Sorry this got lost in the noise last week.
If my comments are still relevant...
Ok, I understand your reasoning here, but I do see differences.
EINVAL for r/o means I made bad request. ENOTSUPP means that the feature
I want to use is not available. Not terribly different, but slightly more
"correct".
I don't see how ENXIO fits other than as a "more unique" error.
I do think that EINVAL is over used, making it difficult to find out why the
error
was returned, but I can see its use in this case, so I am not opposed.
Sorry for the lateness of my reply,
Mike
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/61] drm/i915: Disable userptr pread/pwrite support.
>-Original Message-
>From: Intel-gfx On Behalf Of
>Maarten Lankhorst
>Sent: Friday, October 2, 2020 8:59 AM
>To: intel-gfx@lists.freedesktop.org
>Subject: [Intel-gfx] [PATCH 10/61] drm/i915: Disable userptr pread/pwrite
>support.
>
>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 | 5 +
> 3 files changed, 27 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
>b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
>index 62dde3585b51..dbb6f6171165 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
>@@ -57,6 +57,8 @@ struct drm_i915_gem_object_ops {
>
> int (*pwrite)(struct drm_i915_gem_object *obj,
> const struct drm_i915_gem_pwrite *arg);
>+ int (*pread)(struct drm_i915_gem_object *obj,
>+ const struct drm_i915_gem_pread *arg);
>
> int (*dmabuf_export)(struct drm_i915_gem_object *obj);
> void (*release)(struct drm_i915_gem_object *obj);
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
>b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
>index 22008948be58..136a589e5d94 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
>@@ -700,6 +700,24 @@ i915_gem_userptr_dmabuf_export(struct
>drm_i915_gem_object *obj)
> return i915_gem_userptr_init__mmu_notifier(obj, 0);
> }
>
>+static int
>+i915_gem_userptr_pwrite(struct drm_i915_gem_object *obj,
>+ const struct drm_i915_gem_pwrite *args)
>+{
>+ drm_dbg(obj->base.dev, "pwrite to userptr no longer allowed\n");
>+
>+ return -EINVAL;
I have seen ENOSYS used for unsupported pread/pwrite (see radeon_gem.c).
I have also seen ENOTSUPP for similar return values.
Is EINVAL the correct response?
Thanks,
m
>+}
>+
>+static int
>+i915_gem_userptr_pread(struct drm_i915_gem_object *obj,
>+ const struct drm_i915_gem_pread *args)
>+{
>+ drm_dbg(obj->base.dev, "pread from userptr no longer allowed\n");
>+
>+ return -EINVAL;
>+}
>+
> static const struct drm_i915_gem_object_ops i915_gem_userptr_ops = {
> .name = "i915_gem_object_userptr",
> .flags = I915_GEM_OBJECT_IS_SHRINKABLE |
>@@ -708,6 +726,8 @@ static const struct drm_i915_gem_object_ops
>i915_gem_userptr_ops = {
> .get_pages = i915_gem_userptr_get_pages,
> .put_pages = i915_gem_userptr_put_pages,
> .dmabuf_export = i915_gem_userptr_dmabuf_export,
>+ .pwrite = i915_gem_userptr_pwrite,
>+ .pread = i915_gem_userptr_pread,
> .release = i915_gem_userptr_release,
> };
>
>diff --git a/drivers/gpu/drm/i915/i915_gem.c
>b/drivers/gpu/drm/i915/i915_gem.c
>index 30af7e4b71ab..d349c0b796ec 100644
>--- a/drivers/gpu/drm/i915/i915_gem.c
>+++ b/drivers/gpu/drm/i915/i915_gem.c
>@@ -526,6 +526,11 @@ i915_gem_pread_ioctl(struct drm_device *dev, void
>*data,
> }
>
> trace_i915_gem_object_pread(obj, args->offset, args->size);
>+ ret = -ENODEV;
>+ if (obj->ops->pread)
>+ ret = obj->ops->pread(obj, args);
>+ if (ret != -ENODEV)
>+ goto out;
>
> ret = i915_gem_object_wait(obj,
> I915_WAIT_INTERRUPTIBLE,
>--
>2.28.0
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 08/32] drm: i915: fix common struct sg_table related issues
>-Original Message-
>From: Robin Murphy
>Sent: Tuesday, September 1, 2020 3:54 PM
>To: Ruhl, Michael J ; Marek Szyprowski
>; dri-de...@lists.freedesktop.org;
>io...@lists.linux-foundation.org; linaro-mm-...@lists.linaro.org; linux-
>ker...@vger.kernel.org
>Cc: Bartlomiej Zolnierkiewicz ; David Airlie
>; intel-gfx@lists.freedesktop.org; Christoph Hellwig
>; linux-arm-ker...@lists.infradead.org
>Subject: Re: [Intel-gfx] [PATCH v9 08/32] drm: i915: fix common struct
>sg_table related issues
>
>On 2020-09-01 20:38, Ruhl, Michael J wrote:
>>> -Original Message-
>>> From: Intel-gfx On Behalf Of
>>> Marek Szyprowski
>>> Sent: Wednesday, August 26, 2020 2:33 AM
>>> To: dri-de...@lists.freedesktop.org; io...@lists.linux-foundation.org;
>>> linaro-mm-...@lists.linaro.org; linux-ker...@vger.kernel.org
>>> Cc: Bartlomiej Zolnierkiewicz ; David Airlie
>>> ; intel-gfx@lists.freedesktop.org; Robin Murphy
>>> ; Christoph Hellwig ; linux-arm-
>>> ker...@lists.infradead.org; Marek Szyprowski
>>>
>>> Subject: [Intel-gfx] [PATCH v9 08/32] drm: i915: fix common struct sg_table
>>> related issues
>>>
>>> The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg()
>>> function
>>> returns the number of the created entries in the DMA address space.
>>> However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
>>> dma_unmap_sg must be called with the original number of the entries
>>> passed to the dma_map_sg().
>>>
>>> struct sg_table is a common structure used for describing a non-contiguous
>>> memory buffer, used commonly in the DRM and graphics subsystems. It
>>> consists of a scatterlist with memory pages and DMA addresses (sgl entry),
>>> as well as the number of scatterlist entries: CPU pages (orig_nents entry)
>>> and DMA mapped pages (nents entry).
>>>
>>> It turned out that it was a common mistake to misuse nents and orig_nents
>>> entries, calling DMA-mapping functions with a wrong number of entries or
>>> ignoring the number of mapped entries returned by the dma_map_sg()
>>> function.
>>>
>>> This driver creatively uses sg_table->orig_nents to store the size of the
>>> allocated scatterlist and ignores the number of the entries returned by
>>> dma_map_sg function. The sg_table->orig_nents is (mis)used to properly
>>> free the (over)allocated scatterlist.
>>>
>>> This patch only introduces the common DMA-mapping wrappers operating
>>> directly on the struct sg_table objects to the dmabuf related functions,
>>> so the other drivers, which might share buffers with i915 could rely on
>>> the properly set nents and orig_nents values.
>>>
>>> Signed-off-by: Marek Szyprowski
>>> ---
>>> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 11 +++
>>> drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c | 7 +++
>>> 2 files changed, 6 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>>> b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>>> index 2679380159fc..8a988592715b 100644
>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>>> @@ -48,12 +48,9 @@ static struct sg_table
>*i915_gem_map_dma_buf(struct
>>> dma_buf_attachment *attachme
>>> src = sg_next(src);
>>> }
>>>
>>> - if (!dma_map_sg_attrs(attachment->dev,
>>> - st->sgl, st->nents, dir,
>>> - DMA_ATTR_SKIP_CPU_SYNC)) {
>>> - ret = -ENOMEM;
>>
>> You have dropped this error value.
>>
>> Do you now if this is a benign loss?
>
>True, dma_map_sgtable() will return -EINVAL rather than -ENOMEM for
>failure. A quick look through other .map_dma_buf callbacks suggests
>they're returning a motley mix of error values and NULL for failure
>cases, so I'd imagine that importers shouldn't be too sensitive to the
>exact value.
I followed some of our code through to see if anyone is checking for -ENOMEM...
I have found in some test paths... However, it is not clear to me if we can get
to those paths from here.
Anyways,
Reviewed-by: Michael J. Ruhl
Mike
>Robin.
>
>>
>> M
>>
>>> + ret = dma_map_sgtable(attachment->dev, st, dir,
>>> DMA_ATTR_SKIP_CPU_SYNC);
>>> + if (ret)
>>> goto err_free_sg;
>>> - }
>>>
>>>
Re: [Intel-gfx] [PATCH v9 08/32] drm: i915: fix common struct sg_table related issues
>-Original Message-
>From: Intel-gfx On Behalf Of
>Marek Szyprowski
>Sent: Wednesday, August 26, 2020 2:33 AM
>To: dri-de...@lists.freedesktop.org; io...@lists.linux-foundation.org;
>linaro-mm-...@lists.linaro.org; linux-ker...@vger.kernel.org
>Cc: Bartlomiej Zolnierkiewicz ; David Airlie
>; intel-gfx@lists.freedesktop.org; Robin Murphy
>; Christoph Hellwig ; linux-arm-
>ker...@lists.infradead.org; Marek Szyprowski
>
>Subject: [Intel-gfx] [PATCH v9 08/32] drm: i915: fix common struct sg_table
>related issues
>
>The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg()
>function
>returns the number of the created entries in the DMA address space.
>However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
>dma_unmap_sg must be called with the original number of the entries
>passed to the dma_map_sg().
>
>struct sg_table is a common structure used for describing a non-contiguous
>memory buffer, used commonly in the DRM and graphics subsystems. It
>consists of a scatterlist with memory pages and DMA addresses (sgl entry),
>as well as the number of scatterlist entries: CPU pages (orig_nents entry)
>and DMA mapped pages (nents entry).
>
>It turned out that it was a common mistake to misuse nents and orig_nents
>entries, calling DMA-mapping functions with a wrong number of entries or
>ignoring the number of mapped entries returned by the dma_map_sg()
>function.
>
>This driver creatively uses sg_table->orig_nents to store the size of the
>allocated scatterlist and ignores the number of the entries returned by
>dma_map_sg function. The sg_table->orig_nents is (mis)used to properly
>free the (over)allocated scatterlist.
>
>This patch only introduces the common DMA-mapping wrappers operating
>directly on the struct sg_table objects to the dmabuf related functions,
>so the other drivers, which might share buffers with i915 could rely on
>the properly set nents and orig_nents values.
>
>Signed-off-by: Marek Szyprowski
>---
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 11 +++
> drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c | 7 +++
> 2 files changed, 6 insertions(+), 12 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>index 2679380159fc..8a988592715b 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>@@ -48,12 +48,9 @@ static struct sg_table *i915_gem_map_dma_buf(struct
>dma_buf_attachment *attachme
> src = sg_next(src);
> }
>
>- if (!dma_map_sg_attrs(attachment->dev,
>-st->sgl, st->nents, dir,
>-DMA_ATTR_SKIP_CPU_SYNC)) {
>- ret = -ENOMEM;
You have dropped this error value.
Do you now if this is a benign loss?
M
>+ ret = dma_map_sgtable(attachment->dev, st, dir,
>DMA_ATTR_SKIP_CPU_SYNC);
>+ if (ret)
> goto err_free_sg;
>- }
>
> return st;
>
>@@ -73,9 +70,7 @@ static void i915_gem_unmap_dma_buf(struct
>dma_buf_attachment *attachment,
> {
> struct drm_i915_gem_object *obj = dma_buf_to_obj(attachment-
>>dmabuf);
>
>- dma_unmap_sg_attrs(attachment->dev,
>- sg->sgl, sg->nents, dir,
>- DMA_ATTR_SKIP_CPU_SYNC);
>+ dma_unmap_sgtable(attachment->dev, sg, dir,
>DMA_ATTR_SKIP_CPU_SYNC);
> sg_free_table(sg);
> kfree(sg);
>
>diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
>b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
>index debaf7b18ab5..be30b27e2926 100644
>--- a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
>+++ b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
>@@ -28,10 +28,9 @@ static struct sg_table *mock_map_dma_buf(struct
>dma_buf_attachment *attachment,
> sg = sg_next(sg);
> }
>
>- if (!dma_map_sg(attachment->dev, st->sgl, st->nents, dir)) {
>- err = -ENOMEM;
>+ err = dma_map_sgtable(attachment->dev, st, dir, 0);
>+ if (err)
> goto err_st;
>- }
>
> return st;
>
>@@ -46,7 +45,7 @@ static void mock_unmap_dma_buf(struct
>dma_buf_attachment *attachment,
> struct sg_table *st,
> enum dma_data_direction dir)
> {
>- dma_unmap_sg(attachment->dev, st->sgl, st->nents, dir);
>+ dma_unmap_sgtable(attachment->dev, st, dir, 0);
> sg_free_table(st);
> kfree(st);
> }
>--
>2.17.1
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: Be defensive in the face of false CS events
>-Original Message-
>From: Intel-gfx On Behalf Of Chris
>Wilson
>Sent: Friday, July 10, 2020 8:16 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Chris Wilson
>Subject: [Intel-gfx] [PATCH] drm/i915/gt: Be defensive in the face of false CS
>events
>
>If the HW throws a curve ball and reports either en event before it is
^^
s/en/an/
?
m
>possible, or just a completely impossible event, we have to grin and
>bear it. The first few events, we will likely not notice as we would be
>expecting some event, but as soon as we stop expecting an event and yet
>they still keep coming, then we enter into undefined state territory.
>In which case, bail out, stop processing the events, and reset the
>engine and our set of queued requests to recover.
>
>The sporadic hangs and warnings will continue to plague CI, but at least
>system stability should not be compromised.
>
>Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2045
>Signed-off-by: Chris Wilson
>Cc: Tvrtko Ursulin
>---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
>b/drivers/gpu/drm/i915/gt/intel_lrc.c
>index fbcfeaed6441..c86324d2d2bb 100644
>--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
>+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
>@@ -2567,6 +2567,7 @@ static void process_csb(struct intel_engine_cs
>*engine)
> tail = READ_ONCE(*execlists->csb_write);
> if (unlikely(head == tail))
> return;
>+ execlists->csb_head = tail;
>
> /*
>* Hopefully paired with a wmb() in HW!
>@@ -2613,6 +2614,9 @@ static void process_csb(struct intel_engine_cs
>*engine)
> if (promote) {
> struct i915_request * const *old = execlists->active;
>
>+ if (GEM_WARN_ON(!*execlists->pending))
>+ break;
>+
> ring_set_paused(engine, 0);
>
> /* Point active to the new ELSP; prevent overwriting
>*/
>@@ -2635,7 +2639,8 @@ static void process_csb(struct intel_engine_cs
>*engine)
>
> WRITE_ONCE(execlists->pending[0], NULL);
> } else {
>- GEM_BUG_ON(!*execlists->active);
>+ if (GEM_WARN_ON(!*execlists->active))
>+ break;
>
> /* port0 completed, advanced to port1 */
> trace_ports(execlists, "completed", execlists->active);
>@@ -2686,7 +2691,6 @@ static void process_csb(struct intel_engine_cs
>*engine)
> }
> } while (head != tail);
>
>- execlists->csb_head = head;
> set_timeslice(engine);
>
> /*
>--
>2.20.1
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] i915/gem_close_race: Mix in a contexts and a small delay to closure
>-Original Message-
>From: Chris Wilson
>Sent: Tuesday, June 30, 2020 5:25 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: igt-...@lists.freedesktop.org; Chris Wilson ;
>Ruhl, Michael J
>Subject: [PATCH i-g-t] i915/gem_close_race: Mix in a contexts and a small
>delay to closure
>
>Keep the old handles in a small ring so that we build up a small amount
>of pressure for i915_gem_close_object() and throw in a few concurrent
>contexts so we have to process an obj->lut_list containing more than one
>element. And to make sure the list is truly long enough to schedule,
>start leaking the contexts.
>
>Note that the only correctness check is that the selfcopy doesn't
>explode; the challenge would be to prove that the old handles are no
>longer accessible via the execbuf lut. However, this is sufficient to
>make sure we at least hit the interruptible spinlock used by
>close-objects.
>
>Signed-off-by: Chris Wilson
>Cc: Michael J. Ruhl
>---
> tests/i915/gem_close_race.c | 68 +---
>-
> 1 file changed, 53 insertions(+), 15 deletions(-)
>
>diff --git a/tests/i915/gem_close_race.c b/tests/i915/gem_close_race.c
>index db570e8fd..4b72d353c 100644
>--- a/tests/i915/gem_close_race.c
>+++ b/tests/i915/gem_close_race.c
>@@ -55,7 +55,7 @@ static bool has_64bit_relocations;
>
> #define sigev_notify_thread_id _sigev_un._tid
>
>-static void selfcopy(int fd, uint32_t handle, int loops)
>+static void selfcopy(int fd, uint32_t ctx, uint32_t handle, int loops)
> {
> struct drm_i915_gem_relocation_entry reloc[2];
> struct drm_i915_gem_exec_object2 gem_exec[2];
>@@ -113,6 +113,7 @@ static void selfcopy(int fd, uint32_t handle, int loops)
> execbuf.batch_len = (b - buf) * sizeof(*b);
> if (HAS_BLT_RING(devid))
> execbuf.flags |= I915_EXEC_BLT;
>+ execbuf.rsvd1 = ctx;
>
> memset(_pwrite, 0, sizeof(gem_pwrite));
> gem_pwrite.handle = create.handle;
>@@ -135,7 +136,7 @@ static uint32_t load(int fd)
> if (handle == 0)
> return 0;
>
>- selfcopy(fd, handle, 100);
>+ selfcopy(fd, 0, handle, 100);
> return handle;
> }
>
>@@ -165,14 +166,19 @@ static void crashme_now(int sig)
> #define usec(x) (1000*(x))
> #define msec(x) usec(1000*(x))
>
>-static void threads(int timeout)
>+static void thread(int fd, struct drm_gem_open name,
>+ int timeout, unsigned int flags)
>+#define CONTEXTS 0x1
> {
> struct sigevent sev;
> struct sigaction act;
>- struct drm_gem_open name;
> struct itimerspec its;
>+ uint32_t *history;
>+#define N_HISTORY (256)
> timer_t timer;
>- int fd;
>+
>+ history = malloc(sizeof(*history) * N_HISTORY);
>+ igt_assert(history);
>
> memset(, 0, sizeof(act));
> act.sa_handler = crashme_now;
>@@ -184,28 +190,57 @@ static void threads(int timeout)
> sev.sigev_signo = SIGRTMIN;
> igt_assert(timer_create(CLOCK_MONOTONIC, , ) == 0);
>
>- fd = drm_open_driver(DRIVER_INTEL);
>- name.name = gem_flink(fd, gem_create(fd, OBJECT_SIZE));
>-
> igt_until_timeout(timeout) {
>- crashme.fd = drm_open_driver(DRIVER_INTEL);
>+ unsigned int n = 0;
>+
>+ memset(history, 0, sizeof(*history) * N_HISTORY);
>+
>+ crashme.fd = gem_reopen_driver(fd);
>
> memset(, 0, sizeof(its));
>- its.it_value.tv_nsec = msec(1) + (rand() % msec(10));
>+ its.it_value.tv_nsec = msec(1) + (rand() % msec(150));
> igt_assert(timer_settime(timer, 0, , NULL) == 0);
>
> do {
>- if (drmIoctl(crashme.fd, DRM_IOCTL_GEM_OPEN,
>))
>+ uint32_t ctx = 0;
>+
>+ if (drmIoctl(crashme.fd,
>+ DRM_IOCTL_GEM_OPEN,
>+ ))
> break;
>
>- selfcopy(crashme.fd, name.handle, 100);
>- drmIoctl(crashme.fd, DRM_IOCTL_GEM_CLOSE,
>);
>+ if (flags & CONTEXTS)
>+ __gem_context_create(crashme.fd, );
>+
>+ selfcopy(crashme.fd, ctx, name.handle, 1);
>+
>+ ctx = history[n % N_HISTORY];
Ahh this 'ctx' isn't really a context, it an unclosed handle.
So the difference is that you keep around N_HISTORY open handles and
the associated contexts (if requested) until the test is done.
And 256 is enough history? Any concerns with faster CPU/GPUs?
Looks like a good way to stress things.
Reviewed-by: M
Re: [Intel-gfx] [PATCH v2] drm/i915/gem: Move obj->lut_list under its own lock
>-Original Message-
>From: Chris Wilson
>Sent: Tuesday, June 30, 2020 3:29 PM
>To: Ruhl, Michael J ; intel-
>g...@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [PATCH v2] drm/i915/gem: Move obj->lut_list under
>its own lock
>
>Quoting Ruhl, Michael J (2020-06-30 20:11:16)
>> >-Original Message-
>> >From: Intel-gfx On Behalf Of
>Chris
>> >Wilson
>> >Sent: Monday, June 29, 2020 7:36 AM
>> >To: intel-gfx@lists.freedesktop.org
>> >Cc: Chris Wilson
>> >Subject: [Intel-gfx] [PATCH v2] drm/i915/gem: Move obj->lut_list under its
>> >own lock
>> >
>> >The obj->lut_list is traversed when the object is closed as the file
>> >table is destroyed during process termination. As this occurs before we
>> >kill any outstanding context if, due to some bug or another, the closure
>> >is blocked, then we fail to shootdown any inflight operations
>> >potentially leaving the GPU spinning forever. As we only need to guard
>> >the list against concurrent closures and insertions, the hold is short
>> >and merits being treated as a simple spinlock.
>>
>> The comment:
>>
>> /* Break long locks, and carefully continue on from this spot */
>>
>> seems to be contrary to your "the hold is short" comment. Is calling out
>> this apparent worst case scenario (i.e. how it could happen), worth
>> documenting?
>
>It's paranoia, because list iterating can be slow and historically slow
>object closure has been reported as an issue. Only a few objects will be
>shared between multiple contexts, and even then you would only expect a
>couple of contexts to share an object. One of the OglDrvCtx would show up
>here, which convinced us to move to the per-object lists to shrink the
>number of elements walked.
>
>Even the close race igts do not cause the list to become long enough to
>schedule, but it would be possible to create an object that was shared
>by 64k contexts. Just not wise in practice. [However, I should make sure
>an igt does hit the bookmark.]
I look forward to that igt.
>
>> >@@ -104,21 +105,29 @@ void i915_gem_close_object(struct
>> >drm_gem_object *gem, struct drm_file *file)
>> > {
>> > struct drm_i915_gem_object *obj = to_intel_bo(gem);
>> > struct drm_i915_file_private *fpriv = file->driver_priv;
>> >+ struct i915_lut_handle bookmark = {};
>> > struct i915_mmap_offset *mmo, *mn;
>> > struct i915_lut_handle *lut, *ln;
>> > LIST_HEAD(close);
>> >
>> >- i915_gem_object_lock(obj);
>> >+ spin_lock(>lut_lock);
>> > list_for_each_entry_safe(lut, ln, >lut_list, obj_link) {
>> > struct i915_gem_context *ctx = lut->ctx;
>> >
>> >- if (ctx->file_priv != fpriv)
>> >- continue;
>> >+ if (ctx && ctx->file_priv == fpriv) {
>>
>> Null checking ctx was not done before. I think this changed with the
>possible cond_resched?
>
>The bookmark introduces the lut->ctx == NULL to identify it as being
>special, hence the need to check.
Ok,
clean lock replacement with a paranoid worst case scenario, just in case.
Reviewed-by: Michael J. Ruhl
M
>-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/gem: Move obj->lut_list under its own lock
>-Original Message-
>From: Intel-gfx On Behalf Of Chris
>Wilson
>Sent: Monday, June 29, 2020 7:36 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Chris Wilson
>Subject: [Intel-gfx] [PATCH v2] drm/i915/gem: Move obj->lut_list under its
>own lock
>
>The obj->lut_list is traversed when the object is closed as the file
>table is destroyed during process termination. As this occurs before we
>kill any outstanding context if, due to some bug or another, the closure
>is blocked, then we fail to shootdown any inflight operations
>potentially leaving the GPU spinning forever. As we only need to guard
>the list against concurrent closures and insertions, the hold is short
>and merits being treated as a simple spinlock.
The comment:
/* Break long locks, and carefully continue on from this spot */
seems to be contrary to your "the hold is short" comment. Is calling out
this apparent worst case scenario (i.e. how it could happen), worth
documenting?
>Signed-off-by: Chris Wilson
>---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 6 ++
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 4 ++--
> drivers/gpu/drm/i915/gem/i915_gem_object.c| 21 +--
> .../gpu/drm/i915/gem/i915_gem_object_types.h | 1 +
> 4 files changed, 20 insertions(+), 12 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
>b/drivers/gpu/drm/i915/gem/i915_gem_context.c
>index 5c13809dc3c8..6675447a47b9 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
>@@ -112,8 +112,7 @@ static void lut_close(struct i915_gem_context *ctx)
> if (!kref_get_unless_zero(>base.refcount))
> continue;
>
>- rcu_read_unlock();
>- i915_gem_object_lock(obj);
>+ spin_lock(>lut_lock);
> list_for_each_entry(lut, >lut_list, obj_link) {
> if (lut->ctx != ctx)
> continue;
>@@ -124,8 +123,7 @@ static void lut_close(struct i915_gem_context *ctx)
> list_del(>obj_link);
> break;
> }
>- i915_gem_object_unlock(obj);
>- rcu_read_lock();
>+ spin_unlock(>lut_lock);
>
> if (>obj_link != >lut_list) {
> i915_lut_handle_free(lut);
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>index c38ab51e82f0..b4862afaaf28 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>@@ -789,14 +789,14 @@ static int __eb_add_lut(struct i915_execbuffer *eb,
> if (err == 0) { /* And nor has this handle */
> struct drm_i915_gem_object *obj = vma->obj;
>
>- i915_gem_object_lock(obj);
>+ spin_lock(>lut_lock);
> if (idr_find(>file->object_idr, handle) == obj) {
> list_add(>obj_link, >lut_list);
> } else {
> radix_tree_delete(>handles_vma,
>handle);
> err = -ENOENT;
> }
>- i915_gem_object_unlock(obj);
>+ spin_unlock(>lut_lock);
> }
> mutex_unlock(>mutex);
> }
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>index b6ec5b50d93b..6b69191c5543 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>@@ -61,6 +61,7 @@ void i915_gem_object_init(struct drm_i915_gem_object
>*obj,
> INIT_LIST_HEAD(>mm.link);
>
> INIT_LIST_HEAD(>lut_list);
>+ spin_lock_init(>lut_lock);
>
> spin_lock_init(>mmo.lock);
> obj->mmo.offsets = RB_ROOT;
>@@ -104,21 +105,29 @@ void i915_gem_close_object(struct
>drm_gem_object *gem, struct drm_file *file)
> {
> struct drm_i915_gem_object *obj = to_intel_bo(gem);
> struct drm_i915_file_private *fpriv = file->driver_priv;
>+ struct i915_lut_handle bookmark = {};
> struct i915_mmap_offset *mmo, *mn;
> struct i915_lut_handle *lut, *ln;
> LIST_HEAD(close);
>
>- i915_gem_object_lock(obj);
>+ spin_lock(>lut_lock);
> list_for_each_entry_safe(lut, ln, >lut_list, obj_link) {
> struct i915_gem_context *ctx = lut->ctx;
>
>- if (ctx->file_priv != fpriv)
>- continue;
>+ if (ctx && ctx->file_priv == fpriv) {
Null checking ctx was not done before. I think this changed with the possible
cond_resched?
Or is this just being extra cautious?
Thanks,
Mike
>+ i915_gem_context_get(ctx);
>+ list_move(>obj_link, );
>+ }
>
>- i915_gem_context_get(ctx);
>- list_move(>obj_link, );
>+
Re: [Intel-gfx] [PATCH v2] drm/i915: Remove redundant i915_request_await_object in blit clears
>-Original Message-
>From: Tvrtko Ursulin
>Sent: Monday, June 15, 2020 12:16 PM
>To: Ruhl, Michael J ; Intel-
>g...@lists.freedesktop.org
>Cc: Ursulin, Tvrtko ; Auld, Matthew
>; Chris Wilson
>Subject: Re: [PATCH v2] drm/i915: Remove redundant
>i915_request_await_object in blit clears
>
>
>On 15/06/2020 17:11, Ruhl, Michael J wrote:
>>> -Original Message-
>>> From: Tvrtko Ursulin
>>> Sent: Monday, June 15, 2020 11:15 AM
>>> To: Intel-gfx@lists.freedesktop.org
>>> Cc: Ursulin, Tvrtko ; Auld, Matthew
>>> ; Chris Wilson ;
>Ruhl,
>>> Michael J
>>> Subject: [PATCH v2] drm/i915: Remove redundant
>i915_request_await_object
>>> in blit clears
>>>
>>> From: Tvrtko Ursulin
>>>
>>> One i915_request_await_object is enough and we keep the one under the
>>> object lock so it is final.
>>>
>>> At the same time move async clflushing setup under the same locked
>>> section and consolidate common code into a helper function.
>>>
>>> v2:
>>> * Emit initial breadcrumbs after aways are set up. (Chris)
>>>
>>> Signed-off-by: Tvrtko Ursulin
>>> Cc: Matthew Auld
>>> Cc: Chris Wilson
>>> Cc: Michael J. Ruhl
>>> ---
>>> .../gpu/drm/i915/gem/i915_gem_object_blt.c| 52 ---
>>> 1 file changed, 21 insertions(+), 31 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
>>> b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
>>> index f457d7130491..bfdb32d46877 100644
>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
>>> @@ -126,6 +126,17 @@ void intel_emit_vma_release(struct intel_context
>>> *ce, struct i915_vma *vma)
>>> intel_engine_pm_put(ce->engine);
>>> }
>>>
>>> +static int
>>> +move_obj_to_gpu(struct drm_i915_gem_object *obj,
>>
>> I am not understanding the name of this function.
>>
>> How is the object moved to the gpu? Is clflush a move? Or is
>> it that it is moving to the gpu domain?
>>
>> What about:
>>
>> obj_flush_and_wait()
>>
>> or just:
>>
>> flush_and_wait()
>>
>> ?
>>
>> Or am I missing something?
>
>Yes, the fact I have renamed the existing move_to_gpu to move_obj_to_gpu
>while moving it up in the file and so risked falling victim to bike
>shedding now. :D
Ok.
Code path makes sense to me.
Reviewed-by: Michael J. Ruhl
M
>
>Regards,
>
>Tvrtko
>
>>
>> Mike
>>
>>> + struct i915_request *rq,
>>> + bool write)
>>> +{
>>> + if (obj->cache_dirty & ~obj->cache_coherent)
>>> + i915_gem_clflush_object(obj, 0);
>>> +
>>> + return i915_request_await_object(rq, obj, write);
>>> +}
>>> +
>>> int i915_gem_object_fill_blt(struct drm_i915_gem_object *obj,
>>> struct intel_context *ce,
>>> u32 value)
>>> @@ -143,12 +154,6 @@ int i915_gem_object_fill_blt(struct
>>> drm_i915_gem_object *obj,
>>> if (unlikely(err))
>>> return err;
>>>
>>> - if (obj->cache_dirty & ~obj->cache_coherent) {
>>> - i915_gem_object_lock(obj);
>>> - i915_gem_clflush_object(obj, 0);
>>> - i915_gem_object_unlock(obj);
>>> - }
>>> -
>>> batch = intel_emit_vma_fill_blt(ce, vma, value);
>>> if (IS_ERR(batch)) {
>>> err = PTR_ERR(batch);
>>> @@ -165,27 +170,22 @@ int i915_gem_object_fill_blt(struct
>>> drm_i915_gem_object *obj,
>>> if (unlikely(err))
>>> goto out_request;
>>>
>>> - err = i915_request_await_object(rq, obj, true);
>>> - if (unlikely(err))
>>> - goto out_request;
>>> -
>>> - if (ce->engine->emit_init_breadcrumb) {
>>> - err = ce->engine->emit_init_breadcrumb(rq);
>>> - if (unlikely(err))
>>> - goto out_request;
>>> - }
>>> -
>>> i915_vma_lock(vma);
>>> - err = i915_request_await_object(rq, vma->obj, true);
>>> + err = move_obj_to_gpu(vma->obj, rq, true);
>>> if (err == 0)
>>> err = i915_vma_move_to_active(vma, rq,
>>> EXEC_OBJECT_WRITE);
>>> i
Re: [Intel-gfx] [PATCH v2] drm/i915: Remove redundant i915_request_await_object in blit clears
>-Original Message-
>From: Tvrtko Ursulin
>Sent: Monday, June 15, 2020 11:15 AM
>To: Intel-gfx@lists.freedesktop.org
>Cc: Ursulin, Tvrtko ; Auld, Matthew
>; Chris Wilson ; Ruhl,
>Michael J
>Subject: [PATCH v2] drm/i915: Remove redundant i915_request_await_object
>in blit clears
>
>From: Tvrtko Ursulin
>
>One i915_request_await_object is enough and we keep the one under the
>object lock so it is final.
>
>At the same time move async clflushing setup under the same locked
>section and consolidate common code into a helper function.
>
>v2:
> * Emit initial breadcrumbs after aways are set up. (Chris)
>
>Signed-off-by: Tvrtko Ursulin
>Cc: Matthew Auld
>Cc: Chris Wilson
>Cc: Michael J. Ruhl
>---
> .../gpu/drm/i915/gem/i915_gem_object_blt.c| 52 ---
> 1 file changed, 21 insertions(+), 31 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
>b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
>index f457d7130491..bfdb32d46877 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
>@@ -126,6 +126,17 @@ void intel_emit_vma_release(struct intel_context
>*ce, struct i915_vma *vma)
> intel_engine_pm_put(ce->engine);
> }
>
>+static int
>+move_obj_to_gpu(struct drm_i915_gem_object *obj,
I am not understanding the name of this function.
How is the object moved to the gpu? Is clflush a move? Or is
it that it is moving to the gpu domain?
What about:
obj_flush_and_wait()
or just:
flush_and_wait()
?
Or am I missing something?
Mike
>+ struct i915_request *rq,
>+ bool write)
>+{
>+ if (obj->cache_dirty & ~obj->cache_coherent)
>+ i915_gem_clflush_object(obj, 0);
>+
>+ return i915_request_await_object(rq, obj, write);
>+}
>+
> int i915_gem_object_fill_blt(struct drm_i915_gem_object *obj,
>struct intel_context *ce,
>u32 value)
>@@ -143,12 +154,6 @@ int i915_gem_object_fill_blt(struct
>drm_i915_gem_object *obj,
> if (unlikely(err))
> return err;
>
>- if (obj->cache_dirty & ~obj->cache_coherent) {
>- i915_gem_object_lock(obj);
>- i915_gem_clflush_object(obj, 0);
>- i915_gem_object_unlock(obj);
>- }
>-
> batch = intel_emit_vma_fill_blt(ce, vma, value);
> if (IS_ERR(batch)) {
> err = PTR_ERR(batch);
>@@ -165,27 +170,22 @@ int i915_gem_object_fill_blt(struct
>drm_i915_gem_object *obj,
> if (unlikely(err))
> goto out_request;
>
>- err = i915_request_await_object(rq, obj, true);
>- if (unlikely(err))
>- goto out_request;
>-
>- if (ce->engine->emit_init_breadcrumb) {
>- err = ce->engine->emit_init_breadcrumb(rq);
>- if (unlikely(err))
>- goto out_request;
>- }
>-
> i915_vma_lock(vma);
>- err = i915_request_await_object(rq, vma->obj, true);
>+ err = move_obj_to_gpu(vma->obj, rq, true);
> if (err == 0)
> err = i915_vma_move_to_active(vma, rq,
>EXEC_OBJECT_WRITE);
> i915_vma_unlock(vma);
> if (unlikely(err))
> goto out_request;
>
>- err = ce->engine->emit_bb_start(rq,
>- batch->node.start, batch->node.size,
>- 0);
>+ if (ce->engine->emit_init_breadcrumb)
>+ err = ce->engine->emit_init_breadcrumb(rq);
>+
>+ if (likely(!err))
>+ err = ce->engine->emit_bb_start(rq,
>+ batch->node.start,
>+ batch->node.size,
>+ 0);
> out_request:
> if (unlikely(err))
> i915_request_set_error_once(rq, err);
>@@ -317,16 +317,6 @@ struct i915_vma *intel_emit_vma_copy_blt(struct
>intel_context *ce,
> return ERR_PTR(err);
> }
>
>-static int move_to_gpu(struct i915_vma *vma, struct i915_request *rq, bool
>write)
>-{
>- struct drm_i915_gem_object *obj = vma->obj;
>-
>- if (obj->cache_dirty & ~obj->cache_coherent)
>- i915_gem_clflush_object(obj, 0);
>-
>- return i915_request_await_object(rq, obj, write);
>-}
>-
> int i915_gem_object_copy_blt(struct drm_i915_gem_object *src,
>struct drm_i915_gem_object *dst,
>struct intel_context *ce)
>@@ -375,7 +365,
Re: [Intel-gfx] [PATCH 02/24] drm/i915: Add an implementation for i915_gem_ww_ctx locking, v2.
>-Original Message-
>From: Intel-gfx On Behalf Of
>Maarten Lankhorst
>Sent: Wednesday, June 3, 2020 10:57 AM
>To: intel-gfx@lists.freedesktop.org
>Subject: [Intel-gfx] [PATCH 02/24] drm/i915: Add an implementation for
>i915_gem_ww_ctx locking, v2.
>
>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.
>
>Changes since v1:
>- Change ww_ctx and obj order in locking functions (Jonas Lahtinen)
Not to add more patches to this patch set, but this really seems like two
patches:
1) pre-work: add the new parameter to the locking (and add NULL to all the
calls)
2) add the new functionality, i.e. updates to the locking code (including the
test code)
Finding the new functionality amongst the noise of the parameter update is
a bit difficult.
Splitting into makes the first patch mechanical and compile checked, and the
second patch reviewable.
Other than that, this looks pretty reasonable.
Acked-by: Michael J. Ruhl
m
>Signed-off-by: Maarten Lankhorst
>---
> drivers/gpu/drm/i915/display/intel_display.c | 4 +-
> .../gpu/drm/i915/gem/i915_gem_client_blt.c| 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 4 +-
> drivers/gpu/drm/i915/gem/i915_gem_domain.c| 10 ++--
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 4 +-
> drivers/gpu/drm/i915/gem/i915_gem_object.c| 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_object.h| 38 +++---
> .../gpu/drm/i915/gem/i915_gem_object_blt.c| 2 +-
> .../gpu/drm/i915/gem/i915_gem_object_types.h | 9
> drivers/gpu/drm/i915/gem/i915_gem_pm.c| 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_tiling.c| 2 +-
> .../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +-
> .../i915/gem/selftests/i915_gem_client_blt.c | 2 +-
> .../i915/gem/selftests/i915_gem_coherency.c | 10 ++--
> .../drm/i915/gem/selftests/i915_gem_context.c | 4 +-
> .../drm/i915/gem/selftests/i915_gem_mman.c| 4 +-
> .../drm/i915/gem/selftests/i915_gem_phys.c| 2 +-
> .../gpu/drm/i915/gt/selftest_workarounds.c| 2 +-
> drivers/gpu/drm/i915/gvt/cmd_parser.c | 2 +-
> drivers/gpu/drm/i915/i915_gem.c | 52 +--
> drivers/gpu/drm/i915/i915_gem.h | 11
> drivers/gpu/drm/i915/selftests/i915_gem.c | 41 +++
> drivers/gpu/drm/i915/selftests/i915_vma.c | 2 +-
> .../drm/i915/selftests/intel_memory_region.c | 2 +-
> 25 files changed, 174 insertions(+), 43 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/display/intel_display.c
>b/drivers/gpu/drm/i915/display/intel_display.c
>index a9f752d26b4e..afa4328c3f54 100644
>--- a/drivers/gpu/drm/i915/display/intel_display.c
>+++ b/drivers/gpu/drm/i915/display/intel_display.c
>@@ -2309,7 +2309,7 @@ intel_pin_and_fence_fb_obj(struct
>drm_framebuffer *fb,
>
> void intel_unpin_fb_vma(struct i915_vma *vma, unsigned long flags)
> {
>- i915_gem_object_lock(vma->obj);
>+ i915_gem_object_lock(vma->obj, NULL);
> if (flags & PLANE_HAS_FENCE)
> i915_vma_unpin_fence(vma);
> i915_gem_object_unpin_from_display_plane(vma);
>@@ -17112,7 +17112,7 @@ static int intel_framebuffer_init(struct
>intel_framebuffer *intel_fb,
> if (!intel_fb->frontbuffer)
> return -ENOMEM;
>
>- i915_gem_object_lock(obj);
>+ i915_gem_object_lock(obj, NULL);
> tiling = i915_gem_object_get_tiling(obj);
> stride = i915_gem_object_get_stride(obj);
> i915_gem_object_unlock(obj);
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
>b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
>index d3a86a4d5c04..c182091c00ff 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
>@@ -286,7 +286,7 @@ int i915_gem_schedule_fill_pages_blt(struct
>drm_i915_gem_object *obj,
> dma_fence_init(>dma, _pages_work_ops,
>_lock, 0, 0);
> i915_sw_fence_init(>wait, clear_pages_work_notify);
>
>- i915_gem_object_lock(obj);
>+ i915_gem_object_lock(obj, NULL);
> err = i915_sw_fence_await_reservation(>wait,
> obj->base.resv, NULL, true, 0,
> I915_FENCE_GFP);
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
>b/drivers/gpu/drm/i915/gem/i915_gem_context.c
>index f5d59d18cd5b..46abf903dc8a 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
>@@ -113,7 +113,7 @@ static void lut_close(struct i915_gem_context *ctx)
> continue;
>
> rcu_read_unlock();
>- i915_gem_object_lock(obj);
>+ i915_gem_object_lock(obj, NULL);
> list_for_each_entry(lut, >lut_list,
Re: [Intel-gfx] [PATCH 2/3] dma-fence: use default wait function for mock fences
>-Original Message-
>From: dri-devel On Behalf Of
>Ruhl, Michael J
>Sent: Monday, May 11, 2020 2:13 PM
>To: Daniel Vetter ; LKML ker...@vger.kernel.org>
>Cc: Intel Graphics Development ; DRI
>Development ; linaro-mm-
>s...@lists.linaro.org; Vetter, Daniel ; linux-
>me...@vger.kernel.org
>Subject: RE: [Intel-gfx] [PATCH 2/3] dma-fence: use default wait function for
>mock fences
>
>>-Original Message-
>>From: Intel-gfx On Behalf Of
>>Daniel Vetter
>>Sent: Monday, May 11, 2020 5:12 AM
>>To: LKML
>>Cc: Daniel Vetter ; Intel Graphics Development
>>; DRI Development >de...@lists.freedesktop.org>; linaro-mm-...@lists.linaro.org; Vetter, Daniel
>>; Sumit Semwal ;
>linux-
>>me...@vger.kernel.org
>>Subject: [Intel-gfx] [PATCH 2/3] dma-fence: use default wait function for
>>mock fences
>>
>>No need to micro-optmize when we're waiting in a mocked object ...
>
>Makes sense to me.
/sigh.
Reading Chris comment, I am no longer sure it make sense...
Un-ack?
m
>Acked-by: Michael J. Ruhl
>
>M
>
>>Signed-off-by: Daniel Vetter
>>Cc: Sumit Semwal
>>Cc: linux-me...@vger.kernel.org
>>Cc: linaro-mm-...@lists.linaro.org
>>---
>> drivers/dma-buf/st-dma-fence.c | 41 --
>> 1 file changed, 41 deletions(-)
>>
>>diff --git a/drivers/dma-buf/st-dma-fence.c b/drivers/dma-buf/st-dma-
>>fence.c
>>index e593064341c8..8166d2984702 100644
>>--- a/drivers/dma-buf/st-dma-fence.c
>>+++ b/drivers/dma-buf/st-dma-fence.c
>>@@ -33,50 +33,9 @@ static void mock_fence_release(struct dma_fence *f)
>> kmem_cache_free(slab_fences, to_mock_fence(f));
>> }
>>
>>-struct wait_cb {
>>- struct dma_fence_cb cb;
>>- struct task_struct *task;
>>-};
>>-
>>-static void mock_wakeup(struct dma_fence *f, struct dma_fence_cb *cb)
>>-{
>>- wake_up_process(container_of(cb, struct wait_cb, cb)->task);
>>-}
>>-
>>-static long mock_wait(struct dma_fence *f, bool intr, long timeout)
>>-{
>>- const int state = intr ? TASK_INTERRUPTIBLE :
>>TASK_UNINTERRUPTIBLE;
>>- struct wait_cb cb = { .task = current };
>>-
>>- if (dma_fence_add_callback(f, , mock_wakeup))
>>- return timeout;
>>-
>>- while (timeout) {
>>- set_current_state(state);
>>-
>>- if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags))
>>- break;
>>-
>>- if (signal_pending_state(state, current))
>>- break;
>>-
>>- timeout = schedule_timeout(timeout);
>>- }
>>- __set_current_state(TASK_RUNNING);
>>-
>>- if (!dma_fence_remove_callback(f, ))
>>- return timeout;
>>-
>>- if (signal_pending_state(state, current))
>>- return -ERESTARTSYS;
>>-
>>- return -ETIME;
>>-}
>>-
>> static const struct dma_fence_ops mock_ops = {
>> .get_driver_name = mock_name,
>> .get_timeline_name = mock_name,
>>- .wait = mock_wait,
>> .release = mock_fence_release,
>> };
>>
>>--
>>2.26.2
>>
>>___
>>Intel-gfx mailing list
>>Intel-gfx@lists.freedesktop.org
>>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>___
>dri-devel mailing list
>dri-de...@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] dma-fence: use default wait function for mock fences
>-Original Message-
>From: Intel-gfx On Behalf Of
>Daniel Vetter
>Sent: Monday, May 11, 2020 5:12 AM
>To: LKML
>Cc: Daniel Vetter ; Intel Graphics Development
>; DRI Development de...@lists.freedesktop.org>; linaro-mm-...@lists.linaro.org; Vetter, Daniel
>; Sumit Semwal ; linux-
>me...@vger.kernel.org
>Subject: [Intel-gfx] [PATCH 2/3] dma-fence: use default wait function for
>mock fences
>
>No need to micro-optmize when we're waiting in a mocked object ...
Makes sense to me.
Acked-by: Michael J. Ruhl
M
>Signed-off-by: Daniel Vetter
>Cc: Sumit Semwal
>Cc: linux-me...@vger.kernel.org
>Cc: linaro-mm-...@lists.linaro.org
>---
> drivers/dma-buf/st-dma-fence.c | 41 --
> 1 file changed, 41 deletions(-)
>
>diff --git a/drivers/dma-buf/st-dma-fence.c b/drivers/dma-buf/st-dma-
>fence.c
>index e593064341c8..8166d2984702 100644
>--- a/drivers/dma-buf/st-dma-fence.c
>+++ b/drivers/dma-buf/st-dma-fence.c
>@@ -33,50 +33,9 @@ static void mock_fence_release(struct dma_fence *f)
> kmem_cache_free(slab_fences, to_mock_fence(f));
> }
>
>-struct wait_cb {
>- struct dma_fence_cb cb;
>- struct task_struct *task;
>-};
>-
>-static void mock_wakeup(struct dma_fence *f, struct dma_fence_cb *cb)
>-{
>- wake_up_process(container_of(cb, struct wait_cb, cb)->task);
>-}
>-
>-static long mock_wait(struct dma_fence *f, bool intr, long timeout)
>-{
>- const int state = intr ? TASK_INTERRUPTIBLE :
>TASK_UNINTERRUPTIBLE;
>- struct wait_cb cb = { .task = current };
>-
>- if (dma_fence_add_callback(f, , mock_wakeup))
>- return timeout;
>-
>- while (timeout) {
>- set_current_state(state);
>-
>- if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags))
>- break;
>-
>- if (signal_pending_state(state, current))
>- break;
>-
>- timeout = schedule_timeout(timeout);
>- }
>- __set_current_state(TASK_RUNNING);
>-
>- if (!dma_fence_remove_callback(f, ))
>- return timeout;
>-
>- if (signal_pending_state(state, current))
>- return -ERESTARTSYS;
>-
>- return -ETIME;
>-}
>-
> static const struct dma_fence_ops mock_ops = {
> .get_driver_name = mock_name,
> .get_timeline_name = mock_name,
>- .wait = mock_wait,
> .release = mock_fence_release,
> };
>
>--
>2.26.2
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/writeback: don't set fence->ops to default
>-Original Message-
>From: dri-devel On Behalf Of
>Daniel Vetter
>Sent: Monday, May 11, 2020 5:12 AM
>To: LKML
>Cc: David Airlie ; Daniel Vetter ;
>Intel Graphics Development ; DRI
>Development ; Thomas Zimmermann
>; Vetter, Daniel
>Subject: [PATCH 1/3] drm/writeback: don't set fence->ops to default
>
>It's the default.
I can get behind that.
Reviewed-by: Michael J. Ruhl
>Signed-off-by: Daniel Vetter
>Cc: Maarten Lankhorst
>Cc: Maxime Ripard
>Cc: Thomas Zimmermann
>Cc: David Airlie
>Cc: Daniel Vetter
>---
> drivers/gpu/drm/drm_writeback.c | 1 -
> 1 file changed, 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/drm_writeback.c
>b/drivers/gpu/drm/drm_writeback.c
>index 43d9e3bb3a94..dccf4504f1bb 100644
>--- a/drivers/gpu/drm/drm_writeback.c
>+++ b/drivers/gpu/drm/drm_writeback.c
>@@ -108,7 +108,6 @@ static const struct dma_fence_ops
>drm_writeback_fence_ops = {
> .get_driver_name = drm_writeback_fence_get_driver_name,
> .get_timeline_name = drm_writeback_fence_get_timeline_name,
> .enable_signaling = drm_writeback_fence_enable_signaling,
>- .wait = dma_fence_default_wait,
> };
>
> static int create_writeback_properties(struct drm_device *dev)
>--
>2.26.2
>
>___
>dri-devel mailing list
>dri-de...@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/15] drm/i915: Replace the hardcoded I915_FENCE_TIMEOUT
>-Original Message- >From: Chris Wilson >Sent: Thursday, May 7, 2020 9:57 AM >To: Ruhl, Michael J ; intel- >g...@lists.freedesktop.org >Subject: Re: [Intel-gfx] [PATCH 12/15] drm/i915: Replace the hardcoded >I915_FENCE_TIMEOUT > >Quoting Ruhl, Michael J (2020-05-07 14:53:00) >> >> >> >-Original Message- >> >From: Intel-gfx On Behalf Of >Chris >> >Wilson >> >diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c >> >b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c >> >index 3a146aa2593b..d3a86a4d5c04 100644 >> >--- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c >> >+++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c >> >@@ -288,8 +288,7 @@ int i915_gem_schedule_fill_pages_blt(struct >> >drm_i915_gem_object *obj, >> > >> > i915_gem_object_lock(obj); >> > err = i915_sw_fence_await_reservation(>wait, >> >-obj->base.resv, NULL, >> >-true, I915_FENCE_TIMEOUT, >> >+obj->base.resv, NULL, true, 0, >> >> Did you miss this one, or is the '0' on purpose? > >It should be 0, as it should be only handling internal fences which may >take as long as required and should not be timed out. > >Still this is a placeholder function and should not be taken too >seriously. Assuming that the "placeholder function" is the _fill_pages_blt()... Acked-by: Michael J. Ruhl Mike >-Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/15] drm/i915: Replace the hardcoded I915_FENCE_TIMEOUT
>-Original Message-
>From: Intel-gfx On Behalf Of Chris
>Wilson
>Sent: Wednesday, May 6, 2020 4:59 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Chris Wilson
>Subject: [Intel-gfx] [PATCH 12/15] drm/i915: Replace the hardcoded
>I915_FENCE_TIMEOUT
>
>Expose the hardcoded timeout for unsignaled foreign fences as a Kconfig
>option, primarily to allow brave systems to disable the timeout and
>solely rely on correct signaling.
>
>Signed-off-by: Chris Wilson
>Cc: Joonas Lahtinen
>---
> drivers/gpu/drm/i915/Kconfig.profile | 12
> drivers/gpu/drm/i915/Makefile | 1 +
> drivers/gpu/drm/i915/display/intel_display.c | 5 +++--
> drivers/gpu/drm/i915/gem/i915_gem_clflush.c| 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_client_blt.c | 3 +--
> drivers/gpu/drm/i915/gem/i915_gem_fence.c | 4 ++--
> drivers/gpu/drm/i915/i915_config.c | 15 +++
> drivers/gpu/drm/i915/i915_drv.h| 10 +-
> drivers/gpu/drm/i915/i915_request.c| 9 ++---
> 9 files changed, 50 insertions(+), 11 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/i915_config.c
>
>diff --git a/drivers/gpu/drm/i915/Kconfig.profile
>b/drivers/gpu/drm/i915/Kconfig.profile
>index 0bfd276c19fe..3925be65d314 100644
>--- a/drivers/gpu/drm/i915/Kconfig.profile
>+++ b/drivers/gpu/drm/i915/Kconfig.profile
>@@ -1,3 +1,15 @@
>+config DRM_I915_FENCE_TIMEOUT
>+ int "Timeout for unsignaled foreign fences"
>+ default 1 # milliseconds
>+ help
>+When listening to a foreign fence, we install a supplementary timer
>+to ensure that we are always signaled and our userspace is able to
>+make forward progress. This value specifies the timeout used for an
>+unsignaled foreign fence.
>+
>+May be 0 to disable the timeout, and rely on the foreign fence being
>+eventually signaled.
>+
> config DRM_I915_USERFAULT_AUTOSUSPEND
> int "Runtime autosuspend delay for userspace GGTT mmaps (ms)"
> default 250 # milliseconds
>diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
>index 5359c736c789..b0da6ea6e3f1 100644
>--- a/drivers/gpu/drm/i915/Makefile
>+++ b/drivers/gpu/drm/i915/Makefile
>@@ -35,6 +35,7 @@ subdir-ccflags-y += -I$(srctree)/$(src)
>
> # core driver code
> i915-y += i915_drv.o \
>+i915_config.o \
> i915_irq.o \
> i915_getparam.o \
> i915_params.o \
>diff --git a/drivers/gpu/drm/i915/display/intel_display.c
>b/drivers/gpu/drm/i915/display/intel_display.c
>index fd6d63b03489..432b4eeaf9f6 100644
>--- a/drivers/gpu/drm/i915/display/intel_display.c
>+++ b/drivers/gpu/drm/i915/display/intel_display.c
>@@ -15814,7 +15814,7 @@ intel_prepare_plane_fb(struct drm_plane
>*_plane,
> if (new_plane_state->uapi.fence) { /* explicit fencing */
> ret = i915_sw_fence_await_dma_fence(
>>commit_ready,
> new_plane_state-
>>uapi.fence,
>- I915_FENCE_TIMEOUT,
>+
>i915_fence_timeout(dev_priv),
> GFP_KERNEL);
> if (ret < 0)
> return ret;
>@@ -15841,7 +15841,8 @@ intel_prepare_plane_fb(struct drm_plane
>*_plane,
>
> ret = i915_sw_fence_await_reservation(
>>commit_ready,
> obj->base.resv, NULL,
>-false,
>I915_FENCE_TIMEOUT,
>+false,
>+
>i915_fence_timeout(dev_priv),
> GFP_KERNEL);
> if (ret < 0)
> goto unpin_fb;
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
>b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
>index 34be4c0ee7c5..bc0223716906 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
>@@ -108,7 +108,7 @@ bool i915_gem_clflush_object(struct
>drm_i915_gem_object *obj,
> if (clflush) {
> i915_sw_fence_await_reservation(>base.chain,
> obj->base.resv, NULL, true,
>- I915_FENCE_TIMEOUT,
>+
> i915_fence_timeout(to_i915(obj->base.dev)),
> I915_FENCE_GFP);
> dma_resv_add_excl_fence(obj->base.resv,
>>base.dma);
> dma_fence_work_commit(>base);
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
>b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
>index 3a146aa2593b..d3a86a4d5c04 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
>@@ -288,8 +288,7 @@ int i915_gem_schedule_fill_pages_blt(struct
>drm_i915_gem_object *obj,
>
> i915_gem_object_lock(obj);
> err =
Re: [Intel-gfx] [PATCH v2] drm/i915: Refactor setting dma info to a common helper
>-Original Message- >From: Chris Wilson >Sent: Friday, April 17, 2020 3:55 PM >To: Ruhl, Michael J ; intel- >g...@lists.freedesktop.org >Subject: Re: [Intel-gfx] [PATCH v2] drm/i915: Refactor setting dma info to a >common helper > >Quoting Michael J. Ruhl (2020-04-17 20:51:07) >> DMA_MASK bit values are different for different generations. >> >> This will become more difficult to manage over time with the open >> coded usage of different versions of the device. >> >> Fix by: >> disallow setting of dma mask in AGP path (< GEN(5) for i915, >> add dma_mask_size to the device info configuration, >> updating open code call sequence to the latest interface, >> refactoring into a common function for setting the dma segment >> and mask info >> >> Reviewed-by: Chris Wilson >> Signed-off-by: Michael J. Ruhl >> cc: Brian Welty >> cc: Daniele Ceraolo Spurio >> >> --- >> v1: removed i915 depenancy from agp path for dma mask >> Consolidated segment size and work arounds to the helper >> v2: added r-b > >You don't need to resend for adding r-b by itself, patchwork will do >that, and the committer should be checking the output from pw. dim then >double checks that we haven't missed anything vital. Cool. I will refrain from future sends. M >-Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v1] drm/i915: Refactor setting dma info to a common helper
>-Original Message-
>From: Chris Wilson
>Sent: Friday, April 17, 2020 3:05 PM
>To: Ruhl, Michael J ; intel-
>g...@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [PATCH v1] drm/i915: Refactor setting dma info to a
>common helper
>
>Quoting Michael J. Ruhl (2020-04-17 19:51:34)
>> DMA_MASK bit values are different for different generations.
>>
>> This will become more difficult to manage over time with the open
>> coded usage of different versions of the device.
>>
>> Fix by:
>> disallow setting of dma mask in AGP path (< GEN(5) for i915,
>> add dma_mask_size to the device info configuration,
>> updating open code call sequence to the latest interface,
>> refactoring into a common function for setting the dma segment
>> and mask info
>>
>> Signed-off-by: Michael J. Ruhl
>> cc: Brian Welty
>> cc: Daniele Ceraolo Spurio
>>
>> ---
>> v1: removed i915 depenancy from agp path for dma mask
>> Consolidated segment size and work arounds to the helper
>> ---
>> drivers/char/agp/intel-gtt.c | 17 +++--
>> drivers/gpu/drm/i915/gt/intel_ggtt.c | 15
>> drivers/gpu/drm/i915/i915_drv.c | 94 +++-
>> drivers/gpu/drm/i915/i915_pci.c | 14
>> drivers/gpu/drm/i915/intel_device_info.c | 1 +
>> drivers/gpu/drm/i915/intel_device_info.h | 2 +
>> 6 files changed, 87 insertions(+), 56 deletions(-)
>>
>> diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
>> index 3d42fc4290bc..4b34a5195c65 100644
>> --- a/drivers/char/agp/intel-gtt.c
>> +++ b/drivers/char/agp/intel-gtt.c
>> @@ -1407,13 +1407,16 @@ int intel_gmch_probe(struct pci_dev
>*bridge_pdev, struct pci_dev *gpu_pdev,
>>
>> dev_info(_pdev->dev, "Intel %s Chipset\n",
>intel_gtt_chipsets[i].name);
>>
>> - mask = intel_private.driver->dma_mask_size;
>> - if (pci_set_dma_mask(intel_private.pcidev, DMA_BIT_MASK(mask)))
>> - dev_err(_private.pcidev->dev,
>> - "set gfx device dma mask %d-bit failed!\n", mask);
>> - else
>> - pci_set_consistent_dma_mask(intel_private.pcidev,
>> - DMA_BIT_MASK(mask));
>> + if (bridge) {
>> + mask = intel_private.driver->dma_mask_size;
>> + if (pci_set_dma_mask(intel_private.pcidev,
>DMA_BIT_MASK(mask)))
>> + dev_err(_private.pcidev->dev,
>> + "set gfx device dma mask %d-bit failed!\n",
>> + mask);
>> + else
>> + pci_set_consistent_dma_mask(intel_private.pcidev,
>> + DMA_BIT_MASK(mask));
>> + }
>
>This could even go under IS_ENABLED(CONFIG_AGP_INTEL)
I was going to, but then I was going to have to add:
#if IS_ENABLED(CONFIG_AGP_INTEL)
int mask;
#endif
as well...so I stopped while I was a ahead. If you would like the #if I will
add it.
>> +/**
>> + * i915_set_dma_info - set all relevant PCI dma info as configured for the
>> + * platform
>> + * @i915: valid i915 instance
>> + *
>> + * Set the dma max segment size, device and coherent masks. The dma
>mask set
>> + * needs to occur before i915_ggtt_probe_hw.
>> + *
>> + * A couple of platforms have special needs. Address them as well.
>> + *
>> + */
>> +static int i915_set_dma_info(struct drm_i915_private *i915)
>> +{
>> + struct pci_dev *pdev = i915->drm.pdev;
>> + unsigned int mask_size = INTEL_INFO(i915)->dma_mask_size;
>> + int ret;
>> +
>> + GEM_BUG_ON(!mask_size);
>> +
>> + /*
>> +* We don't have a max segment size, so set it to the max so sg's
>> +* debugging layer doesn't complain
>> +*/
>> + dma_set_max_seg_size(>dev, UINT_MAX);
>> +
>> + ret = dma_set_mask(>dev, DMA_BIT_MASK(mask_size));
>> + if (ret)
>> + goto mask_err;
>> +
>> + /* overlay on gen2 is broken and can't address above 1G */
>> + if (IS_GEN(i915, 2))
>> + mask_size = 30;
>> +
>> + /*
>> +* 965GM sometimes incorrectly writes to hardware status page (HWS)
>> +* using 32bit addressing, overwriting memory if HWS is located
>> +* above 4GB.
>> +*
>> +* The documentation also
Re: [Intel-gfx] [PATCH] drm/i915: Refactor dma mask usage to a common helper
>-Original Message- >From: Ruhl, Michael J >Sent: Friday, April 17, 2020 1:21 PM >To: 'Chris Wilson' ; intel-gfx@lists.freedesktop.org >Subject: RE: [Intel-gfx] [PATCH] drm/i915: Refactor dma mask usage to a >common helper > >>-Original Message- >>From: Chris Wilson >>Sent: Friday, April 17, 2020 12:20 PM >>To: Ruhl, Michael J ; intel- >>g...@lists.freedesktop.org >>Subject: Re: [Intel-gfx] [PATCH] drm/i915: Refactor dma mask usage to a >>common helper >> >>Quoting Ruhl, Michael J (2020-04-17 17:07:24) >>> >-Original Message----- >>> >From: Chris Wilson >>> >Sent: Friday, April 17, 2020 11:43 AM >>> >To: Ruhl, Michael J ; intel- >>> >g...@lists.freedesktop.org >>> >Subject: Re: [Intel-gfx] [PATCH] drm/i915: Refactor dma mask usage to a >>> >common helper >>> > >>> >Quoting Michael J. Ruhl (2020-04-17 16:22:44) >>> >> DMA_MASK bit values are different for different generations. >>> >> >>> >> This will become more difficult to manage over time with the open >>> >> coded usage of different versions of the device. >>> >> >>> >> Fix by: >>> >> adding dma_mask_size to the device info configuration, >>> >> updating open code call sequence to the latest interface, >>> >> refactoring into a common function for setting the dma_mask >>> >> >>> >> Note: GEN(5) and down is also set in intel_gmch_probe(). >>> > >>> >Assume we pull that code into i915.ko, we will one day. >>> >>> The gen5 stuff has the same dma_mask_size that I added to the >>> i915 config structures. >>> >>> I thought about pulling it out of the gen 5 area, but it appears that that >>> can be built as a separate driver, and if I pulled it out, the ability for >>> it to >>> be set in that path would be lost. >> >>It's not viable standalone anymore. It's over a decade dead by this >>point, we can drop the old AGP interface and then the sole user is >>i915.ko. Even if we did not, you can't use the AGP interface at the same >>time as i915.ko so we can just orphan char/agp, and use our own code. > >Ok, so can I do something like this in char/agp/intel-gtt.c: > >#if IS_ENABLED(CONFIG_AGP_INTEL) > mask = intel_private.driver->dma_mask_size; > if (pci_set_dma_mask(intel_private.pcidev, DMA_BIT_MASK(mask))) > dev_err(_private.pcidev->dev, > "set gfx device dma mask %d-bit failed!\n", mask); > else > pci_set_consistent_dma_mask(intel_private.pcidev, > DMA_BIT_MASK(mask)); >#endif Hmmm, will still need to add an "if (bridge)" around it as well. M > >This would fix my flow issue from the previous comments. > >Mike > >>-Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Refactor dma mask usage to a common helper
>-Original Message- >From: Chris Wilson >Sent: Friday, April 17, 2020 12:20 PM >To: Ruhl, Michael J ; intel- >g...@lists.freedesktop.org >Subject: Re: [Intel-gfx] [PATCH] drm/i915: Refactor dma mask usage to a >common helper > >Quoting Ruhl, Michael J (2020-04-17 17:07:24) >> >-Original Message- >> >From: Chris Wilson >> >Sent: Friday, April 17, 2020 11:43 AM >> >To: Ruhl, Michael J ; intel- >> >g...@lists.freedesktop.org >> >Subject: Re: [Intel-gfx] [PATCH] drm/i915: Refactor dma mask usage to a >> >common helper >> > >> >Quoting Michael J. Ruhl (2020-04-17 16:22:44) >> >> DMA_MASK bit values are different for different generations. >> >> >> >> This will become more difficult to manage over time with the open >> >> coded usage of different versions of the device. >> >> >> >> Fix by: >> >> adding dma_mask_size to the device info configuration, >> >> updating open code call sequence to the latest interface, >> >> refactoring into a common function for setting the dma_mask >> >> >> >> Note: GEN(5) and down is also set in intel_gmch_probe(). >> > >> >Assume we pull that code into i915.ko, we will one day. >> >> The gen5 stuff has the same dma_mask_size that I added to the >> i915 config structures. >> >> I thought about pulling it out of the gen 5 area, but it appears that that >> can be built as a separate driver, and if I pulled it out, the ability for >> it to >> be set in that path would be lost. > >It's not viable standalone anymore. It's over a decade dead by this >point, we can drop the old AGP interface and then the sole user is >i915.ko. Even if we did not, you can't use the AGP interface at the same >time as i915.ko so we can just orphan char/agp, and use our own code. Ok, so can I do something like this in char/agp/intel-gtt.c: #if IS_ENABLED(CONFIG_AGP_INTEL) mask = intel_private.driver->dma_mask_size; if (pci_set_dma_mask(intel_private.pcidev, DMA_BIT_MASK(mask))) dev_err(_private.pcidev->dev, "set gfx device dma mask %d-bit failed!\n", mask); else pci_set_consistent_dma_mask(intel_private.pcidev, DMA_BIT_MASK(mask)); #endif This would fix my flow issue from the previous comments. Mike >-Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Refactor dma mask usage to a common helper
>-Original Message-
>From: Chris Wilson
>Sent: Friday, April 17, 2020 12:17 PM
>To: Ruhl, Michael J ; intel-
>g...@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [PATCH] drm/i915: Refactor dma mask usage to a
>common helper
>
>Quoting Ruhl, Michael J (2020-04-17 17:05:07)
>> >-Original Message-
>> >From: Chris Wilson
>> >Sent: Friday, April 17, 2020 11:42 AM
>> >To: Ruhl, Michael J ; intel-
>> >g...@lists.freedesktop.org
>> >Subject: Re: [Intel-gfx] [PATCH] drm/i915: Refactor dma mask usage to a
>> >common helper
>> >
>> >Quoting Michael J. Ruhl (2020-04-17 16:22:44)
>> >> DMA_MASK bit values are different for different generations.
>> >>
>> >> This will become more difficult to manage over time with the open
>> >> coded usage of different versions of the device.
>> >>
>> >> Fix by:
>> >> adding dma_mask_size to the device info configuration,
>> >> updating open code call sequence to the latest interface,
>> >> refactoring into a common function for setting the dma_mask
>> >>
>> >> Note: GEN(5) and down is also set in intel_gmch_probe().
>> >>
>> >> Signed-off-by: Michael J. Ruhl
>> >> cc: Brian Welty
>> >> cc: Daniele Ceraolo Spurio
>> >> ---
>> >> drivers/gpu/drm/i915/gt/intel_ggtt.c | 15 --
>> >> drivers/gpu/drm/i915/i915_drv.c | 25
>
>> >> drivers/gpu/drm/i915/i915_pci.c | 14 +
>> >> drivers/gpu/drm/i915/intel_device_info.c | 1 +
>> >> drivers/gpu/drm/i915/intel_device_info.h | 2 ++
>> >> 5 files changed, 42 insertions(+), 15 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
>> >b/drivers/gpu/drm/i915/gt/intel_ggtt.c
>> >> index eebd1190506f..66165b10256e 100644
>> >> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
>> >> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
>> >> @@ -840,7 +840,6 @@ static int gen8_gmch_probe(struct i915_ggtt
>*ggtt)
>> >> struct pci_dev *pdev = i915->drm.pdev;
>> >> unsigned int size;
>> >> u16 snb_gmch_ctl;
>> >> - int err;
>> >>
>> >> /* TODO: We're not aware of mappable constraints on gen8 yet */
>> >> if (!IS_DGFX(i915)) {
>> >> @@ -848,13 +847,6 @@ static int gen8_gmch_probe(struct i915_ggtt
>*ggtt)
>> >> ggtt->mappable_end = resource_size(>gmadr);
>> >> }
>> >>
>> >> - err = pci_set_dma_mask(pdev, DMA_BIT_MASK(39));
>> >> - if (!err)
>> >> - err = pci_set_consistent_dma_mask(pdev,
>DMA_BIT_MASK(39));
>> >> - if (err)
>> >> - drm_err(>drm,
>> >> - "Can't set DMA mask/consistent mask (%d)\n", err);
>> >> -
>> >> pci_read_config_word(pdev, SNB_GMCH_CTRL, _gmch_ctl);
>> >> if (IS_CHERRYVIEW(i915))
>> >> size = chv_get_total_gtt_size(snb_gmch_ctl);
>> >> @@ -990,7 +982,6 @@ static int gen6_gmch_probe(struct i915_ggtt
>*ggtt)
>> >> struct pci_dev *pdev = i915->drm.pdev;
>> >> unsigned int size;
>> >> u16 snb_gmch_ctl;
>> >> - int err;
>> >>
>> >> ggtt->gmadr = pci_resource(pdev, 2);
>> >> ggtt->mappable_end = resource_size(>gmadr);
>> >> @@ -1005,12 +996,6 @@ static int gen6_gmch_probe(struct i915_ggtt
>*ggtt)
>> >> return -ENXIO;
>> >> }
>> >>
>> >> - err = pci_set_dma_mask(pdev, DMA_BIT_MASK(40));
>> >> - if (!err)
>> >> - err = pci_set_consistent_dma_mask(pdev,
>DMA_BIT_MASK(40));
>> >> - if (err)
>> >> - drm_err(>drm,
>> >> - "Can't set DMA mask/consistent mask (%d)\n", err);
>> >> pci_read_config_word(pdev, SNB_GMCH_CTRL, _gmch_ctl);
>> >>
>> >> size = gen6_get_total_gtt_size(snb_gmch_ctl);
>> >> diff --git a/drivers/gpu/drm/i915/i915_drv.c
>> >b/drivers/gpu/drm/i915/i915_drv.c
>> >> index 641f5e03b661..3c5654b5d321 100644
>> >> --- a/drivers/gpu/drm/i915/i915_drv.c
>>
Re: [Intel-gfx] [PATCH] drm/i915: Refactor dma mask usage to a common helper
>-Original Message- >From: Chris Wilson >Sent: Friday, April 17, 2020 11:43 AM >To: Ruhl, Michael J ; intel- >g...@lists.freedesktop.org >Subject: Re: [Intel-gfx] [PATCH] drm/i915: Refactor dma mask usage to a >common helper > >Quoting Michael J. Ruhl (2020-04-17 16:22:44) >> DMA_MASK bit values are different for different generations. >> >> This will become more difficult to manage over time with the open >> coded usage of different versions of the device. >> >> Fix by: >> adding dma_mask_size to the device info configuration, >> updating open code call sequence to the latest interface, >> refactoring into a common function for setting the dma_mask >> >> Note: GEN(5) and down is also set in intel_gmch_probe(). > >Assume we pull that code into i915.ko, we will one day. The gen5 stuff has the same dma_mask_size that I added to the i915 config structures. I thought about pulling it out of the gen 5 area, but it appears that that can be built as a separate driver, and if I pulled it out, the ability for it to be set in that path would be lost. M >-Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Refactor dma mask usage to a common helper
>-Original Message-
>From: Chris Wilson
>Sent: Friday, April 17, 2020 11:42 AM
>To: Ruhl, Michael J ; intel-
>g...@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [PATCH] drm/i915: Refactor dma mask usage to a
>common helper
>
>Quoting Michael J. Ruhl (2020-04-17 16:22:44)
>> DMA_MASK bit values are different for different generations.
>>
>> This will become more difficult to manage over time with the open
>> coded usage of different versions of the device.
>>
>> Fix by:
>> adding dma_mask_size to the device info configuration,
>> updating open code call sequence to the latest interface,
>> refactoring into a common function for setting the dma_mask
>>
>> Note: GEN(5) and down is also set in intel_gmch_probe().
>>
>> Signed-off-by: Michael J. Ruhl
>> cc: Brian Welty
>> cc: Daniele Ceraolo Spurio
>> ---
>> drivers/gpu/drm/i915/gt/intel_ggtt.c | 15 --
>> drivers/gpu/drm/i915/i915_drv.c | 25
>> drivers/gpu/drm/i915/i915_pci.c | 14 +
>> drivers/gpu/drm/i915/intel_device_info.c | 1 +
>> drivers/gpu/drm/i915/intel_device_info.h | 2 ++
>> 5 files changed, 42 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
>b/drivers/gpu/drm/i915/gt/intel_ggtt.c
>> index eebd1190506f..66165b10256e 100644
>> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
>> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
>> @@ -840,7 +840,6 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
>> struct pci_dev *pdev = i915->drm.pdev;
>> unsigned int size;
>> u16 snb_gmch_ctl;
>> - int err;
>>
>> /* TODO: We're not aware of mappable constraints on gen8 yet */
>> if (!IS_DGFX(i915)) {
>> @@ -848,13 +847,6 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
>> ggtt->mappable_end = resource_size(>gmadr);
>> }
>>
>> - err = pci_set_dma_mask(pdev, DMA_BIT_MASK(39));
>> - if (!err)
>> - err = pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(39));
>> - if (err)
>> - drm_err(>drm,
>> - "Can't set DMA mask/consistent mask (%d)\n", err);
>> -
>> pci_read_config_word(pdev, SNB_GMCH_CTRL, _gmch_ctl);
>> if (IS_CHERRYVIEW(i915))
>> size = chv_get_total_gtt_size(snb_gmch_ctl);
>> @@ -990,7 +982,6 @@ static int gen6_gmch_probe(struct i915_ggtt *ggtt)
>> struct pci_dev *pdev = i915->drm.pdev;
>> unsigned int size;
>> u16 snb_gmch_ctl;
>> - int err;
>>
>> ggtt->gmadr = pci_resource(pdev, 2);
>> ggtt->mappable_end = resource_size(>gmadr);
>> @@ -1005,12 +996,6 @@ static int gen6_gmch_probe(struct i915_ggtt *ggtt)
>> return -ENXIO;
>> }
>>
>> - err = pci_set_dma_mask(pdev, DMA_BIT_MASK(40));
>> - if (!err)
>> - err = pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(40));
>> - if (err)
>> - drm_err(>drm,
>> - "Can't set DMA mask/consistent mask (%d)\n", err);
>> pci_read_config_word(pdev, SNB_GMCH_CTRL, _gmch_ctl);
>>
>> size = gen6_get_total_gtt_size(snb_gmch_ctl);
>> diff --git a/drivers/gpu/drm/i915/i915_drv.c
>b/drivers/gpu/drm/i915/i915_drv.c
>> index 641f5e03b661..3c5654b5d321 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.c
>> +++ b/drivers/gpu/drm/i915/i915_drv.c
>> @@ -566,6 +566,29 @@ static void intel_sanitize_options(struct
>drm_i915_private *dev_priv)
>> intel_gvt_sanitize_options(dev_priv);
>> }
>>
>> +/**
>> + * i915_set_dma_mask - set the dma mask as configured for the platform
>> + * @i915: valid i915 instance
>> + *
>> + * Set the dma device and coherent masks. This needs to occur before
>> + * i915_ggtt_probe_hw.
>> + *
>> + * NOTE: for devices < GEN(6), the dma_mask will also be set in
>> + * intel_gmch_probe() (i.e. it will be set a second time).
>> + */
>> +static void i915_set_dma_mask(struct drm_i915_private *i915)
>> +{
>> + struct pci_dev *pdev = i915->drm.pdev;
>> + unsigned int mask_size = INTEL_INFO(i915)->dma_mask_size;
>> + int err;
>> +
>> + GEM_BUG_ON(!mask_size);
>> +
>> + err = dma_set_mask_and_coherent(>dev,
>DMA_BIT_MASK(mask_size));
>> + if (err)
>> +
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Wait until we start timeslicing after a submit
>-Original Message-
>From: Chris Wilson
>Sent: Friday, April 3, 2020 4:34 PM
>To: Ruhl, Michael J ; intel-
>g...@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [PATCH] drm/i915/selftests: Wait until we start
>timeslicing after a submit
>
>Quoting Ruhl, Michael J (2020-04-03 21:31:42)
>> >-Original Message-
>> >From: Intel-gfx On Behalf Of
>Chris
>> >Wilson
>> >Sent: Friday, April 3, 2020 3:02 PM
>> >To: intel-gfx@lists.freedesktop.org
>> >Cc: Chris Wilson
>> >Subject: [Intel-gfx] [PATCH] drm/i915/selftests: Wait until we start
>timeslicing
>> >after a submit
>> >
>> >If we submit, we do not start timeslicnig until we process the CS event
>>
>> s/timeslicnig/timeslicing/
>>
>> >that marks the start of the context running on HW. So in the selftest,
>> >be sure to wait until we have processed the pending events before
>> >asserting that timeslicing has begun.
>> >
>> >Signed-off-by: Chris Wilson
>> >---
>> > drivers/gpu/drm/i915/gt/selftest_lrc.c | 6 +-
>> > 1 file changed, 5 insertions(+), 1 deletion(-)
>> >
>> >diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
>> >b/drivers/gpu/drm/i915/gt/selftest_lrc.c
>> >index 985d4041d929..9e02917695b1 100644
>> >--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
>> >+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
>> >@@ -1244,7 +1244,11 @@ static int live_timeslice_queue(void *arg)
>> > if (err)
>> > goto err_rq;
>> >
>> >- intel_engine_flush_submission(engine);
>> >+ /* Wait until we ack the release_queue and start timeslicing
>> >*/
>> >+ do {
>> >+ intel_engine_flush_submission(engine);
>> >+ } while (READ_ONCE(engine->execlists.pending[0]));
>>
>> Is this guaranteed to clear? Or should there be a count to protect against
>> the endless loop?
>
>Yes. If the HW stops, we reset it and clear the submission queue.
In that case:
Acked-by: Michael J. Ruhl
M
>-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Wait until we start timeslicing after a submit
>-Original Message-
>From: Intel-gfx On Behalf Of Chris
>Wilson
>Sent: Friday, April 3, 2020 3:02 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Chris Wilson
>Subject: [Intel-gfx] [PATCH] drm/i915/selftests: Wait until we start
>timeslicing
>after a submit
>
>If we submit, we do not start timeslicnig until we process the CS event
s/timeslicnig/timeslicing/
>that marks the start of the context running on HW. So in the selftest,
>be sure to wait until we have processed the pending events before
>asserting that timeslicing has begun.
>
>Signed-off-by: Chris Wilson
>---
> drivers/gpu/drm/i915/gt/selftest_lrc.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
>b/drivers/gpu/drm/i915/gt/selftest_lrc.c
>index 985d4041d929..9e02917695b1 100644
>--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
>+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
>@@ -1244,7 +1244,11 @@ static int live_timeslice_queue(void *arg)
> if (err)
> goto err_rq;
>
>- intel_engine_flush_submission(engine);
>+ /* Wait until we ack the release_queue and start timeslicing
>*/
>+ do {
>+ intel_engine_flush_submission(engine);
>+ } while (READ_ONCE(engine->execlists.pending[0]));
Is this guaranteed to clear? Or should there be a count to protect against
the endless loop?
Or am I too paranoid?
M
> if (!READ_ONCE(engine->execlists.timer.expires) &&
> !i915_request_completed(rq)) {
> struct drm_printer p =
>--
>2.20.1
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Wrap i915_active in a simple kreffed struct
>-Original Message-
>From: Intel-gfx On Behalf Of Chris
>Wilson
>Sent: Friday, March 27, 2020 7:22 AM
>To: intel-gfx@lists.freedesktop.org
>Subject: [Intel-gfx] [PATCH 2/3] drm/i915: Wrap i915_active in a simple
>kreffed struct
>
>For conveniences of callers that just want to use an i915_active to
>track a wide array of concurrent timelines, wrap the base i915_active
>struct inside a kref. This i915_active will self-destruct after use.
>
>Signed-off-by: Chris Wilson
>Cc: Mika Kuoppala
>Reviewed-by: Mika Kuoppala
>---
> drivers/gpu/drm/i915/i915_active.c | 53
>++
> drivers/gpu/drm/i915/i915_active.h | 4 +++
> 2 files changed, 57 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/i915_active.c
>b/drivers/gpu/drm/i915/i915_active.c
>index 7b685032cc1e..5df7704369fd 100644
>--- a/drivers/gpu/drm/i915/i915_active.c
>+++ b/drivers/gpu/drm/i915/i915_active.c
>@@ -939,6 +939,59 @@ void i915_active_noop(struct dma_fence *fence,
>struct dma_fence_cb *cb)
> active_fence_cb(fence, cb);
> }
>
>+struct auto_active {
>+ struct i915_active base;
>+ struct kref ref;
>+};
>+
>+struct i915_active *i915_active_get(struct i915_active *ref)
>+{
>+ struct auto_active *aa = container_of(ref, typeof(*aa), base);
>+
>+ kref_get(>ref);
Should this be kref_get_unless_zero()?
Mike
>+ return >base;
>+}
>+
>+static void auto_release(struct kref *ref)
>+{
>+ struct auto_active *aa = container_of(ref, typeof(*aa), ref);
>+
>+ i915_active_fini(>base);
>+ kfree(aa);
>+}
>+
>+void i915_active_put(struct i915_active *ref)
>+{
>+ struct auto_active *aa = container_of(ref, typeof(*aa), base);
>+
>+ kref_put(>ref, auto_release);
>+}
>+
>+static int auto_active(struct i915_active *ref)
>+{
>+ i915_active_get(ref);
>+ return 0;
>+}
>+
>+static void auto_retire(struct i915_active *ref)
>+{
>+ i915_active_put(ref);
>+}
>+
>+struct i915_active *i915_active_create(void)
>+{
>+ struct auto_active *aa;
>+
>+ aa = kmalloc(sizeof(*aa), GFP_KERNEL);
>+ if (!aa)
>+ return NULL;
>+
>+ kref_init(>ref);
>+ i915_active_init(>base, auto_active, auto_retire);
>+
>+ return >base;
>+}
>+
> #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
> #include "selftests/i915_active.c"
> #endif
>diff --git a/drivers/gpu/drm/i915/i915_active.h
>b/drivers/gpu/drm/i915/i915_active.h
>index 4f9aa7bab514..b526d310a585 100644
>--- a/drivers/gpu/drm/i915/i915_active.h
>+++ b/drivers/gpu/drm/i915/i915_active.h
>@@ -225,4 +225,8 @@ void i915_request_add_active_barriers(struct
>i915_request *rq);
> void i915_active_print(struct i915_active *ref, struct drm_printer *m);
> void i915_active_unlock_wait(struct i915_active *ref);
>
>+struct i915_active *i915_active_create(void);
>+struct i915_active *i915_active_get(struct i915_active *ref);
>+void i915_active_put(struct i915_active *ref);
>+
> #endif /* _I915_ACTIVE_H_ */
>--
>2.20.1
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/12] drm/i915: Wrap i915_active in a simple kreffed struct
>-Original Message-
>From: Intel-gfx On Behalf Of Chris
>Wilson
>Sent: Tuesday, March 17, 2020 8:27 AM
>To: intel-gfx@lists.freedesktop.org
>Subject: [Intel-gfx] [PATCH 02/12] drm/i915: Wrap i915_active in a simple
>kreffed struct
>
>For conveniences of callers that just want to use an i915_active to
>track a wide array of concurrent timelines, wrap the base i915_active
>struct inside a kref. This i915_active will self-destruct after use.
>
>Signed-off-by: Chris Wilson
>Cc: Mika Kuoppala
>Reviewed-by: Mika Kuoppala
>---
> drivers/gpu/drm/i915/i915_active.c | 53
>++
> drivers/gpu/drm/i915/i915_active.h | 4 +++
> 2 files changed, 57 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/i915_active.c
>b/drivers/gpu/drm/i915/i915_active.c
>index c4048628188a..535b8161a597 100644
>--- a/drivers/gpu/drm/i915/i915_active.c
>+++ b/drivers/gpu/drm/i915/i915_active.c
>@@ -937,6 +937,59 @@ void i915_active_noop(struct dma_fence *fence,
>struct dma_fence_cb *cb)
> active_fence_cb(fence, cb);
> }
>
>+struct auto_active {
>+ struct i915_active base;
>+ struct kref ref;
>+};
>+
>+struct i915_active *i915_active_get(struct i915_active *ref)
>+{
>+ struct auto_active *aa = container_of(ref, typeof(*aa), base);
>+
>+ kref_get(>ref);
Does this need to be kref_get_unless_zero()?
I asked this a couple of days ago, but found that the email for
chris-wilson.co.uk had bounced. Not sure if you have answered this or not.
Thanks,
Mike
>+ return >base;
>+}
>+
>+static void auto_release(struct kref *ref)
>+{
>+ struct auto_active *aa = container_of(ref, typeof(*aa), ref);
>+
>+ i915_active_fini(>base);
>+ kfree(aa);
>+}
>+
>+void i915_active_put(struct i915_active *ref)
>+{
>+ struct auto_active *aa = container_of(ref, typeof(*aa), base);
>+
>+ kref_put(>ref, auto_release);
>+}
>+
>+static int auto_active(struct i915_active *ref)
>+{
>+ i915_active_get(ref);
>+ return 0;
>+}
>+
>+static void auto_retire(struct i915_active *ref)
>+{
>+ i915_active_put(ref);
>+}
>+
>+struct i915_active *i915_active_create(void)
>+{
>+ struct auto_active *aa;
>+
>+ aa = kmalloc(sizeof(*aa), GFP_KERNEL);
>+ if (!aa)
>+ return NULL;
>+
>+ kref_init(>ref);
>+ i915_active_init(>base, auto_active, auto_retire);
>+
>+ return >base;
>+}
>+
> #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
> #include "selftests/i915_active.c"
> #endif
>diff --git a/drivers/gpu/drm/i915/i915_active.h
>b/drivers/gpu/drm/i915/i915_active.h
>index b3282ae7913c..bffbcf7751a7 100644
>--- a/drivers/gpu/drm/i915/i915_active.h
>+++ b/drivers/gpu/drm/i915/i915_active.h
>@@ -221,4 +221,8 @@ void i915_request_add_active_barriers(struct
>i915_request *rq);
> void i915_active_print(struct i915_active *ref, struct drm_printer *m);
> void i915_active_unlock_wait(struct i915_active *ref);
>
>+struct i915_active *i915_active_create(void);
>+struct i915_active *i915_active_get(struct i915_active *ref);
>+void i915_active_put(struct i915_active *ref);
>+
> #endif /* _I915_ACTIVE_H_ */
>--
>2.20.1
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/12] drm/i915: Wrap i915_active in a simple kreffed struct
>-Original Message-
>From: Intel-gfx On Behalf Of Chris
>Wilson
>Sent: Wednesday, March 11, 2020 9:31 AM
>To: intel-gfx@lists.freedesktop.org
>Subject: [Intel-gfx] [PATCH 02/12] drm/i915: Wrap i915_active in a simple
>kreffed struct
>
>For conveniences of callers that just want to use an i915_active to
>track a wide array of concurrent timelines, wrap the base i915_active
>struct inside a kref. This i915_active will self-destruct after use.
>
>Signed-off-by: Chris Wilson
>Cc: Mika Kuoppala
>Reviewed-by: Mika Kuoppala
>---
> drivers/gpu/drm/i915/i915_active.c | 53
>++
> drivers/gpu/drm/i915/i915_active.h | 4 +++
> 2 files changed, 57 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/i915_active.c
>b/drivers/gpu/drm/i915/i915_active.c
>index c4048628188a..535b8161a597 100644
>--- a/drivers/gpu/drm/i915/i915_active.c
>+++ b/drivers/gpu/drm/i915/i915_active.c
>@@ -937,6 +937,59 @@ void i915_active_noop(struct dma_fence *fence,
>struct dma_fence_cb *cb)
> active_fence_cb(fence, cb);
> }
>
>+struct auto_active {
>+ struct i915_active base;
>+ struct kref ref;
>+};
>+
>+struct i915_active *i915_active_get(struct i915_active *ref)
>+{
>+ struct auto_active *aa = container_of(ref, typeof(*aa), base);
>+
>+ kref_get(>ref);
Should this be:
kref_get_unless_zero()?
Mike
>+ return >base;
>+}
>+
>+static void auto_release(struct kref *ref)
>+{
>+ struct auto_active *aa = container_of(ref, typeof(*aa), ref);
>+
>+ i915_active_fini(>base);
>+ kfree(aa);
>+}
>+
>+void i915_active_put(struct i915_active *ref)
>+{
>+ struct auto_active *aa = container_of(ref, typeof(*aa), base);
>+
>+ kref_put(>ref, auto_release);
>+}
>+
>+static int auto_active(struct i915_active *ref)
>+{
>+ i915_active_get(ref);
>+ return 0;
>+}
>+
>+static void auto_retire(struct i915_active *ref)
>+{
>+ i915_active_put(ref);
>+}
>+
>+struct i915_active *i915_active_create(void)
>+{
>+ struct auto_active *aa;
>+
>+ aa = kmalloc(sizeof(*aa), GFP_KERNEL);
>+ if (!aa)
>+ return NULL;
>+
>+ kref_init(>ref);
>+ i915_active_init(>base, auto_active, auto_retire);
>+
>+ return >base;
>+}
>+
> #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
> #include "selftests/i915_active.c"
> #endif
>diff --git a/drivers/gpu/drm/i915/i915_active.h
>b/drivers/gpu/drm/i915/i915_active.h
>index b3282ae7913c..bffbcf7751a7 100644
>--- a/drivers/gpu/drm/i915/i915_active.h
>+++ b/drivers/gpu/drm/i915/i915_active.h
>@@ -221,4 +221,8 @@ void i915_request_add_active_barriers(struct
>i915_request *rq);
> void i915_active_print(struct i915_active *ref, struct drm_printer *m);
> void i915_active_unlock_wait(struct i915_active *ref);
>
>+struct i915_active *i915_active_create(void);
>+struct i915_active *i915_active_get(struct i915_active *ref);
>+void i915_active_put(struct i915_active *ref);
>+
> #endif /* _I915_ACTIVE_H_ */
>--
>2.20.1
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/19] drm/i915: Nuke arguments to eb_pin_engine
>-Original Message-
>From: Intel-gfx On Behalf Of
>Maarten Lankhorst
>Sent: Friday, February 14, 2020 5:31 AM
>To: intel-gfx@lists.freedesktop.org
>Subject: [Intel-gfx] [PATCH 10/19] drm/i915: Nuke arguments to
>eb_pin_engine
>
>Those arguments are already set as eb.file and eb.args, so kill off
>the extra arguments. This will allow us to move eb_pin_engine() to
>after we reserved all BO's.
"move eb_pin_engine() to"
I think you mean "too"? (as in "move eb_pin_engine also"
Or do you mean "move_eb_pin_engine to , after we"?
Other than that,
Acked-by: Michael J. Ruhl
Mike
>
>Signed-off-by: Maarten Lankhorst
>---
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 17 +++--
> 1 file changed, 7 insertions(+), 10 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>index a27aa85985bd..d96e7649314c 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>@@ -2393,11 +2393,10 @@ static void eb_unpin_engine(struct
>i915_execbuffer *eb)
> }
>
> static unsigned int
>-eb_select_legacy_ring(struct i915_execbuffer *eb,
>-struct drm_file *file,
>-struct drm_i915_gem_execbuffer2 *args)
>+eb_select_legacy_ring(struct i915_execbuffer *eb)
> {
> struct drm_i915_private *i915 = eb->i915;
>+ struct drm_i915_gem_execbuffer2 *args = eb->args;
> unsigned int user_ring_id = args->flags & I915_EXEC_RING_MASK;
>
> if (user_ring_id != I915_EXEC_BSD &&
>@@ -2412,7 +2411,7 @@ eb_select_legacy_ring(struct i915_execbuffer *eb,
> unsigned int bsd_idx = args->flags & I915_EXEC_BSD_MASK;
>
> if (bsd_idx == I915_EXEC_BSD_DEFAULT) {
>- bsd_idx = gen8_dispatch_bsd_engine(i915, file);
>+ bsd_idx = gen8_dispatch_bsd_engine(i915, eb->file);
> } else if (bsd_idx >= I915_EXEC_BSD_RING1 &&
> bsd_idx <= I915_EXEC_BSD_RING2) {
> bsd_idx >>= I915_EXEC_BSD_SHIFT;
>@@ -2437,18 +2436,16 @@ eb_select_legacy_ring(struct i915_execbuffer
>*eb,
> }
>
> static int
>-eb_pin_engine(struct i915_execbuffer *eb,
>-struct drm_file *file,
>-struct drm_i915_gem_execbuffer2 *args)
>+eb_pin_engine(struct i915_execbuffer *eb)
> {
> struct intel_context *ce;
> unsigned int idx;
> int err;
>
> if (i915_gem_context_user_engines(eb->gem_context))
>- idx = args->flags & I915_EXEC_RING_MASK;
>+ idx = eb->args->flags & I915_EXEC_RING_MASK;
> else
>- idx = eb_select_legacy_ring(eb, file, args);
>+ idx = eb_select_legacy_ring(eb);
>
> ce = i915_gem_context_get_engine(eb->gem_context, idx);
> if (IS_ERR(ce))
>@@ -2681,7 +2678,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
> if (unlikely(err))
> goto err_destroy;
>
>- err = eb_pin_engine(, file, args);
>+ err = eb_pin_engine();
> if (unlikely(err))
> goto err_context;
>
>--
>2.25.0.24.g3f081b084b0
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 19/19] drm/i915: Use ww pinning for intel_context_create_request()
>-Original Message-
>From: Intel-gfx On Behalf Of
>Maarten Lankhorst
>Sent: Friday, February 14, 2020 5:31 AM
>To: intel-gfx@lists.freedesktop.org
>Subject: [Intel-gfx] [PATCH 19/19] drm/i915: Use ww pinning for
>intel_context_create_request()
>
>We want to get rid of intel_context_pin(), convert
>intel_context_create_request() first. :)
>
>Signed-off-by: Maarten Lankhorst
>---
> drivers/gpu/drm/i915/gt/intel_context.c | 20 +++-
> 1 file changed, 15 insertions(+), 5 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
>b/drivers/gpu/drm/i915/gt/intel_context.c
>index 87f9f9e61916..44868b10be0a 100644
>--- a/drivers/gpu/drm/i915/gt/intel_context.c
>+++ b/drivers/gpu/drm/i915/gt/intel_context.c
>@@ -436,15 +436,25 @@ int intel_context_prepare_remote_request(struct
>intel_context *ce,
>
> struct i915_request *intel_context_create_request(struct intel_context *ce)
> {
>+ struct i915_gem_ww_ctx ww;
> struct i915_request *rq;
> int err;
>
>- err = intel_context_pin(ce);
>- if (unlikely(err))
>- return ERR_PTR(err);
>+ i915_gem_ww_ctx_init(, true);
>+retry:
>+ err = intel_context_pin_ww(ce, );
>+ if (!err) {
>+ rq = i915_request_create(ce);
>+ intel_context_unpin(ce);
>+ } else if (err == -EDEADLK) {
>+ err = i915_gem_ww_ctx_backoff();
>+ if (!err)
>+ goto retry;
>+ } else {
>+ rq = ERR_PTR(err);
>+ }
If you have the pathological path:
err = intel_context_pin_ww(cd, &&))
else if (err == -EDEADLK)
err = i915_gem_ww_ctx_backoff() ; (where err != 0)
It appears that you can get to IS_ERR(rq) with rq being garbage from the
stack.
Do you need to preset rq, or set it on:
if (!err)
goto retry;
else
rq = ERR_PTR(err);
?
Thanks,
Mike
>
>- rq = i915_request_create(ce);
>- intel_context_unpin(ce);
>+ i915_gem_ww_ctx_fini();
>
> if (IS_ERR(rq))
> return rq;
>--
>2.25.0.24.g3f081b084b0
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use the async worker to avoid reclaim tainting the ggtt->mutex
>-Original Message-
>From: Intel-gfx On Behalf Of Chris
>Wilson
>Sent: Thursday, January 30, 2020 10:21 AM
>To: intel-gfx@lists.freedesktop.org
>Subject: [Intel-gfx] [PATCH] drm/i915: Use the async worker to avoid reclaim
>tainting the ggtt->mutex
>
>On Braswell and Broxton (also known as Valleyview and Apollolake), we
>need to serialise updates of the GGTT using the big stop_machine()
>hammer. This has the side effect of appearing to lockdep as a possible
>reclaim (since it uses the cpuhp mutex and that is tainted by per-cpu
>allocations). However, we want to use vm->mutex (including ggtt->mutex)
>from wthin the shrinker and so must avoid such possible taints. For this
s/wthin/within
m
>purpose, we introduced the asynchronous vma binding and we can apply it
>to the PIN_GLOBAL so long as take care to add the necessary waits for
>the worker afterwards.
>
>Closes: https://gitlab.freedesktop.org/drm/intel/issues/211
>Signed-off-by: Chris Wilson
>---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 7 ++---
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 3 +-
> drivers/gpu/drm/i915/gt/intel_gt.c| 2 +-
> drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_ring.c | 6 ++--
> drivers/gpu/drm/i915/gt/intel_timeline.c | 4 +--
> drivers/gpu/drm/i915/gt/uc/intel_guc.c| 4 +--
> drivers/gpu/drm/i915/i915_active.c| 10 --
> drivers/gpu/drm/i915/i915_active.h| 3 +-
> drivers/gpu/drm/i915/i915_gem.c | 6
> drivers/gpu/drm/i915/i915_vma.c | 38 +--
> drivers/gpu/drm/i915/i915_vma.h | 2 ++
> 12 files changed, 66 insertions(+), 21 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>index decb63462410..86af5edd6933 100644
>--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>@@ -527,7 +527,6 @@ static int pin_ggtt_status_page(struct intel_engine_cs
>*engine,
> {
> unsigned int flags;
>
>- flags = PIN_GLOBAL;
> if (!HAS_LLC(engine->i915) && i915_ggtt_has_aperture(engine->gt-
>>ggtt))
> /*
>* On g33, we cannot place HWS above 256MiB, so
>@@ -540,11 +539,11 @@ static int pin_ggtt_status_page(struct
>intel_engine_cs *engine,
>* above the mappable region (even though we never
>* actually map it).
>*/
>- flags |= PIN_MAPPABLE;
>+ flags = PIN_MAPPABLE;
> else
>- flags |= PIN_HIGH;
>+ flags = PIN_HIGH;
>
>- return i915_vma_pin(vma, 0, 0, flags);
>+ return i915_ggtt_pin(vma, 0, flags);
> }
>
> static int init_status_page(struct intel_engine_cs *engine)
>diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
>b/drivers/gpu/drm/i915/gt/intel_ggtt.c
>index f624fc5c19c3..d9fd25480a46 100644
>--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
>+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
>@@ -109,7 +109,7 @@ static void ggtt_suspend_mappings(struct i915_ggtt
>*ggtt)
> struct i915_vma *vma;
>
> list_for_each_entry(vma, >vm.bound_list, vm_link)
>- i915_vma_sync(vma);
>+ i915_vma_wait_for_bind(vma);
>
> ggtt->vm.clear_range(>vm, 0, ggtt->vm.total);
> ggtt->invalidate(ggtt);
>@@ -851,6 +851,7 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
> IS_CHERRYVIEW(i915) /* fails with concurrent use/update */) {
> ggtt->vm.insert_entries = bxt_vtd_ggtt_insert_entries__BKL;
> ggtt->vm.insert_page= bxt_vtd_ggtt_insert_page__BKL;
>+ ggtt->vm.bind_async_flags = I915_VMA_GLOBAL_BIND;
> }
>
> ggtt->invalidate = gen8_ggtt_invalidate;
>diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
>b/drivers/gpu/drm/i915/gt/intel_gt.c
>index 51019611bc1e..f1f1b306e0af 100644
>--- a/drivers/gpu/drm/i915/gt/intel_gt.c
>+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
>@@ -344,7 +344,7 @@ static int intel_gt_init_scratch(struct intel_gt *gt,
>unsigned int size)
> goto err_unref;
> }
>
>- ret = i915_vma_pin(vma, 0, 0, PIN_GLOBAL | PIN_HIGH);
>+ ret = i915_ggtt_pin(vma, 0, PIN_HIGH);
> if (ret)
> goto err_unref;
>
>diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
>b/drivers/gpu/drm/i915/gt/intel_lrc.c
>index eb83c87c8b4e..fc0a72cc54fd 100644
>--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
>+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
>@@ -3268,7 +3268,7 @@ static int lrc_setup_wa_ctx(struct intel_engine_cs
>*engine)
> goto err;
> }
>
>- err = i915_vma_pin(vma, 0, 0, PIN_GLOBAL | PIN_HIGH);
>+ err = i915_ggtt_pin(vma, 0, PIN_HIGH);
> if (err)
> goto err;
>
>diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c
>b/drivers/gpu/drm/i915/gt/intel_ring.c
>index 374b28f13ca0..366013367526 100644
>--- a/drivers/gpu/drm/i915/gt/intel_ring.c
>+++ b/drivers/gpu/drm/i915/gt/intel_ring.c
>@@ -31,17 +31,15 @@
Re: [Intel-gfx] [PATCH 4/5] drm/i915/gem: Convert vm idr to xarray
>-Original Message-
>From: Chris Wilson
>Sent: Wednesday, January 22, 2020 11:09 AM
>To: Ruhl, Michael J ; intel-
>g...@lists.freedesktop.org
>Cc: Auld, Matthew
>Subject: RE: [Intel-gfx] [PATCH 4/5] drm/i915/gem: Convert vm idr to xarray
>
>Quoting Ruhl, Michael J (2020-01-22 16:00:25)
>> >-Original Message-
>> >From: Intel-gfx On Behalf Of
>Chris
>> >Wilson
>> >@@ -876,23 +868,13 @@ int i915_gem_vm_create_ioctl(struct drm_device
>> >*dev, void *data,
>> > goto err_put;
>> > }
>> >
>> >- err = mutex_lock_interruptible(_priv->vm_idr_lock);
>> >+ err = xa_alloc(_priv->vm_xa, >vm_id,
>> >+ >vm, xa_limit_32b, GFP_KERNEL);
>> > if (err)
>> > goto err_put;
>> >
>> >- err = idr_alloc(_priv->vm_idr, >vm, 0, 0, GFP_KERNEL);
>> >- if (err < 0)
>> >- goto err_unlock;
>> >-
>> >- GEM_BUG_ON(err == 0); /* reserved for invalid/unassigned ppgtt */
>>
>> Moving this comment to the xa_init_flags() would help me understand
>> why the index started at 1.
>
>Hey, I take 0 being reserved for granted, and had to think about why
>the context_xa was not 1-biased!
>
>> >@@ -1021,35 +991,27 @@ static int get_ppgtt(struct drm_i915_file_private
>> >*file_priv,
>> >struct drm_i915_gem_context_param *args)
>> > {
>> > struct i915_address_space *vm;
>> >- int ret;
>> >+ int err = -ENODEV;
>> >+ u32 id;
>> >
>> > if (!rcu_access_pointer(ctx->vm))
>> > return -ENODEV;
>> >
>> > rcu_read_lock();
>> > vm = context_get_vm_rcu(ctx);
>> >+ if (vm)
>> >+ err = xa_alloc(_priv->vm_xa, , vm,
>> >+ xa_limit_32b, GFP_KERNEL);
>> > rcu_read_unlock();
>> >+ if (!err) {
>> >+ i915_vm_open(vm);
>>
>> Why did you switch to success path in the if here?
>
>No good reason, just simple enough to fit inside one if {}.
>
>> Can you do:
>>
>> if (err)
>> goto err_put;
>>
>> ?
>>
>> >- ret = mutex_lock_interruptible(_priv->vm_idr_lock);
>> >- if (ret)
>> >- goto err_put;
>> >-
>> >- ret = idr_alloc(_priv->vm_idr, vm, 0, 0, GFP_KERNEL);
>> >- GEM_BUG_ON(!ret);
>> >- if (ret < 0)
>> >- goto err_unlock;
>> >-
>> >- i915_vm_open(vm);
>> >-
>> >- args->size = 0;
>> >- args->value = ret;
>> >+ args->size = 0;
>> >+ args->value = id;
>>
>> Would passing args->value to the xa_alloc be a useful?
>
>General rule is not to alter user params except on success. While not
>always required, the pattern does help to avoid common pitfalls where
>userspace has to repeat an ioctl (e.g. SIGINT).
Yup. Following that rule, xa_array() will only update the value on success.
I was mostly commenting on it because you had done that in the previous
xa_alloc call.
Thanks,
Mike
>-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm/i915/gem: Convert vm idr to xarray
>-Original Message-
>From: Intel-gfx On Behalf Of Chris
>Wilson
>Sent: Monday, January 20, 2020 5:49 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Auld, Matthew
>Subject: [Intel-gfx] [PATCH 4/5] drm/i915/gem: Convert vm idr to xarray
>
>Replace the vm_idr + vm_idr_mutex to an XArray. The XArray data
>structure is now used to implement IDRs, and provides its won locking.
s/won/own
>We can simply remove the IDR wrapper and in the process also remove our
>extra mutex.
>
>Signed-off-by: Chris Wilson
>Cc: Tvrtko Ursulin
>---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 80 ++---
> drivers/gpu/drm/i915/i915_drv.h | 4 +-
> 2 files changed, 22 insertions(+), 62 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
>b/drivers/gpu/drm/i915/gem/i915_gem_context.c
>index a2e57e62af30..d2e4e8cbf4d4 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
>@@ -761,12 +761,6 @@ void i915_gem_driver_release__contexts(struct
>drm_i915_private *i915)
> flush_work(>gem.contexts.free_work);
> }
>
>-static int vm_idr_cleanup(int id, void *p, void *data)
>-{
>- i915_vm_put(p);
>- return 0;
>-}
>-
> static int gem_context_register(struct i915_gem_context *ctx,
> struct drm_i915_file_private *fpriv,
> u32 *id)
>@@ -803,9 +797,7 @@ int i915_gem_context_open(struct drm_i915_private
>*i915,
> u32 id;
>
> xa_init_flags(_priv->context_xa, XA_FLAGS_ALLOC);
>-
>- mutex_init(_priv->vm_idr_lock);
>- idr_init_base(_priv->vm_idr, 1);
>+ xa_init_flags(_priv->vm_xa, XA_FLAGS_ALLOC1);
>
> ctx = i915_gem_create_context(i915, 0);
> if (IS_ERR(ctx)) {
>@@ -823,9 +815,8 @@ int i915_gem_context_open(struct drm_i915_private
>*i915,
> err_ctx:
> context_close(ctx);
> err:
>- idr_destroy(_priv->vm_idr);
>+ xa_destroy(_priv->vm_xa);
> xa_destroy(_priv->context_xa);
>- mutex_destroy(_priv->vm_idr_lock);
> return err;
> }
>
>@@ -833,6 +824,7 @@ void i915_gem_context_close(struct drm_file *file)
> {
> struct drm_i915_file_private *file_priv = file->driver_priv;
> struct drm_i915_private *i915 = file_priv->dev_priv;
>+ struct i915_address_space *vm;
> struct i915_gem_context *ctx;
> unsigned long idx;
>
>@@ -840,9 +832,9 @@ void i915_gem_context_close(struct drm_file *file)
> context_close(ctx);
> xa_destroy(_priv->context_xa);
>
>- idr_for_each(_priv->vm_idr, vm_idr_cleanup, NULL);
>- idr_destroy(_priv->vm_idr);
>- mutex_destroy(_priv->vm_idr_lock);
>+ xa_for_each(_priv->vm_xa, idx, vm)
>+ i915_vm_put(vm);
>+ xa_destroy(_priv->vm_xa);
>
> contexts_flush_free(>gem.contexts);
> }
>@@ -876,23 +868,13 @@ int i915_gem_vm_create_ioctl(struct drm_device
>*dev, void *data,
> goto err_put;
> }
>
>- err = mutex_lock_interruptible(_priv->vm_idr_lock);
>+ err = xa_alloc(_priv->vm_xa, >vm_id,
>+ >vm, xa_limit_32b, GFP_KERNEL);
> if (err)
> goto err_put;
>
>- err = idr_alloc(_priv->vm_idr, >vm, 0, 0, GFP_KERNEL);
>- if (err < 0)
>- goto err_unlock;
>-
>- GEM_BUG_ON(err == 0); /* reserved for invalid/unassigned ppgtt */
Moving this comment to the xa_init_flags() would help me understand
why the index started at 1.
>- mutex_unlock(_priv->vm_idr_lock);
>-
>- args->vm_id = err;
> return 0;
>
>-err_unlock:
>- mutex_unlock(_priv->vm_idr_lock);
> err_put:
> i915_vm_put(>vm);
> return err;
>@@ -904,8 +886,6 @@ int i915_gem_vm_destroy_ioctl(struct drm_device
>*dev, void *data,
> struct drm_i915_file_private *file_priv = file->driver_priv;
> struct drm_i915_gem_vm_control *args = data;
> struct i915_address_space *vm;
>- int err;
>- u32 id;
>
> if (args->flags)
> return -EINVAL;
>@@ -913,17 +893,7 @@ int i915_gem_vm_destroy_ioctl(struct drm_device
>*dev, void *data,
> if (args->extensions)
> return -EINVAL;
>
>- id = args->vm_id;
>- if (!id)
>- return -ENOENT;
>-
>- err = mutex_lock_interruptible(_priv->vm_idr_lock);
>- if (err)
>- return err;
>-
>- vm = idr_remove(_priv->vm_idr, id);
>-
>- mutex_unlock(_priv->vm_idr_lock);
>+ vm = xa_erase(_priv->vm_xa, args->vm_id);
> if (!vm)
> return -ENOENT;
>
>@@ -1021,35 +991,27 @@ static int get_ppgtt(struct drm_i915_file_private
>*file_priv,
>struct drm_i915_gem_context_param *args)
> {
> struct i915_address_space *vm;
>- int ret;
>+ int err = -ENODEV;
>+ u32 id;
>
> if (!rcu_access_pointer(ctx->vm))
> return -ENODEV;
>
> rcu_read_lock();
> vm = context_get_vm_rcu(ctx);
>+ if (vm)
>+ err = xa_alloc(_priv->vm_xa,
Re: [Intel-gfx] [PATCH] drm/i915/display: nuke skl workaround for pre-production hw
>-Original Message-
>From: Intel-gfx On Behalf Of Lucas
>De Marchi
>Sent: Friday, December 20, 2019 5:07 PM
>To: intel-gfx@lists.freedesktop.org
>Subject: [Intel-gfx] [PATCH] drm/i915/display: nuke skl workaround for pre-
>production hw
>
>According to intel_detect_preproduction_hw(), the SKL steeping D0 is
s/steeping/stepping/
?
M
>still pre-preproduction so we can nuke the additional workaround.
>
>While at it, nuke dangling new line.
>
>Signed-off-by: Lucas De Marchi
>---
> drivers/gpu/drm/i915/display/intel_display.c | 9 +
> 1 file changed, 1 insertion(+), 8 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/display/intel_display.c
>b/drivers/gpu/drm/i915/display/intel_display.c
>index e6702b9b9117..4aa7dfa88c7c 100644
>--- a/drivers/gpu/drm/i915/display/intel_display.c
>+++ b/drivers/gpu/drm/i915/display/intel_display.c
>@@ -16018,14 +16018,8 @@ static void intel_setup_outputs(struct
>drm_i915_private *dev_priv)
> if (intel_ddi_crt_present(dev_priv))
> intel_crt_init(dev_priv);
>
>- /*
>- * Haswell uses DDI functions to detect digital outputs.
>- * On SKL pre-D0 the strap isn't connected, so we assume
>- * it's there.
>- */
> found = I915_READ(DDI_BUF_CTL(PORT_A)) &
>DDI_INIT_DISPLAY_DETECTED;
>- /* WaIgnoreDDIAStrap: skl */
>- if (found || IS_GEN9_BC(dev_priv))
>+ if (found)
> intel_ddi_init(dev_priv, PORT_A);
>
> /* DDI B, C, D, and F detection is indicated by the
>SFUSE_STRAP
>@@ -16046,7 +16040,6 @@ static void intel_setup_outputs(struct
>drm_i915_private *dev_priv)
> if (IS_GEN9_BC(dev_priv) &&
> intel_bios_is_port_present(dev_priv, PORT_E))
> intel_ddi_init(dev_priv, PORT_E);
>-
> } else if (HAS_PCH_SPLIT(dev_priv)) {
> int found;
>
>--
>2.24.0
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/etnaviv: Use dma_resv locking wrappers
>-Original Message-
>From: dri-devel On Behalf Of
>Daniel Vetter
>Sent: Friday, December 13, 2019 3:08 PM
>To: DRI Development
>Cc: Daniel Vetter ; Intel Graphics Development
>; etna...@lists.freedesktop.org; Russell
>King ; Vetter, Daniel
>
>Subject: Re: [PATCH 1/4] drm/etnaviv: Use dma_resv locking wrappers
>
>On Mon, Nov 25, 2019 at 10:43:53AM +0100, Daniel Vetter wrote:
>> I'll add more fancy logic to them soon, so everyone really has to use
>> them. Plus they already provide some nice additional debug
>> infrastructure on top of direct ww_mutex usage for the fences tracked
>> by dma_resv.
>>
>> Signed-off-by: Daniel Vetter
>> Cc: Lucas Stach
>> Cc: Russell King
>> Cc: Christian Gmeiner
>> Cc: etna...@lists.freedesktop.org
>
>Ping for some review/acks.
>
>Thanks, Daniel
>
>> ---
>> drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 8 +++-
>> 1 file changed, 3 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
>b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
>> index aa3e4c3b063a..947b21868e72 100644
>> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
>> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
>> @@ -113,7 +113,7 @@ static void submit_unlock_object(struct
>etnaviv_gem_submit *submit, int i)
>> if (submit->bos[i].flags & BO_LOCKED) {
>> struct drm_gem_object *obj = >bos[i].obj->base;
>>
>> -ww_mutex_unlock(>resv->lock);
>> +dma_resv_unlock(obj->resv);
>> submit->bos[i].flags &= ~BO_LOCKED;
>> }
>> }
>> @@ -133,8 +133,7 @@ static int submit_lock_objects(struct
>etnaviv_gem_submit *submit,
>> contended = i;
>>
>> if (!(submit->bos[i].flags & BO_LOCKED)) {
>> -ret = ww_mutex_lock_interruptible(>resv-
>>lock,
>> - ticket);
>> +ret = dma_resv_lock(obj->resv, ticket);
Should this be dma_resv_lock_interruptible()?
Mike
>> if (ret == -EALREADY)
>> DRM_ERROR("BO at index %u already on
>submit list\n",
>>i);
>> @@ -161,8 +160,7 @@ static int submit_lock_objects(struct
>etnaviv_gem_submit *submit,
>> obj = >bos[contended].obj->base;
>>
>> /* we lost out in a seqno race, lock and retry.. */
>> -ret = ww_mutex_lock_slow_interruptible(>resv->lock,
>> - ticket);
>> +ret = dma_resv_lock_slow_interruptible(obj->resv, ticket);
>> if (!ret) {
>> submit->bos[contended].flags |= BO_LOCKED;
>> slow_locked = contended;
>> --
>> 2.24.0
>>
>
>--
>Daniel Vetter
>Software Engineer, Intel Corporation
>http://blog.ffwll.ch
>___
>dri-devel mailing list
>dri-de...@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [CI] drm/i915: Use a ctor for TYPESAFE_BY_RCU i915_request
>-Original Message- >From: Chris Wilson >Sent: Friday, November 22, 2019 3:50 PM >To: Ruhl, Michael J ; intel- >g...@lists.freedesktop.org >Subject: RE: [Intel-gfx] [CI] drm/i915: Use a ctor for TYPESAFE_BY_RCU >i915_request > >Quoting Ruhl, Michael J (2019-11-22 20:37:59) >> >-Original Message- >> >From: Intel-gfx On Behalf Of >Chris >> >Wilson >> >Sent: Friday, November 22, 2019 2:03 AM >> >To: intel-gfx@lists.freedesktop.org >> >Subject: [Intel-gfx] [CI] drm/i915: Use a ctor for TYPESAFE_BY_RCU >> >i915_request >> > >> >As we start peeking into requests for longer and longer, e.g. >> >incorporating use of spinlocks when only protected by an >> >rcu_read_lock(), we need to be careful in how we reset the request when >> >recycling and need to preserve any barriers that may still be in use as >> >the request is reset for reuse. >> > >> >Quoting Linus Torvalds: >> > >> >> If there is refcounting going on then why use SLAB_TYPESAFE_BY_RCU? >> > >> > .. because the object can be accessed (by RCU) after the refcount has >> > gone down to zero, and the thing has been released. >> > >> > That's the whole and only point of SLAB_TYPESAFE_BY_RCU. >> > >> > That flag basically says: >> > >> > "I may end up accessing this object *after* it has been free'd, >> > because there may be RCU lookups in flight" >> > >> > This has nothing to do with constructors. It's ok if the object gets >> > reused as an object of the same type and does *not* get >> > re-initialized, because we're perfectly fine seeing old stale data. >> > >> > What it guarantees is that the slab isn't shared with any other kind >> > of object, _and_ that the underlying pages are free'd after an RCU >> > quiescent period (so the pages aren't shared with another kind of >> > object either during an RCU walk). >> > >> > And it doesn't necessarily have to have a constructor, because the >> > thing that a RCU walk will care about is >> > >> >(a) guaranteed to be an object that *has* been on some RCU list (so >> >it's not a "new" object) >> > >> >(b) the RCU walk needs to have logic to verify that it's still the >> >*same* object and hasn't been re-used as something else. >> > >> > In contrast, a SLAB_TYPESAFE_BY_RCU memory gets free'd and re-used >> > immediately, but because it gets reused as the same kind of object, >> > the RCU walker can "know" what parts have meaning for re-use, in a way >> > it couidn't if the re-use was random. >> > >> > That said, it *is* subtle, and people should be careful. >> > >> >> So the re-use might initialize the fields lazily, not necessarily using a >> >> ctor. >> > >> > If you have a well-defined refcount, and use "atomic_inc_not_zero()" >> > to guard the speculative RCU access section, and use >> > "atomic_dec_and_test()" in the freeing section, then you should be >> > safe wrt new allocations. >> > >> > If you have a completely new allocation that has "random stale >> > content", you know that it cannot be on the RCU list, so there is no >> > speculative access that can ever see that random content. >> > >> > So the only case you need to worry about is a re-use allocation, and >> > you know that the refcount will start out as zero even if you don't >> > have a constructor. >> > >> > So you can think of the refcount itself as always having a zero >> > constructor, *BUT* you need to be careful with ordering. >> > >> > In particular, whoever does the allocation needs to then set the >> > refcount to a non-zero value *after* it has initialized all the other >> > fields. And in particular, it needs to make sure that it uses the >> > proper memory ordering to do so. >> > >> > NOTE! One thing to be very worried about is that re-initializing >> > whatever RCU lists means that now the RCU walker may be walking on >the >> > wrong list so the walker may do the right thing for this particular >> > entry, but it may miss walking *other* entries. So then you can get >> > spurious lookup failures, because the RCU walker never walked all the >> > way to the end of the right list. That ends up being a much more >
Re: [Intel-gfx] [CI] drm/i915: Use a ctor for TYPESAFE_BY_RCU i915_request
>-Original Message-
>From: Intel-gfx On Behalf Of Chris
>Wilson
>Sent: Friday, November 22, 2019 2:03 AM
>To: intel-gfx@lists.freedesktop.org
>Subject: [Intel-gfx] [CI] drm/i915: Use a ctor for TYPESAFE_BY_RCU
>i915_request
>
>As we start peeking into requests for longer and longer, e.g.
>incorporating use of spinlocks when only protected by an
>rcu_read_lock(), we need to be careful in how we reset the request when
>recycling and need to preserve any barriers that may still be in use as
>the request is reset for reuse.
>
>Quoting Linus Torvalds:
>
>> If there is refcounting going on then why use SLAB_TYPESAFE_BY_RCU?
>
> .. because the object can be accessed (by RCU) after the refcount has
> gone down to zero, and the thing has been released.
>
> That's the whole and only point of SLAB_TYPESAFE_BY_RCU.
>
> That flag basically says:
>
> "I may end up accessing this object *after* it has been free'd,
> because there may be RCU lookups in flight"
>
> This has nothing to do with constructors. It's ok if the object gets
> reused as an object of the same type and does *not* get
> re-initialized, because we're perfectly fine seeing old stale data.
>
> What it guarantees is that the slab isn't shared with any other kind
> of object, _and_ that the underlying pages are free'd after an RCU
> quiescent period (so the pages aren't shared with another kind of
> object either during an RCU walk).
>
> And it doesn't necessarily have to have a constructor, because the
> thing that a RCU walk will care about is
>
>(a) guaranteed to be an object that *has* been on some RCU list (so
>it's not a "new" object)
>
>(b) the RCU walk needs to have logic to verify that it's still the
>*same* object and hasn't been re-used as something else.
>
> In contrast, a SLAB_TYPESAFE_BY_RCU memory gets free'd and re-used
> immediately, but because it gets reused as the same kind of object,
> the RCU walker can "know" what parts have meaning for re-use, in a way
> it couidn't if the re-use was random.
>
> That said, it *is* subtle, and people should be careful.
>
>> So the re-use might initialize the fields lazily, not necessarily using a
>> ctor.
>
> If you have a well-defined refcount, and use "atomic_inc_not_zero()"
> to guard the speculative RCU access section, and use
> "atomic_dec_and_test()" in the freeing section, then you should be
> safe wrt new allocations.
>
> If you have a completely new allocation that has "random stale
> content", you know that it cannot be on the RCU list, so there is no
> speculative access that can ever see that random content.
>
> So the only case you need to worry about is a re-use allocation, and
> you know that the refcount will start out as zero even if you don't
> have a constructor.
>
> So you can think of the refcount itself as always having a zero
> constructor, *BUT* you need to be careful with ordering.
>
> In particular, whoever does the allocation needs to then set the
> refcount to a non-zero value *after* it has initialized all the other
> fields. And in particular, it needs to make sure that it uses the
> proper memory ordering to do so.
>
> NOTE! One thing to be very worried about is that re-initializing
> whatever RCU lists means that now the RCU walker may be walking on the
> wrong list so the walker may do the right thing for this particular
> entry, but it may miss walking *other* entries. So then you can get
> spurious lookup failures, because the RCU walker never walked all the
> way to the end of the right list. That ends up being a much more
> subtle bug.
>
>Signed-off-by: Chris Wilson
>Cc: Tvrtko Ursulin
>---
> drivers/gpu/drm/i915/i915_request.c | 49 ++-
> drivers/gpu/drm/i915/i915_scheduler.c | 6
> drivers/gpu/drm/i915/i915_scheduler.h | 1 +
> drivers/gpu/drm/i915/i915_sw_fence.c | 8 +
> drivers/gpu/drm/i915/i915_sw_fence.h | 2 ++
> 5 files changed, 50 insertions(+), 16 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/i915_request.c
>b/drivers/gpu/drm/i915/i915_request.c
>index 00011f9533b6..a558f64186fa 100644
>--- a/drivers/gpu/drm/i915/i915_request.c
>+++ b/drivers/gpu/drm/i915/i915_request.c
>@@ -188,7 +188,7 @@ static void free_capture_list(struct i915_request
>*request)
> {
> struct i915_capture_list *capture;
>
>- capture = request->capture_list;
>+ capture = fetch_and_zero(>capture_list);
> while (capture) {
> struct i915_capture_list *next = capture->next;
>
>@@ -214,7 +214,7 @@ static void remove_from_engine(struct i915_request
>*rq)
> spin_lock(>active.lock);
> locked = engine;
> }
>- list_del(>sched.link);
>+ list_del_init(>sched.link);
> spin_unlock_irq(>active.lock);
> }
>
>@@ -586,6 +586,21 @@ request_alloc_slow(struct intel_timeline *tl, gfp_t
>gfp)
> return kmem_cache_alloc(global.slab_requests, gfp);
> }
>
>+static void __i915_request_ctor(void *arg)
>+{
>+
Re: [Intel-gfx] [PATCH 2/2] drm: share address space for dma bufs
>-Original Message-
>From: Intel-gfx On Behalf Of Gerd
>Hoffmann
>Sent: Thursday, November 21, 2019 5:38 AM
>To: dri-de...@lists.freedesktop.org
>Cc: David Airlie ; intel-gfx@lists.freedesktop.org; open list
>; Maxime Ripard ; Gerd
>Hoffmann
>Subject: [Intel-gfx] [PATCH 2/2] drm: share address space for dma bufs
>
>Use the shared address space of the drm device (see drm_open() in
>drm_file.c) for dma-bufs too. That removes a difference betweem drm
>device mmap vmas and dma-buf mmap vmas and fixes corner cases like
>unmaps not working properly.
Hi Gerd,
Just want to make sure I understand this...
So unmaps will not work correctly for mappings when a driver does a
drm_vma_node_unamp()?
I.e. the dmabuf mappings will not get cleaned up correctly?
This is a day one bug?
Thanks,
Mike
>Signed-off-by: Gerd Hoffmann
>---
> drivers/gpu/drm/drm_prime.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
>index a9633bd241bb..c3fc341453c0 100644
>--- a/drivers/gpu/drm/drm_prime.c
>+++ b/drivers/gpu/drm/drm_prime.c
>@@ -240,6 +240,7 @@ void drm_prime_destroy_file_private(struct
>drm_prime_file_private *prime_fpriv)
> struct dma_buf *drm_gem_dmabuf_export(struct drm_device *dev,
> struct dma_buf_export_info *exp_info)
> {
>+ struct drm_gem_object *obj = exp_info->priv;
> struct dma_buf *dma_buf;
>
> dma_buf = dma_buf_export(exp_info);
>@@ -247,7 +248,8 @@ struct dma_buf *drm_gem_dmabuf_export(struct
>drm_device *dev,
> return dma_buf;
>
> drm_dev_get(dev);
>- drm_gem_object_get(exp_info->priv);
>+ drm_gem_object_get(obj);
>+ dma_buf->file->f_mapping = obj->dev->anon_inode->i_mapping;
>
> return dma_buf;
> }
>--
>2.18.1
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Switch obj->mm.lock lockdep annotations on its head
Just some nits/typos that made this a little difficult for me to read. I am still trying to understand what is going on, so unfortunately I have no comments on the patch. >-Original Message- >From: Intel-gfx On Behalf Of >Daniel Vetter >Sent: Tuesday, November 5, 2019 4:02 AM >To: Intel Graphics Development >Cc: Daniel Vetter ; Auld, Matthew >; Vetter, Daniel >Subject: [Intel-gfx] [PATCH] drm/i915: Switch obj->mm.lock lockdep >annotations on its head > >The trouble with having a plain nesting flag for locks which do not >naturally nest (unlike block devices and their partitions, which is >the original motivation for nesting levels) is that lockdep will >never spot a true deadlock if you screw up. > >This patch is an attempt at trying better, by highlighting a bit more "a bit more of the" >the actual nature of the nesting that's going on. Essentially we have >two kinds of objects: > >- objects without pages allocated, which cannot be on any lru and are > hence inaccessible to the shrinker. > >- objects which have pages allocated, which are on an lru, and which > the shrinker can decide to throw out. > >For the former type of object, memory allcoations while holding s/allcoations/allocations >obj->mm.lock are permissible. For the latter they are not. And >get/put_pages transitions between the two types of objects. I am not sure what the sentence, "And get/put_page transitions between the two types of objects." means. Can you clarify? > >This is still not entirely fool-proof since the rules might chance. s/chance/change/ >But as long as we run such a code ever at runtime lockdep should be >able to observe the inconsistency and complain (like with any other I am having difficulty with "But as long as we run such a code ever at". Should this be, "With this code, runtime lockdep should be able to..."? >lockdep class that we've split up in multiple classes). But there are >a few clear benefits: > >- We can drop the nesting flag parameter from > __i915_gem_object_put_pages, because that function by definition is > never going allocate memory, and calling it on an object which > doesn't have its pages allocated would be a bug. > >- We strictly catch more bugs, since there's not only one place in the > entire tree which is annotated with the special class. All the > other places that had explicit lockdep nesting annotations we're now > going to leave up to lockdep again. > >- Specifically this catches stuff like calling get_pages from > put_pages (which isn't really a good idea, if we can call get_pages > so could the shrinker). I've seen patches do exactly that. > >Of course I fully expect CI will show me for the fool I am with this >one here :-) > >v2: There can only be one (lockdep only has a cache for the first >subclass, not for deeper ones, and we don't want to make these locks >even slower). Still separate enums for better documentation. > >Real fix: don forget about phys objs and pin_map(), and fix the s/don/don't/ Thanks, Mike >shrinker to have the right annotations ... silly me. > >v3: Forgot usertptr too ... > >v4: Improve comment for pages_pin_count, drop the IMPORTANT comment >and instead prime lockdep (Chris). > >v5: Appease checkpatch, no double empty lines (Chris) > >v6: More rebasing over selftest changes. Also somehow I forgot to >push this patch :-/ > >Also format comments consistently while at it. > >v7: Fix typo in commit message (Joonas) > >Also drop the priming, with the lmem merge we now have allocations >while holding the lmem lock, which wreaks the generic priming I've >done in earlier patches. Should probably be resurrected when lmem is >fixed. See > >commit 232a6ebae419193f5b8da4fa869ae5089ab105c2 >Author: Matthew Auld >Date: Tue Oct 8 17:01:14 2019 +0100 > >drm/i915: introduce intel_memory_region > >I'm keeping the priming patch locally so it wont get lost. > >Cc: Matthew Auld >Cc: Chris Wilson >Cc: "Tang, CQ" >Cc: Tvrtko Ursulin >Cc: Joonas Lahtinen >Reviewed-by: Chris Wilson (v5) >Reviewed-by: Joonas Lahtinen (v6) >Signed-off-by: Daniel Vetter >--- > drivers/gpu/drm/i915/gem/i915_gem_object.c | 4 +++- > drivers/gpu/drm/i915/gem/i915_gem_object.h | 17 ++--- > .../gpu/drm/i915/gem/i915_gem_object_types.h| 6 +- > drivers/gpu/drm/i915/gem/i915_gem_pages.c | 9 - > drivers/gpu/drm/i915/gem/i915_gem_phys.c| 2 +- > drivers/gpu/drm/i915/gem/i915_gem_shrinker.c| 5 ++--- > drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 4 ++-- > drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 14 +++--- > .../drm/i915/selftests/intel_memory_region.c| 4 ++-- > 9 files changed, 40 insertions(+), 25 deletions(-) > >diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c >b/drivers/gpu/drm/i915/gem/i915_gem_object.c >index a50296cce0d8..db103d3c8760 100644 >--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c >+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c >@@ -22,6 +22,8 @@ > * > */
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Plump dev_priv all the way to icl_{hdr, sdr_y}_plane_mask()
Minor nit.
s/Plump/Plumb/
M
>-Original Message-
>From: Intel-gfx On Behalf Of Ville
>Syrjala
>Sent: Thursday, October 31, 2019 6:59 AM
>To: intel-gfx@lists.freedesktop.org
>Subject: [Intel-gfx] [PATCH 4/4] drm/i915: Plump dev_priv all the way to
>icl_{hdr, sdr_y}_plane_mask()
>
>From: Ville Syrjälä
>
>We're going to need platforms specific decisions in
>icl_sdr_y_plane_mask(), so let's plumb dev_priv all the way
>down. For consistency we'll do the same for icl_hdr_plane_mask().
>
>Signed-off-by: Ville Syrjälä
>---
> drivers/gpu/drm/i915/display/intel_display.c | 4 ++--
> drivers/gpu/drm/i915/display/intel_sprite.c | 4 ++--
> drivers/gpu/drm/i915/display/intel_sprite.h | 24
> 3 files changed, 19 insertions(+), 13 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/display/intel_display.c
>b/drivers/gpu/drm/i915/display/intel_display.c
>index 8e1160f8d988..b690ea26cc89 100644
>--- a/drivers/gpu/drm/i915/display/intel_display.c
>+++ b/drivers/gpu/drm/i915/display/intel_display.c
>@@ -9613,7 +9613,7 @@ static void bdw_set_pipemisc(const struct
>intel_crtc_state *crtc_state)
> PIPEMISC_YUV420_MODE_FULL_BLEND;
>
> if (INTEL_GEN(dev_priv) >= 11 &&
>- (crtc_state->active_planes & ~(icl_hdr_plane_mask() |
>+ (crtc_state->active_planes & ~(icl_hdr_plane_mask(dev_priv) |
> BIT(PLANE_CURSOR))) == 0)
> val |= PIPEMISC_HDR_MODE_PRECISION;
>
>@@ -11955,7 +11955,7 @@ static int icl_check_nv12_planes(struct
>intel_crtc_state *crtc_state)
> continue;
>
> for_each_intel_plane_on_crtc(_priv->drm, crtc, linked) {
>- if (!icl_is_sdr_y_plane(linked->id))
>+ if (!icl_is_sdr_y_plane(dev_priv, linked->id))
> continue;
>
> if (crtc_state->active_planes & BIT(linked->id))
>diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
>b/drivers/gpu/drm/i915/display/intel_sprite.c
>index ba344d9e2e19..b486287b9fb1 100644
>--- a/drivers/gpu/drm/i915/display/intel_sprite.c
>+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
>@@ -2849,7 +2849,7 @@ static const u32 *icl_get_plane_formats(struct
>drm_i915_private *dev_priv,
> if (icl_is_hdr_plane(dev_priv, plane_id)) {
> *num_formats = ARRAY_SIZE(icl_hdr_plane_formats);
> return icl_hdr_plane_formats;
>- } else if (icl_is_sdr_y_plane(plane_id)) {
>+ } else if (icl_is_sdr_y_plane(dev_priv, plane_id)) {
> *num_formats = ARRAY_SIZE(icl_sdr_y_plane_formats);
> return icl_sdr_y_plane_formats;
> } else {
>@@ -2910,7 +2910,7 @@ skl_universal_plane_create(struct drm_i915_private
>*dev_priv,
> plane->get_hw_state = skl_plane_get_hw_state;
> plane->check_plane = skl_plane_check;
> plane->min_cdclk = skl_plane_min_cdclk;
>- if (icl_is_sdr_y_plane(plane_id))
>+ if (icl_is_sdr_y_plane(dev_priv, plane_id))
> plane->update_slave = icl_update_slave;
>
> if (INTEL_GEN(dev_priv) >= 11)
>diff --git a/drivers/gpu/drm/i915/display/intel_sprite.h
>b/drivers/gpu/drm/i915/display/intel_sprite.h
>index ffb03ee640ed..d9efac5e157f 100644
>--- a/drivers/gpu/drm/i915/display/intel_sprite.h
>+++ b/drivers/gpu/drm/i915/display/intel_sprite.h
>@@ -32,27 +32,33 @@ struct intel_plane *
> skl_universal_plane_create(struct drm_i915_private *dev_priv,
> enum pipe pipe, enum plane_id plane_id);
>
>-static inline u8 icl_sdr_y_plane_mask(void)
>+static inline u8 icl_sdr_y_plane_mask(struct drm_i915_private *dev_priv)
> {
>- return BIT(PLANE_SPRITE4) | BIT(PLANE_SPRITE5);
>+ if (INTEL_GEN(dev_priv) >= 11)
>+ return BIT(PLANE_SPRITE4) | BIT(PLANE_SPRITE5);
>+ else
>+ return 0;
> }
>
>-static inline bool icl_is_sdr_y_plane(enum plane_id id)
>+static inline bool icl_is_sdr_y_plane(struct drm_i915_private *dev_priv,
>+enum plane_id plane_id)
> {
>- return icl_sdr_y_plane_mask() & BIT(id);
>+ return icl_sdr_y_plane_mask(dev_priv) & BIT(plane_id);
> }
>
>-static inline u8 icl_hdr_plane_mask(void)
>+static inline u8 icl_hdr_plane_mask(struct drm_i915_private *dev_priv)
> {
>- return BIT(PLANE_PRIMARY) |
>- BIT(PLANE_SPRITE0) | BIT(PLANE_SPRITE1);
>+ if (INTEL_GEN(dev_priv) >= 11)
>+ return BIT(PLANE_PRIMARY) |
>+ BIT(PLANE_SPRITE0) | BIT(PLANE_SPRITE1);
>+ else
>+ return 0;
> }
>
> static inline bool icl_is_hdr_plane(struct drm_i915_private *dev_priv,
> enum plane_id plane_id)
> {
>- return INTEL_GEN(dev_priv) >= 11 &&
>- icl_hdr_plane_mask() & BIT(plane_id);
>+ return icl_hdr_plane_mask(dev_priv) & BIT(plane_id);
> }
>
> int ivb_plane_min_cdclk(const struct intel_crtc_state *crtc_state,
>--
>2.23.0
>
Re: [Intel-gfx] [PATCH 8/8] drm/print: introduce new struct drm_device based logging macros
>-Original Message- >From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of >Jani Nikula >Sent: Wednesday, October 9, 2019 11:38 AM >To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org >Cc: Nikula, Jani ; Sam Ravnborg >Subject: [Intel-gfx] [PATCH 8/8] drm/print: introduce new struct drm_device >based logging macros > >Add new struct drm_device based logging macros modeled after the core >kernel device based logging macros. These would be preferred over the >drm printk and struct device based macros in drm code, where possible. > >We have existing drm specific struct device based logging functions, but >they are too verbose to use for two main reasons: > > * The names are unnecessarily long, for example DRM_DEV_DEBUG_KMS(). > > * The use of struct device over struct drm_device is too generic for > most users, leading to an extra dereference. > >For example: > > DRM_DEV_DEBUG_KMS(drm->dev, "Hello, world\n"); > >vs. > > drm_dbg_kms(drm, "Hello, world\n"); > >It's a matter of taste, but the SHOUTING UPPERCASE has been argued to be >less readable than lowercase. > >Some names are changed from old DRM names to be based on the core >kernel >logging functions. For example, NOTE -> notice, ERROR -> err, DEBUG -> >dbg. > >Due to the conflation of DRM_DEBUG and DRM_DEBUG_DRIVER macro use >(DRM_DEBUG is used widely in drivers though it's supposed to be a core >debugging category), they are named as drm_dbg_core and drm_dbg, >respectively. > >The drm_err and _once/_ratelimited variants no longer include the >function name in order to be able to use the core device based logging >macros. Arguably this is not a significant change; error messages should >not be so common to be only distinguishable by the function name. > >Ratelimited debug logging macros are to be added later. > >Cc: Sam Ravnborg >Signed-off-by: Jani Nikula > >--- > >With something like this, I think i915 could start migrating to >drm_device based logging. I have a hard time convincing myself or anyone >about migrating to the DRM_DEV_* variants. >--- > include/drm/drm_print.h | 65 >+ > 1 file changed, 65 insertions(+) > >diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h >index 085a9685270c..e4040dea0d8c 100644 >--- a/include/drm/drm_print.h >+++ b/include/drm/drm_print.h >@@ -322,6 +322,8 @@ static inline bool drm_debug_enabled(enum >drm_debug_category category) > > /* > * struct device based logging >+ * >+ * Prefer drm_device based logging over device or prink based logging. > */ > > __printf(3, 4) >@@ -417,8 +419,71 @@ void drm_dev_dbg(const struct device *dev, enum >drm_debug_category category, > _DRM_DEV_DEFINE_DEBUG_RATELIMITED(dev, DRM_UT_PRIME, > \ > fmt, ##__VA_ARGS__) > >+/* >+ * struct drm_device based logging >+ * >+ * Prefer drm_device based logging over device or prink based logging. >+ */ >+ >+/* Helper for struct drm_device based logging. */ >+#define __drm_printk(drm, level, type, fmt, ...) \ >+ dev_##level##type(drm->dev, "[drm] " fmt, ##__VA_ARGS__) In the past, I have been able to do a: #undef pr_fmt #define pr_fmt(fmt) "[myinfo here] " fmt And have the "[myinfo here]" portion show up the output. Is it possible that you might be able to use this instead of "[drm] " fmt? I think that the this will be the same result, but might be more in line with the printk interface? Mike >+ >+ >+#define drm_info(drm, fmt, ...) \ >+ __drm_printk(drm, info,, fmt, ##__VA_ARGS__) >+ >+#define drm_notice(drm, fmt, ...) \ >+ __drm_printk(drm, notice,, fmt, ##__VA_ARGS__) >+ >+#define drm_warn(drm, fmt, ...) \ >+ __drm_printk(drm, warn,, fmt, ##__VA_ARGS__) >+ >+#define drm_err(drm, fmt, ...)\ >+ __drm_printk(drm, err,, "*ERROR* " fmt, ##__VA_ARGS__) >+ >+ >+#define drm_info_once(drm, fmt, ...) \ >+ __drm_printk(drm, info, _once, fmt, ##__VA_ARGS__) >+ >+#define drm_notice_once(drm, fmt, ...)\ >+ __drm_printk(drm, notice, _once, fmt, ##__VA_ARGS__) >+ >+#define drm_warn_once(drm, fmt, ...) \ >+ __drm_printk(drm, warn, _once, fmt, ##__VA_ARGS__) >+ >+#define drm_err_once(drm, fmt, ...) \ >+ __drm_printk(drm, err, _once, "*ERROR* " fmt, ##__VA_ARGS__) >+ >+ >+#define drm_err_ratelimited(drm, fmt, ...)\ >+ __drm_printk(drm, err, _ratelimited, "*ERROR* " fmt, >##__VA_ARGS__) >+ >+ >+#define drm_dbg_core(drm, fmt, ...) \ >+ drm_dev_dbg(drm->dev, DRM_UT_CORE, fmt, ##__VA_ARGS__) >+#define drm_dbg(drm, fmt, ...) > \ >+ drm_dev_dbg(drm->dev, DRM_UT_DRIVER, fmt, ##__VA_ARGS__) >+#define
Re: [Intel-gfx] [PATCH v3] dma-fence: Serialise signal enabling (dma_fence_enable_sw_signaling)
>-Original Message-
>From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
>Sent: Thursday, October 3, 2019 10:19 AM
>To: Ruhl, Michael J ; intel-
>g...@lists.freedesktop.org
>Cc: dri-de...@lists.freedesktop.org
>Subject: RE: [Intel-gfx] [PATCH v3] dma-fence: Serialise signal enabling
>(dma_fence_enable_sw_signaling)
>
>Quoting Ruhl, Michael J (2019-10-03 15:12:38)
>> >-Original Message-
>> >From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
>Of
>> >Chris Wilson
>> >Sent: Thursday, October 3, 2019 9:24 AM
>> >To: intel-gfx@lists.freedesktop.org
>> >Cc: dri-de...@lists.freedesktop.org
>> >Subject: [Intel-gfx] [PATCH v3] dma-fence: Serialise signal enabling
>> >(dma_fence_enable_sw_signaling)
>> >
>> >Make dma_fence_enable_sw_signaling() behave like its
>> >dma_fence_add_callback() and dma_fence_default_wait() counterparts
>and
>> >perform the test to enable signaling under the fence->lock, along with
>> >the action to do so. This ensure that should an implementation be trying
>> >to flush the cb_list (by signaling) on retirement before freeing the
>> >fence, it can do so in a race-free manner.
>> >
>> >See also 0fc89b6802ba ("dma-fence: Simply wrap
>dma_fence_signal_locked
>> >with dma_fence_signal").
>> >
>> >v2: Refactor all 3 enable_signaling paths to use a common function.
>> >
>> >Signed-off-by: Chris Wilson
>> >---
>> >Return false for "could not _enable_ signaling as it was already
>> >signaled"
>> >---
>> > drivers/dma-buf/dma-fence.c | 78 +
>> > 1 file changed, 35 insertions(+), 43 deletions(-)
>> >
>> >diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
>> >index 2c136aee3e79..b58528c1cc9d 100644
>> >--- a/drivers/dma-buf/dma-fence.c
>> >+++ b/drivers/dma-buf/dma-fence.c
>> >@@ -273,6 +273,30 @@ void dma_fence_free(struct dma_fence *fence)
>> > }
>> > EXPORT_SYMBOL(dma_fence_free);
>> >
>> >+static bool __dma_fence_enable_signaling(struct dma_fence *fence)
>> >+{
>> >+ bool was_set;
>> >+
>> >+ lockdep_assert_held(fence->lock);
>>
>> With this held...
>>
>> >+ was_set =
>> >test_and_set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
>> >+ >flags);
>> >+
>> >+ if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags))
>> >+ return false;
>>
>> Would making these the non-atomic versions be useful (and/or
>reasonable)?
>
>That depends on all modifications to the dword (not just the bit) being
>serialised by the same lock (or otherwise guaranteed to be serial and
>coherent), which as Tvrtko rediscovered is not the case. dma_fence.flags
>is also home to a number of user flags.
Ah got it.
In the future, I will think a bit outside the patch. (sorry for the pun...)
Thanks,
Mike
>-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] dma-fence: Serialise signal enabling (dma_fence_enable_sw_signaling)
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Chris Wilson
>Sent: Thursday, October 3, 2019 9:24 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: dri-de...@lists.freedesktop.org
>Subject: [Intel-gfx] [PATCH v3] dma-fence: Serialise signal enabling
>(dma_fence_enable_sw_signaling)
>
>Make dma_fence_enable_sw_signaling() behave like its
>dma_fence_add_callback() and dma_fence_default_wait() counterparts and
>perform the test to enable signaling under the fence->lock, along with
>the action to do so. This ensure that should an implementation be trying
>to flush the cb_list (by signaling) on retirement before freeing the
>fence, it can do so in a race-free manner.
>
>See also 0fc89b6802ba ("dma-fence: Simply wrap dma_fence_signal_locked
>with dma_fence_signal").
>
>v2: Refactor all 3 enable_signaling paths to use a common function.
>
>Signed-off-by: Chris Wilson
>---
>Return false for "could not _enable_ signaling as it was already
>signaled"
>---
> drivers/dma-buf/dma-fence.c | 78 +
> 1 file changed, 35 insertions(+), 43 deletions(-)
>
>diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
>index 2c136aee3e79..b58528c1cc9d 100644
>--- a/drivers/dma-buf/dma-fence.c
>+++ b/drivers/dma-buf/dma-fence.c
>@@ -273,6 +273,30 @@ void dma_fence_free(struct dma_fence *fence)
> }
> EXPORT_SYMBOL(dma_fence_free);
>
>+static bool __dma_fence_enable_signaling(struct dma_fence *fence)
>+{
>+ bool was_set;
>+
>+ lockdep_assert_held(fence->lock);
With this held...
>+ was_set =
>test_and_set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
>+ >flags);
>+
>+ if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags))
>+ return false;
Would making these the non-atomic versions be useful (and/or reasonable)?
Mike
>+
>+ if (!was_set && fence->ops->enable_signaling) {
>+ if (!fence->ops->enable_signaling(fence)) {
>+ dma_fence_signal_locked(fence);
>+ return false;
>+ }
>+
>+ trace_dma_fence_enable_signal(fence);
>+ }
>+
>+ return true;
>+}
>+
> /**
> * dma_fence_enable_sw_signaling - enable signaling on fence
> * @fence: the fence to enable
>@@ -285,19 +309,12 @@ void dma_fence_enable_sw_signaling(struct
>dma_fence *fence)
> {
> unsigned long flags;
>
>- if (!test_and_set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
>->flags) &&
>- !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags) &&
>- fence->ops->enable_signaling) {
>- trace_dma_fence_enable_signal(fence);
>-
>- spin_lock_irqsave(fence->lock, flags);
>-
>- if (!fence->ops->enable_signaling(fence))
>- dma_fence_signal_locked(fence);
>+ if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags))
>+ return;
>
>- spin_unlock_irqrestore(fence->lock, flags);
>- }
>+ spin_lock_irqsave(fence->lock, flags);
>+ __dma_fence_enable_signaling(fence);
>+ spin_unlock_irqrestore(fence->lock, flags);
> }
> EXPORT_SYMBOL(dma_fence_enable_sw_signaling);
>
>@@ -331,7 +348,6 @@ int dma_fence_add_callback(struct dma_fence
>*fence, struct dma_fence_cb *cb,
> {
> unsigned long flags;
> int ret = 0;
>- bool was_set;
>
> if (WARN_ON(!fence || !func))
> return -EINVAL;
>@@ -343,25 +359,14 @@ int dma_fence_add_callback(struct dma_fence
>*fence, struct dma_fence_cb *cb,
>
> spin_lock_irqsave(fence->lock, flags);
>
>- was_set =
>test_and_set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
>- >flags);
>-
>- if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags))
>- ret = -ENOENT;
>- else if (!was_set && fence->ops->enable_signaling) {
>- trace_dma_fence_enable_signal(fence);
>-
>- if (!fence->ops->enable_signaling(fence)) {
>- dma_fence_signal_locked(fence);
>- ret = -ENOENT;
>- }
>- }
>-
>- if (!ret) {
>+ if (__dma_fence_enable_signaling(fence)) {
> cb->func = func;
> list_add_tail(>node, >cb_list);
>- } else
>+ } else {
> INIT_LIST_HEAD(>node);
>+ ret = -ENOENT;
>+ }
>+
> spin_unlock_irqrestore(fence->lock, flags);
>
> return ret;
>@@ -461,7 +466,6 @@ dma_fence_default_wait(struct dma_fence *fence,
>bool intr, signed long timeout)
> struct default_wait_cb cb;
> unsigned long flags;
> signed long ret = timeout ? timeout : 1;
>- bool was_set;
>
> if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags))
> return ret;
>@@ -473,21 +477,9 @@ dma_fence_default_wait(struct dma_fence *fence,
>bool intr, signed long timeout)
> goto out;
> }
>
>- was_set =
Re: [Intel-gfx] [PATCH 2/2] drm/mm: Pack allocated/scanned boolean into a bitfield
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
>Of Chris Wilson
>Sent: Thursday, October 3, 2019 3:08 AM
>To: Ruhl, Michael J ; dri-
>de...@lists.freedesktop.org
>Cc: intel-gfx@lists.freedesktop.org
>Subject: RE: [PATCH 2/2] drm/mm: Pack allocated/scanned boolean into a
>bitfield
>
>Quoting Ruhl, Michael J (2019-09-16 20:45:14)
>> >-Original Message-
>> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On
>Behalf
>> >Of Chris Wilson
>> >Sent: Sunday, September 15, 2019 2:46 PM
>> >@@ -424,9 +424,9 @@ int drm_mm_reserve_node(struct drm_mm *mm,
>> >struct drm_mm_node *node)
>> >
>> > node->mm = mm;
>> >
>> >+ __set_bit(DRM_MM_NODE_ALLOCATED_BIT, >flags);
>>
>> Maybe a silly question(s), but you appear to be mixing atomic bit ops
>> (clear_ and test_) with non-atomic bit ops __xxx_bit().
>>
>> Should that be a concern? Should that be mention in the commit?
>
>Generally yes, but this is inside an allocation function so the new node
>cannot be accessed concurrently yet (and manipulation of the drm_mm
>itself requires external serialisation).
Got it.
Thanks for the clarification.
Mike
>The concern is with blocks like
>
>> >diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c
>b/drivers/gpu/drm/vc4/vc4_crtc.c
>> >index f1f0a7c87771..b00e20f5ce05 100644
>> >--- a/drivers/gpu/drm/vc4/vc4_crtc.c
>> >+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
>> >@@ -994,7 +994,7 @@ static void vc4_crtc_destroy_state(struct drm_crtc
>> >*crtc,
>> > struct vc4_dev *vc4 = to_vc4_dev(crtc->dev);
>> > struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(state);
>> >
>> >- if (vc4_state->mm.allocated) {
>> >+ if (drm_mm_node_allocated(_state->mm)) {
>> > unsigned long flags;
>> >
>> > spin_lock_irqsave(>hvs->mm_lock, flags);
>
>where we are testing the bit prior to taking the lock to serialise
>removal before free. To avoid the cost of serialising here we have to be
>sure that any other thread has completely stopped using the drm_mm_node
>when it is marked as released.
>-Chris
>___
>dri-devel mailing list
>dri-de...@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Make is_signed_type() simpler
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Alexey Dobriyan
>Sent: Sunday, September 29, 2019 4:06 PM
>To: a...@linux-foundation.org
>Cc: intel-gfx@lists.freedesktop.org; li...@rasmusvillemoes.dk; linux-
>ker...@vger.kernel.org; rost...@goodmis.org; mi...@redhat.com
>Subject: [Intel-gfx] [PATCH] Make is_signed_type() simpler
>
>* Simply compare -1 with 0,
>* Drop unnecessary parenthesis sets
>
>New macro leaves pointer as "unsigned type" but gives a warning,
>which should be fine because asking whether a pointer is signed is
>strange question.
>
>I'm not sure what's going on in the i915 driver, it is shipping kernel
>pointers to userspace.
>
>Signed-off-by: Alexey Dobriyan
>---
>
> drivers/gpu/drm/i915/i915_trace.h | 86 +++--
>-
> include/linux/overflow.h |2
> include/linux/trace_events.h |2
> tools/include/linux/overflow.h|2
> 4 files changed, 46 insertions(+), 46 deletions(-)
>
>--- a/drivers/gpu/drm/i915/i915_trace.h
>+++ b/drivers/gpu/drm/i915/i915_trace.h
>@@ -419,16 +419,16 @@ TRACE_EVENT(i915_gem_object_create,
> TP_ARGS(obj),
>
> TP_STRUCT__entry(
>- __field(struct drm_i915_gem_object *, obj)
>+ __field(unsigned long, obj)
>__field(u64, size)
>),
>
> TP_fast_assign(
>- __entry->obj = obj;
>+ __entry->obj = (unsigned long)obj;
> __entry->size = obj->base.size;
> ),
>
>- TP_printk("obj=%p, size=0x%llx", __entry->obj, __entry->size)
>+ TP_printk("obj=%p, size=0x%llx", (void *)__entry->obj, __entry-
Looking up the printk format specifiers, I see:
%p
Pointers printed without a specifier extension (i.e unadorned %p) are
hashed to give a unique identifier without leaking kernel addresses to user
space.
This would seem to me that we this code is correct. Am I misreading this?
Mike
>>size)
> );
>
> TRACE_EVENT(i915_gem_shrink,
>@@ -456,25 +456,25 @@ TRACE_EVENT(i915_vma_bind,
> TP_ARGS(vma, flags),
>
> TP_STRUCT__entry(
>- __field(struct drm_i915_gem_object *, obj)
>- __field(struct i915_address_space *, vm)
>+ __field(unsigned long, obj)
>+ __field(unsigned long, vm)
>__field(u64, offset)
>__field(u64, size)
>__field(unsigned, flags)
>),
>
> TP_fast_assign(
>- __entry->obj = vma->obj;
>- __entry->vm = vma->vm;
>+ __entry->obj = (unsigned long)vma->obj;
>+ __entry->vm = (unsigned long)vma->vm;
> __entry->offset = vma->node.start;
> __entry->size = vma->node.size;
> __entry->flags = flags;
> ),
>
> TP_printk("obj=%p, offset=0x%016llx size=0x%llx%s vm=%p",
>-__entry->obj, __entry->offset, __entry->size,
>+(void *)__entry->obj, __entry->offset, __entry->size,
> __entry->flags & PIN_MAPPABLE ? ", mappable" : "",
>-__entry->vm)
>+(void *)__entry->vm)
> );
>
> TRACE_EVENT(i915_vma_unbind,
>@@ -482,21 +482,21 @@ TRACE_EVENT(i915_vma_unbind,
> TP_ARGS(vma),
>
> TP_STRUCT__entry(
>- __field(struct drm_i915_gem_object *, obj)
>- __field(struct i915_address_space *, vm)
>+ __field(unsigned long, obj)
>+ __field(unsigned long, vm)
>__field(u64, offset)
>__field(u64, size)
>),
>
> TP_fast_assign(
>- __entry->obj = vma->obj;
>- __entry->vm = vma->vm;
>+ __entry->obj = (unsigned long)vma->obj;
>+ __entry->vm = (unsigned long)vma->vm;
> __entry->offset = vma->node.start;
> __entry->size = vma->node.size;
> ),
>
> TP_printk("obj=%p, offset=0x%016llx size=0x%llx vm=%p",
>-__entry->obj, __entry->offset, __entry->size, __entry-
>>vm)
>+(void *)__entry->obj, __entry->offset, __entry->size,
>(void *)__entry->vm)
> );
>
> TRACE_EVENT(i915_gem_object_pwrite,
>@@ -504,19 +504,19 @@ TRACE_EVENT(i915_gem_object_pwrite,
> TP_ARGS(obj, offset, len),
>
> TP_STRUCT__entry(
>- __field(struct drm_i915_gem_object *, obj)
>+
Re: [Intel-gfx] [PATCH 04/22] drm/i915/region: support continuous allocations
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Matthew Auld
>Sent: Friday, September 27, 2019 1:34 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: daniel.vet...@ffwll.ch
>Subject: [Intel-gfx] [PATCH 04/22] drm/i915/region: support continuous
>allocations
>
>Some kernel internal objects may need to be allocated as a continuous
Nit:
You refer to the "continuous block", but the then you create the "CONTIGUOUS"
allocations.
s/continuous/contiguous?
Mike
>block, also thinking ahead the various kernel io_mapping interfaces seem
>to expect it, although this is purely a limitation in the kernel
>API...so perhaps something to be improved.
>
>Signed-off-by: Matthew Auld
>Cc: Joonas Lahtinen
>Cc: Abdiel Janulgue
>---
> .../gpu/drm/i915/gem/i915_gem_object_types.h | 4 +
> drivers/gpu/drm/i915/gem/i915_gem_region.c| 15 +-
> drivers/gpu/drm/i915/gem/i915_gem_region.h| 3 +-
> .../gpu/drm/i915/gem/selftests/huge_pages.c | 3 +-
> drivers/gpu/drm/i915/intel_memory_region.c| 13 +-
> drivers/gpu/drm/i915/intel_memory_region.h| 3 +-
> .../drm/i915/selftests/intel_memory_region.c | 163 ++
> drivers/gpu/drm/i915/selftests/mock_region.c | 2 +-
> 8 files changed, 197 insertions(+), 9 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
>b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
>index d36c860c9c6f..7acd383f174f 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
>@@ -117,6 +117,10 @@ struct drm_i915_gem_object {
>
> I915_SELFTEST_DECLARE(struct list_head st_link);
>
>+ unsigned long flags;
>+#define I915_BO_ALLOC_CONTIGUOUS BIT(0)
>+#define I915_BO_ALLOC_FLAGS (I915_BO_ALLOC_CONTIGUOUS)
>+
> /*
>* Is the object to be mapped as read-only to the GPU
>* Only honoured if hardware has relevant pte bit
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.c
>b/drivers/gpu/drm/i915/gem/i915_gem_region.c
>index 5c3bfc121921..b317a5c84144 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_region.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_region.c
>@@ -23,10 +23,10 @@ i915_gem_object_get_pages_buddy(struct
>drm_i915_gem_object *obj)
> {
> struct intel_memory_region *mem = obj->mm.region;
> struct list_head *blocks = >mm.blocks;
>- unsigned int flags = I915_ALLOC_MIN_PAGE_SIZE;
> resource_size_t size = obj->base.size;
> resource_size_t prev_end;
> struct i915_buddy_block *block;
>+ unsigned int flags;
> struct sg_table *st;
> struct scatterlist *sg;
> unsigned int sg_page_sizes;
>@@ -42,6 +42,10 @@ i915_gem_object_get_pages_buddy(struct
>drm_i915_gem_object *obj)
> return -ENOMEM;
> }
>
>+ flags = I915_ALLOC_MIN_PAGE_SIZE;
>+ if (obj->flags & I915_BO_ALLOC_CONTIGUOUS)
>+ flags |= I915_ALLOC_CONTIGUOUS;
>+
> ret = __intel_memory_region_get_pages_buddy(mem, size, flags,
>blocks);
> if (ret)
> goto err_free_sg;
>@@ -56,7 +60,8 @@ i915_gem_object_get_pages_buddy(struct
>drm_i915_gem_object *obj)
> list_for_each_entry(block, blocks, link) {
> u64 block_size, offset;
>
>- block_size = i915_buddy_block_size(>mm, block);
>+ block_size = min_t(u64, size,
>+ i915_buddy_block_size(>mm,
>block));
> offset = i915_buddy_block_offset(block);
>
> GEM_BUG_ON(overflows_type(block_size, sg->length));
>@@ -98,10 +103,12 @@ i915_gem_object_get_pages_buddy(struct
>drm_i915_gem_object *obj)
> }
>
> void i915_gem_object_init_memory_region(struct drm_i915_gem_object
>*obj,
>- struct intel_memory_region *mem)
>+ struct intel_memory_region *mem,
>+ unsigned long flags)
> {
> INIT_LIST_HEAD(>mm.blocks);
> obj->mm.region = mem;
>+ obj->flags = flags;
> }
>
> void i915_gem_object_release_memory_region(struct
>drm_i915_gem_object *obj)
>@@ -115,6 +122,8 @@ i915_gem_object_create_region(struct
>intel_memory_region *mem,
> {
> struct drm_i915_gem_object *obj;
>
>+ GEM_BUG_ON(flags & ~I915_BO_ALLOC_FLAGS);
>+
> if (!mem)
> return ERR_PTR(-ENODEV);
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.h
>b/drivers/gpu/drm/i915/gem/i915_gem_region.h
>index ebddc86d78f7..f2ff6f8bff74 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_region.h
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_region.h
>@@ -17,7 +17,8 @@ void i915_gem_object_put_pages_buddy(struct
>drm_i915_gem_object *obj,
>struct sg_table *pages);
>
> void i915_gem_object_init_memory_region(struct drm_i915_gem_object
>*obj,
>- struct intel_memory_region *mem);
>+ struct
Re: [Intel-gfx] [PATCH 2/2] drm/mm: Pack allocated/scanned boolean into a bitfield
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
>Of Chris Wilson
>Sent: Sunday, September 15, 2019 2:46 PM
>To: dri-de...@lists.freedesktop.org
>Cc: intel-gfx@lists.freedesktop.org
>Subject: [PATCH 2/2] drm/mm: Pack allocated/scanned boolean into a bitfield
>
>The ulterior motive to switching the booleans over to bitops is to
>allow use of the allocated flag as a bitlock.
>
>Signed-off-by: Chris Wilson
>---
> drivers/gpu/drm/drm_mm.c | 36 +++
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 6 ++--
> drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 2 +-
> drivers/gpu/drm/i915/i915_gem.c | 16 -
> drivers/gpu/drm/i915/i915_gem_evict.c | 2 +-
> drivers/gpu/drm/i915/i915_vma.c | 2 +-
> drivers/gpu/drm/i915/i915_vma.h | 4 +--
> drivers/gpu/drm/selftests/test-drm_mm.c | 14
> drivers/gpu/drm/vc4/vc4_crtc.c| 2 +-
> drivers/gpu/drm/vc4/vc4_hvs.c | 2 +-
> drivers/gpu/drm/vc4/vc4_plane.c | 4 +--
> include/drm/drm_mm.h | 7 ++--
> 12 files changed, 52 insertions(+), 45 deletions(-)
>
>diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
>index 4581c5387372..211967006cec 100644
>--- a/drivers/gpu/drm/drm_mm.c
>+++ b/drivers/gpu/drm/drm_mm.c
>@@ -174,7 +174,7 @@ static void drm_mm_interval_tree_add_node(struct
>drm_mm_node *hole_node,
>
> node->__subtree_last = LAST(node);
>
>- if (hole_node->allocated) {
>+ if (drm_mm_node_allocated(hole_node)) {
> rb = _node->rb;
> while (rb) {
> parent = rb_entry(rb, struct drm_mm_node, rb);
>@@ -424,9 +424,9 @@ int drm_mm_reserve_node(struct drm_mm *mm,
>struct drm_mm_node *node)
>
> node->mm = mm;
>
>+ __set_bit(DRM_MM_NODE_ALLOCATED_BIT, >flags);
Maybe a silly question(s), but you appear to be mixing atomic bit ops
(clear_ and test_) with non-atomic bit ops __xxx_bit().
Should that be a concern? Should that be mention in the commit?
Mike
> list_add(>node_list, >node_list);
> drm_mm_interval_tree_add_node(hole, node);
>- node->allocated = true;
> node->hole_size = 0;
>
> rm_hole(hole);
>@@ -543,9 +543,9 @@ int drm_mm_insert_node_in_range(struct drm_mm *
>const mm,
> node->color = color;
> node->hole_size = 0;
>
>+ __set_bit(DRM_MM_NODE_ALLOCATED_BIT, >flags);
> list_add(>node_list, >node_list);
> drm_mm_interval_tree_add_node(hole, node);
>- node->allocated = true;
>
> rm_hole(hole);
> if (adj_start > hole_start)
>@@ -561,6 +561,11 @@ int drm_mm_insert_node_in_range(struct drm_mm
>* const mm,
> }
> EXPORT_SYMBOL(drm_mm_insert_node_in_range);
>
>+static inline bool drm_mm_node_scanned_block(const struct
>drm_mm_node *node)
>+{
>+ return test_bit(DRM_MM_NODE_SCANNED_BIT, >flags);
>+}
>+
> /**
> * drm_mm_remove_node - Remove a memory node from the allocator.
> * @node: drm_mm_node to remove
>@@ -574,8 +579,8 @@ void drm_mm_remove_node(struct drm_mm_node
>*node)
> struct drm_mm *mm = node->mm;
> struct drm_mm_node *prev_node;
>
>- DRM_MM_BUG_ON(!node->allocated);
>- DRM_MM_BUG_ON(node->scanned_block);
>+ DRM_MM_BUG_ON(!drm_mm_node_allocated(node));
>+ DRM_MM_BUG_ON(drm_mm_node_scanned_block(node));
>
> prev_node = list_prev_entry(node, node_list);
>
>@@ -584,11 +589,12 @@ void drm_mm_remove_node(struct
>drm_mm_node *node)
>
> drm_mm_interval_tree_remove(node, >interval_tree);
> list_del(>node_list);
>- node->allocated = false;
>
> if (drm_mm_hole_follows(prev_node))
> rm_hole(prev_node);
> add_hole(prev_node);
>+
>+ clear_bit_unlock(DRM_MM_NODE_ALLOCATED_BIT, >flags);
> }
> EXPORT_SYMBOL(drm_mm_remove_node);
>
>@@ -605,7 +611,7 @@ void drm_mm_replace_node(struct drm_mm_node
>*old, struct drm_mm_node *new)
> {
> struct drm_mm *mm = old->mm;
>
>- DRM_MM_BUG_ON(!old->allocated);
>+ DRM_MM_BUG_ON(!drm_mm_node_allocated(old));
>
> *new = *old;
>
>@@ -622,8 +628,7 @@ void drm_mm_replace_node(struct drm_mm_node
>*old, struct drm_mm_node *new)
> >holes_addr);
> }
>
>- old->allocated = false;
>- new->allocated = true;
>+ clear_bit_unlock(DRM_MM_NODE_ALLOCATED_BIT, >flags);
> }
> EXPORT_SYMBOL(drm_mm_replace_node);
>
>@@ -731,9 +736,9 @@ bool drm_mm_scan_add_block(struct drm_mm_scan
>*scan,
> u64 adj_start, adj_end;
>
> DRM_MM_BUG_ON(node->mm != mm);
>- DRM_MM_BUG_ON(!node->allocated);
>- DRM_MM_BUG_ON(node->scanned_block);
>- node->scanned_block = true;
>+ DRM_MM_BUG_ON(!drm_mm_node_allocated(node));
>+ DRM_MM_BUG_ON(drm_mm_node_scanned_block(node));
>+ __set_bit(DRM_MM_NODE_SCANNED_BIT, >flags);
>
