Re: [Intel-gfx] [PATCH v2 12/16] drm/i915: Add i915_vma_unbind_unlocked, and take obj lock for i915_vma_unbind

On Thu, 9 Dec 2021 at 13:46, Maarten Lankhorst wrote: > > On 09-12-2021 14:40, Matthew Auld wrote: > > On Thu, 9 Dec 2021 at 13:25, Maarten Lankhorst > > wrote: > >> On 09-12-2021 14:05, Matthew Auld wrote: > >>> On Mon, 29 Nov 2021 at 13:58, Maarten

Re: [Intel-gfx] [PATCH v2 12/16] drm/i915: Add i915_vma_unbind_unlocked, and take obj lock for i915_vma_unbind

On Thu, 9 Dec 2021 at 13:25, Maarten Lankhorst wrote: > > On 09-12-2021 14:05, Matthew Auld wrote: > > On Mon, 29 Nov 2021 at 13:58, Maarten Lankhorst > > wrote: > >> We want to remove more members of i915_vma, which requires the locking to > >> be &

Re: [Intel-gfx] [PATCH v2 12/16] drm/i915: Add i915_vma_unbind_unlocked, and take obj lock for i915_vma_unbind

On Mon, 29 Nov 2021 at 13:58, Maarten Lankhorst wrote: > > We want to remove more members of i915_vma, which requires the locking to be > held more often. > > Start requiring gem object lock for i915_vma_unbind, as it's one of the > callers that may unpin pages. > > Some special care is needed

Re: [Intel-gfx] [PATCH v2 14/16] drm/i915: Remove assert_object_held_shared

d-off-by: Maarten Lankhorst Reviewed-by: Matthew Auld

Re: [Intel-gfx] [PATCH v2 11/16] drm/i915: Call i915_gem_evict_vm in vm_fault_gtt to prevent new ENOSPC errors

he already locked object and then also any vma sharing the same dma-resv object here? Or at least trying to nuke the entire vm, just for the mappable portion seems maybe overkill? Or perhaps we never expect to hit this in the real world? Reviewed-by: Matthew Auld > +

Re: [Intel-gfx] [PATCH 2/4] drm/i915/xehpsdv: set min page-size to 64K

On Wed, 8 Dec 2021 at 14:16, Ramalingam C wrote: > > From: Matthew Auld > > LMEM should be allocated at 64K granularity, since 4K page support will > eventually be dropped for LMEM when using the PPGTT. s/will eventually be dropped/has been dropped/ as per Thomas' suggestion.

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Add has_64k_pages flag

On Wed, 8 Dec 2021 at 12:43, Thomas Hellström (Intel) wrote: > > Hi, > > On 12/7/21 17:51, Ramalingam C wrote: > > From: Stuart Summers > > > > Add a new platform flag, has_64k_pages, for platforms supporting > > base page sizes of 64k. > > > > Signed-off-by: Stuart Summers > > Signed-off-by:

Re: [Intel-gfx] [PATCH v2 10/16] drm/i915: Make i915_gem_evict_vm work correctly for already locked objects

; case to allow i915_gem_evict_vm to evict locked objects as well. > > This might also allow multiple objects sharing the same resv to be evicted. > > Signed-off-by: Maarten Lankhorst Reviewed-by: Matthew Auld Do we need similar treatment for stuff like evict_for_node etc? &g

Re: [Intel-gfx] [PATCH v2 09/16] drm/i915: Ensure i915_vma tests do not get -ENOSPC with the locking changes.

On Wed, 8 Dec 2021 at 11:49, Matthew Auld wrote: > > On Mon, 29 Nov 2021 at 13:58, Maarten Lankhorst > wrote: > > > > Now that we require locking to evict, multiple vmas from the same object > > might not be evicted. This is expected and required, because execbuf

Re: [Intel-gfx] [PATCH v2 09/16] drm/i915: Ensure i915_vma tests do not get -ENOSPC with the locking changes.

On Mon, 29 Nov 2021 at 13:58, Maarten Lankhorst wrote: > > Now that we require locking to evict, multiple vmas from the same object > might not be evicted. This is expected and required, because execbuf will > move to short-term pinning by using the lock only. This will cause these > tests to

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Sanitycheck device iomem on probe

that the memory is functional. Signed-off-by: Chris Wilson Cc: Matthew Auld Cc: CQ Tang Signed-off-by: Ramalingam C For the series, assuming CI is happy now, Reviewed-by: Matthew Auld Also patch 3 should be moved to the start of the series. --- drivers/gpu/drm/i915/intel_memory_region.c

Re: [Intel-gfx] [PATCH 0/2] Sanity Check for device memory region

On Tue, 7 Dec 2021 at 16:04, Matthew Auld wrote: > > On Tue, 7 Dec 2021 at 14:34, Ramalingam C wrote: > > > > Changes for introducing the quick test on the device memory range and > > also a test of detailed validation for each addr of the range with read > > and w

Re: [Intel-gfx] [PATCH 0/2] Sanity Check for device memory region

On Tue, 7 Dec 2021 at 14:34, Ramalingam C wrote: > > Changes for introducing the quick test on the device memory range and > also a test of detailed validation for each addr of the range with read > and write. > > Detailed testing is optionally enabled with a modparam i915.memtest=1 Series is

Re: [Intel-gfx] [PATCH v2 08/16] drm/i915: Pass trylock context to callers

the current ww context. > > On top of that, this slightly improves ww handling because the locked > objects are marked as locked by the correct ww. > > Signed-off-by: Maarten Lankhorst Reviewed-by: Matthew Auld

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/4] drm/i915/migrate: don't check the scratch page

On Mon, 6 Dec 2021 at 16:46, Patchwork wrote: > *Patch Details* > *Series:* series starting with [1/4] drm/i915/migrate: don't check the > scratch page > *URL:* https://patchwork.freedesktop.org/series/97610/ > *State:* failure > *Details:* >

Re: [Intel-gfx] [PATCH v9 2/8] drm/i915/ttm: add tt shmem backend

On 07/12/2021 13:10, Tvrtko Ursulin wrote: On 18/10/2021 10:10, Matthew Auld wrote: For cached objects we can allocate our pages directly in shmem. This should make it possible(in a later patch) to utilise the existing i915-gem shrinker code for such objects. For now this is still disabled

Re: [Intel-gfx] [PATCH v2 07/16] drm/i915: Take trylock during eviction, v2.

On Mon, 29 Nov 2021 at 13:57, Maarten Lankhorst wrote: > > Now that freeing objects takes the object lock when destroying the > backing pages, we can confidently take the object lock even for dead > objects. That looks to be a future patch, at least with non-TTM backend? Does something need to

Re: [Intel-gfx] [PATCH v2 03/16] drm/i915: Remove pages_mutex and intel_gtt->vma_ops.set/clear_pages members, v2.

On Tue, 7 Dec 2021 at 10:06, Maarten Lankhorst wrote: > > On 06-12-2021 18:10, Matthew Auld wrote: > > On Mon, 29 Nov 2021 at 13:57, Maarten Lankhorst > > wrote: > >> Big delta, but boils down to moving set_pages to i915_vma.c, and removing > >> the special ha

Re: [Intel-gfx] [PATCH v2 06/16] drm/i915: Ensure gem_contexts selftests work with unbind changes.

u32), > alignof_dword); > > - err = write_to_scratch(ctx_a, engine, > + err = write_to_scratch(ctx_a, engine, obj_a, >offset, 0xdeadbeef); > if (err == 0) > -

Re: [Intel-gfx] [PATCH v2 03/16] drm/i915: Remove pages_mutex and intel_gtt->vma_ops.set/clear_pages members, v2.

On Mon, 29 Nov 2021 at 13:57, Maarten Lankhorst wrote: > > Big delta, but boils down to moving set_pages to i915_vma.c, and removing > the special handling, all callers use the defaults anyway. We only remap > in ggtt, so default case will fall through. > > Because we still don't require locking

Re: [Intel-gfx] [PATCH v2 03/16] drm/i915: Remove pages_mutex and intel_gtt->vma_ops.set/clear_pages members, v2.

On Mon, 6 Dec 2021 at 15:18, Maarten Lankhorst wrote: > > On 06-12-2021 14:13, Matthew Auld wrote: > > On Mon, 29 Nov 2021 at 13:57, Maarten Lankhorst > > wrote: > >> Big delta, but boils down to moving set_pages to i915_vma.c, and removing > >> the special ha

Re: [Intel-gfx] [PATCH v3 0/8] DG2 accelerated migration/clearing support

On 06/12/2021 14:49, Daniel Stone wrote: Hi Matthew, On Mon, 6 Dec 2021 at 13:32, Matthew Auld wrote: Enable accelerated moves and clearing on DG2. On such HW we have minimum page size restrictions when accessing LMEM from the GTT, where we now have to use 64K GTT pages or larger

[Intel-gfx] [PATCH v3 8/8] drm/i915/migrate: turn on acceleration for DG2

Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Ramalingam C --- drivers/gpu/drm/i915/gt/intel_migrate.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c b/drivers/gpu/drm/i915/gt/intel_migrate.c index fb658ae70a8d..0fb83d0bec91 100644

[Intel-gfx] [PATCH v3 6/8] drm/i915/gtt: add xehpsdv_ppgtt_insert_entry

If this is LMEM then we get a 32 entry PT, with each PTE pointing to some 64K block of memory, otherwise it's just the usual 512 entry PT. This very much assumes the caller knows what they are doing. Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Ramalingam C Reviewed-by: Ramalingam C

[Intel-gfx] [PATCH v3 7/8] drm/i915/migrate: add acceleration support for DG2

This is all kinds of awkward since we now have to contend with using 64K GTT pages when mapping anything in LMEM(including the page-tables themselves). Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Ramalingam C --- drivers/gpu/drm/i915/gt/intel_migrate.c | 189

[Intel-gfx] [PATCH v3 5/8] drm/i915/gtt: allow overriding the pt alignment

On some platforms we have alignment restrictions when accessing LMEM from the GTT. In the next patch few patches we need to be able to modify the page-tables directly via the GTT itself. Suggested-by: Ramalingam C Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Ramalingam C --- drivers

[Intel-gfx] [PATCH v3 4/8] drm/i915/selftests: handle object rounding

Ensure we account for any object rounding due to min_page_size restrictions. Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Ramalingam C Reviewed-by: Ramalingam C --- drivers/gpu/drm/i915/gt/selftest_migrate.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/gt

[Intel-gfx] [PATCH v3 3/8] drm/i915/migrate: fix length calculation

No need to insert PTEs for the PTE window itself, also foreach expects a length not an end offset, which could be gigantic here with a second engine. Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Ramalingam C Reviewed-by: Ramalingam C --- drivers/gpu/drm/i915/gt/intel_migrate.c | 2

[Intel-gfx] [PATCH v3 2/8] drm/i915/migrate: fix offset calculation

Ensure we add the engine base only after we calculate the qword offset into the PTE window. Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Ramalingam C Reviewed-by: Ramalingam C --- drivers/gpu/drm/i915/gt/intel_migrate.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[Intel-gfx] [PATCH v3 1/8] drm/i915/migrate: don't check the scratch page

The scratch page might not be allocated in LMEM(like on DG2), so instead of using that as the deciding factor for where the paging structures live, let's just query the pt before mapping it. Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Ramalingam C Reviewed-by: Ramalingam C

[Intel-gfx] [PATCH v3 0/8] DG2 accelerated migration/clearing support

to be applied on top of the DG2 enabling branch: https://cgit.freedesktop.org/~ramaling/linux/log/?h=dg2_enabling_ww49.3 Matthew Auld (8): drm/i915/migrate: don't check the scratch page drm/i915/migrate: fix offset calculation drm/i915/migrate: fix length calculation drm/i915/selftests: handle

Re: [Intel-gfx] [PATCH v2 04/16] drm/i915: Take object lock in i915_ggtt_pin if ww is not set

On Mon, 29 Nov 2021 at 13:58, Maarten Lankhorst wrote: > > i915_vma_wait_for_bind needs the vma lock held, fix the caller. > > Signed-off-by: Maarten Lankhorst Reviewed-by: Matthew Auld

[Intel-gfx] [PATCH 1/4] drm/i915/migrate: don't check the scratch page

The scratch page might not be allocated in LMEM(like on DG2), so instead of using that as the deciding factor for where the paging structures live, let's just query the pt before mapping it. Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Ramalingam C Reviewed-by: Ramalingam C

[Intel-gfx] [PATCH 4/4] drm/i915/selftests: handle object rounding

Ensure we account for any object rounding due to min_page_size restrictions. Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Ramalingam C Reviewed-by: Ramalingam C --- drivers/gpu/drm/i915/gt/selftest_migrate.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/gt

[Intel-gfx] [PATCH 2/4] drm/i915/migrate: fix offset calculation

Ensure we add the engine base only after we calculate the qword offset into the PTE window. Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Ramalingam C Reviewed-by: Ramalingam C --- drivers/gpu/drm/i915/gt/intel_migrate.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[Intel-gfx] [PATCH 3/4] drm/i915/migrate: fix length calculation

No need to insert PTEs for the PTE window itself, also foreach expects a length not an end offset, which could be gigantic here with a second engine. Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Ramalingam C Reviewed-by: Ramalingam C --- drivers/gpu/drm/i915/gt/intel_migrate.c | 2

Re: [Intel-gfx] [PATCH v2 4/8] drm/i915/migrate: fix offset calculation

On 03/12/2021 17:30, Ramalingam C wrote: On 2021-12-03 at 12:24:22 +, Matthew Auld wrote: Ensure we add the engine base only after we calculate the qword offset into the PTE window. So we didn't hit this issue because we were always using the engine->instance 0!? Yes, AFAIK. Lo

Re: [Intel-gfx] [PATCH v2 3/8] drm/i915/gtt: add gtt mappable plumbing

On 03/12/2021 17:25, Ramalingam C wrote: On 2021-12-03 at 12:24:21 +, Matthew Auld wrote: With object clearing/copying we need to be able to modify the PTEs on the fly via some batch buffer, which means we need to be able to map the paging structures(or at the very least the PT, but being

Re: [Intel-gfx] [PATCH v2 2/8] drm/i915/gtt: add xehpsdv_ppgtt_insert_entry

On 03/12/2021 16:59, Ramalingam C wrote: On 2021-12-03 at 12:24:20 +, Matthew Auld wrote: If this is LMEM then we get a 32 entry PT, with each PTE pointing to some 64K block of memory, otherwise it's just the usual 512 entry PT. This very much assumes the caller knows what they are doing

[Intel-gfx] [PATCH v2 8/8] drm/i915/migrate: turn on acceleration for DG2

Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Ramalingam C --- drivers/gpu/drm/i915/gt/intel_migrate.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c b/drivers/gpu/drm/i915/gt/intel_migrate.c index a804c57b61df..0da27ec808dc 100644

[Intel-gfx] [PATCH v2 6/8] drm/i915/selftests: handle object rounding

Ensure we account for any object rounding due to min_page_size restrictions. Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Ramalingam C --- drivers/gpu/drm/i915/gt/selftest_migrate.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/gt/selftest_migrate.c b

[Intel-gfx] [PATCH v2 7/8] drm/i915/migrate: add acceleration support for DG2

This is all kinds of awkward since we now have to contend with using 64K GTT pages when mapping anything in LMEM(including the page-tables themselves). Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Ramalingam C --- drivers/gpu/drm/i915/gt/intel_migrate.c | 186

[Intel-gfx] [PATCH v2 4/8] drm/i915/migrate: fix offset calculation

Ensure we add the engine base only after we calculate the qword offset into the PTE window. Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Ramalingam C --- drivers/gpu/drm/i915/gt/intel_migrate.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt

[Intel-gfx] [PATCH v2 5/8] drm/i915/migrate: fix length calculation

No need to insert PTEs for the PTE window itself, also foreach expects a length not an end offset, which could be gigantic here with a second engine. Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Ramalingam C --- drivers/gpu/drm/i915/gt/intel_migrate.c | 2 +- 1 file changed, 1

[Intel-gfx] [PATCH v2 3/8] drm/i915/gtt: add gtt mappable plumbing

-by: Matthew Auld Cc: Thomas Hellström Cc: Ramalingam C --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 ++-- drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 2 +- drivers/gpu/drm/i915/gt/gen6_ppgtt.c| 2 +- drivers/gpu/drm/i915/gt/gen8_ppgtt.c| 3 ++- drivers

[Intel-gfx] [PATCH v2 2/8] drm/i915/gtt: add xehpsdv_ppgtt_insert_entry

If this is LMEM then we get a 32 entry PT, with each PTE pointing to some 64K block of memory, otherwise it's just the usual 512 entry PT. This very much assumes the caller knows what they are doing. Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Ramalingam C --- drivers/gpu/drm/i915/gt

[Intel-gfx] [PATCH v2 1/8] drm/i915/migrate: don't check the scratch page

The scratch page might not be allocated in LMEM(like on DG2), so instead of using that as the deciding factor for where the paging structures live, let's just query the pt before mapping it. Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Ramalingam C --- drivers/gpu/drm/i915/gt

[Intel-gfx] [PATCH v2 0/8] DG2 accelerated migration/clearing support

to be applied on top of the DG2 enabling branch: https://cgit.freedesktop.org/~ramaling/linux/log/?h=dg2_enabling_ww49.3 Patches 2, 7 and 8 have a dependency on patches in that branch, but the rest can likely already land if the direction makes sense. Matthew Auld (8): drm/i915/migrate: don't check

[Intel-gfx] [PATCH 8/8] drm/i915/migrate: turn on acceleration for DG2

Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Ramalingam C --- drivers/gpu/drm/i915/gt/intel_migrate.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c b/drivers/gpu/drm/i915/gt/intel_migrate.c index a804c57b61df..0da27ec808dc 100644

[Intel-gfx] [PATCH 7/8] drm/i915/migrate: add acceleration support for DG2

This is all kinds of awkward since we now have to contend with using 64K GTT pages when mapping anything in LMEM(including the page-tables themselves). Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Ramalingam C --- drivers/gpu/drm/i915/gt/intel_migrate.c | 186

[Intel-gfx] [PATCH 6/8] drm/i915/selftests: handle object rounding

Ensure we account for any object rounding due to min_page_size restrictions. Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Ramalingam C --- drivers/gpu/drm/i915/gt/selftest_migrate.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/gt/selftest_migrate.c b

[Intel-gfx] [PATCH 5/8] drm/i915/migrate: fix length calculation

No need to insert PTEs for the PTE window itself, also foreach expects a length not an end offset, which could be gigantic here with a second engine. Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Ramalingam C --- drivers/gpu/drm/i915/gt/intel_migrate.c | 2 +- 1 file changed, 1

[Intel-gfx] [PATCH 4/8] drm/i915/migrate: fix offset calculation

Ensure we add the engine base only after we calculate the qword offset into the PTE window. Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Ramalingam C --- drivers/gpu/drm/i915/gt/intel_migrate.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt

[Intel-gfx] [PATCH 3/8] drm/i915/gtt: add gtt mappable plumbing

-by: Matthew Auld Cc: Thomas Hellström Cc: Ramalingam C --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 ++-- drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 2 +- drivers/gpu/drm/i915/gt/gen6_ppgtt.c| 2 +- drivers/gpu/drm/i915/gt/gen8_ppgtt.c| 3 ++- drivers

[Intel-gfx] [PATCH 2/8] drm/i915/gtt: add xehpsdv_ppgtt_insert_entry

If this is LMEM then we get a 32 entry PT, with each PTE pointing to some 64K block of memory, otherwise it's just the usual 512 entry PT. This very much assumes the caller knows what they are doing. Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Ramalingam C --- drivers/gpu/drm/i915/gt

[Intel-gfx] [PATCH 1/8] drm/i915/migrate: don't check the scratch page

The scratch page might not be allocated in LMEM(like on DG2), so instead of using that as the deciding factor for where the paging structures live, let's just query the pt before mapping it. Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Ramalingam C --- drivers/gpu/drm/i915/gt

Re: [Intel-gfx] [PATCH] drm/i915: Force ww lock for i915_gem_object_ggtt_pin_ww, v2.

err = i915_gem_object_lock(obj, ); > + if (err) > + continue; > + > + ret = i915_gem_object_ggtt_pin_ww(obj, , view, size, > + alignment, flags); > + if (IS_ERR(

[Intel-gfx] [PATCH] drm/i915/gemfs: don't mark huge_opt as static

gions: i915 :00:02.0: [drm] Transparent Hugepage mode 'huge' tmpfs: Bad value for 'huge' [drm] Unable to create a private tmpfs mount, hugepage support will be disabled(-22). References: https://gitlab.freedesktop.org/drm/intel/-/issues/4651 Signed-off-by: Matthew Auld Cc: Tvrtko Ursulin

Re: [Intel-gfx] [PATCH v3 2/6] drm: improve drm_buddy_alloc function

On 23/11/2021 22:39, Arunpravin wrote: On 18/11/21 12:09 am, Matthew Auld wrote: On 16/11/2021 20:18, Arunpravin wrote: - Make drm_buddy_alloc a single function to handle range allocation and non-range allocation demands - Implemented a new function alloc_range() which allocates

[Intel-gfx] [PATCH] drm/i915/ttm: fixup build failure

vma->vm_page_prot, | ^~~ Signed-off-by: Matthew Auld Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c b/drivers/gpu/drm/i9

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gem: placate scripts/kernel-doc

On Tue, 23 Nov 2021 at 05:56, Patchwork wrote: > *Patch Details* > *Series:* drm/i915/gem: placate scripts/kernel-doc > *URL:* https://patchwork.freedesktop.org/series/97190/ > *State:* failure > *Details:* > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21664/index.html CI > Bug Log -

Re: [Intel-gfx] [PATCH] drm/i915/gem: placate scripts/kernel-doc

: warning: No description found for return value of 'i915_gem_object_read_from_page' Signed-off-by: Randy Dunlap Reported-by: kernel test robot Cc: Thomas Hellström Cc: Matthew Auld Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: Tvrtko Ursulin Cc: intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/ttm: Fix error code in i915_ttm_eviction_valuable()

On Mon, 22 Nov 2021 at 14:21, Dan Carpenter wrote: > > On Mon, Nov 22, 2021 at 02:08:39PM -, Patchwork wrote: > > == Series Details == > > > > Series: drm/i915/ttm: Fix error code in i915_ttm_eviction_valuable() > > URL : https://patchwork.freedesktop.org/series/97151/ > > State : failure >

Re: [Intel-gfx] [PATCH] Revert "drm/i915/dmabuf: fix broken build"

-2021-11-12' of git://anongit.freedesktop.org/drm/drm"). Signed-off-by: Tvrtko Ursulin Fixes: 777226dac058 ("drm/i915/dmabuf: fix broken build") Cc: Matthew Auld Cc: Thomas Hellström Cc: Daniel Vetter Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: Jani Nikula Acked-by: Matthew

Re: [Intel-gfx] [PATCH] drm/i915/ttm: Fix error code in i915_ttm_eviction_valuable()

On 22/11/2021 07:41, Dan Carpenter wrote: This function returns a bool type so returning -EBUSY is equivalent to returning true. It should return false instead. Fixes: 7ae034590cea ("drm/i915/ttm: add tt shmem backend") Signed-off-by: Dan Carpenter Reviewed-by: Matthew Auld

Re: [Intel-gfx] [PATCH v4 6/6] drm/i915/ttm: Update i915_gem_obj_copy_ttm() to be asynchronous

On 18/11/2021 13:02, Thomas Hellström wrote: Update the copy function i915_gem_obj_copy_ttm() to be asynchronous for future users and update the only current user to sync the objects as needed after this function. Signed-off-by: Thomas Hellström Reviewed-by: Matthew Auld

Re: [Intel-gfx] [PATCH v4 5/6] drm/i915/ttm: Implement asynchronous TTM moves

issues (Matthew Auld) - Audit and add more checks for ghost objects (Matthew Auld) - Add more documentation for the i915_deps utility (Mattew Auld) - Simplify the i915_deps_sync() function Signed-off-by: Thomas Hellström --- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 32 +- drivers/gpu/drm

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,1/6] drm/i915: move the pre_pin earlier (rev3)

On 19/11/2021 13:53, Patchwork wrote: *Patch Details* *Series:* series starting with [v2,1/6] drm/i915: move the pre_pin earlier (rev3) *URL:* https://patchwork.freedesktop.org/series/97026/ *State:*failure *Details:*

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/6] drm/i915: move the pre_pin earlier (rev2)

On 18/11/2021 16:36, Patchwork wrote: *Patch Details* *Series:* series starting with [v2,1/6] drm/i915: move the pre_pin earlier (rev2) *URL:* https://patchwork.freedesktop.org/series/97026/ *State:*failure *Details:*

Re: [Intel-gfx] [bug report] drm/i915/ttm: add tt shmem backend

On 18/11/2021 15:01, Dan Carpenter wrote: Hello Matthew Auld, The patch 7ae034590cea: "drm/i915/ttm: add tt shmem backend" from Oct 18, 2021, leads to the following Smatch static checker warning: drivers/gpu/drm/i915/gem/i915_gem_ttm.c:335 i915_ttm_eviction_valuable()

Re: [Intel-gfx] [PATCH v4 4/6] drm/i915/ttm: Correctly handle waiting for gpu when shrinking

Reviewed-by: Matthew Auld

Re: [Intel-gfx] [PATCH v4 3/6] drm/i915/ttm: Drop region reference counting

off-by: Thomas Hellström Reviewed-by: Matthew Auld

Re: [Intel-gfx] [PATCH v4 1/6] drm/i915: Add support for moving fence waiting

nce waiting for i915_vma_pin_iomap() and replace with a verification that the vma is already bound. (Matthew Auld) - Squash with a previous patch introducing moving fence waiting and accessing interfaces (Matthew Auld) - Rename to indicated that we also add support for sync waiting.

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/6] drm/i915: move the pre_pin earlier

On 17/11/2021 19:53, Patchwork wrote: *Patch Details* *Series:* series starting with [v2,1/6] drm/i915: move the pre_pin earlier *URL:* https://patchwork.freedesktop.org/series/97026/ *State:*failure *Details:*

Re: [Intel-gfx] [PATCH v2 1/6] drm/i915: move the pre_pin earlier

On 18/11/2021 06:57, Thomas Hellström wrote: On Wed, 2021-11-17 at 19:49 +0100, Thomas Hellström wrote: On 11/17/21 15:20, Matthew Auld wrote: In intel_context_do_pin_ww, when calling into the pre_pin hook(which is passed the ww context) it could in theory return -EDEADLK(which is very likely

Re: [Intel-gfx] [PATCH v3 4/6] drm: implement a method to free unused pages

On 16/11/2021 20:18, Arunpravin wrote: On contiguous allocation, we round up the size to the *next* power of 2, implement a function to free the unused pages after the newly allocate block. v2(Matthew Auld): - replace function name 'drm_buddy_free_unused_pages' with drm_buddy_block_trim

Re: [Intel-gfx] [PATCH v3 2/6] drm: improve drm_buddy_alloc function

to i915 driver v3(Matthew Auld): - Fix alignment issues and remove unnecessary list_empty check - add more validation checks for input arguments - make alloc_range() block allocations as bottom-up - optimize order computation logic - replace uint64_t with u64, which is preferred

Re: [Intel-gfx] [PATCH v3 1/6] drm: move the buddy allocator from i915 into common drm

On 16/11/2021 20:18, Arunpravin wrote: Move the base i915 buddy allocator code into drm - Move i915_buddy.h to include/drm - Move i915_buddy.c to drm root folder - Rename "i915" string with "drm" string wherever applicable - Rename "I915" string with "DRM" string wherever applicable - Fix header

[Intel-gfx] [PATCH v2 6/6] drm/i915: Drain the ttm delayed workqueue too

From: Maarten Lankhorst Lets be thorough here. Users of the TTM backend would likely expect this behaviour. Signed-off-by: Maarten Lankhorst Reviewed-by: Matthew Auld Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/i915_drv.h | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers

[Intel-gfx] [PATCH v2 5/6] drm/i915: Remove resv from i915_vma

From: Maarten Lankhorst It's just an alias to vma->obj->base.resv, no need to duplicate it. Signed-off-by: Maarten Lankhorst Reviewed-by: Niranjana Vishwanathapura Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 ++-- drivers/gpu/drm/i915/i915

[Intel-gfx] [PATCH v2 3/6] drm/i915: Create a full object for mock_ring, v2.

hew Auld Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/gt/mock_engine.c | 38 --- 1 file changed, 28 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/mock_engine.c b/drivers/gpu/drm/i915/gt/mock_engine.c index 8b89215afe46..bb99fc03f503 100

[Intel-gfx] [PATCH v2 4/6] drm/i915: vma is always backed by an object.

From: Maarten Lankhorst vma->obj and vma->resv are now never NULL, and some checks can be removed. Signed-off-by: Maarten Lankhorst Reviewed-by: Matthew Auld Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/gt/intel_context.c | 2 +- .../gpu/drm/i915/gt/intel_ring_submis

[Intel-gfx] [PATCH v2 2/6] drm/i915: Create a dummy object for gen6 ppgtt

ect is created. It just has to look real enough. Also kill pin_mutex, it's not compatible with ww locking, and we can use the vm lock instead. v2: - Drop IS_SHRINKABLE and shorten overly long line v3: - Checkpatch fix for alignment Signed-off-by: Maarten Lankhorst Reviewed-by: Matthew Auld Signed-

[Intel-gfx] [PATCH v2 1/6] drm/i915: move the pre_pin earlier

-off-by: Matthew Auld Cc: Thomas Hellström Cc: Maarten Lankhorst --- drivers/gpu/drm/i915/gt/intel_context.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_context.c b/drivers/gpu/drm/i915/gt/intel_context.c index 5634d14052bc

Re: [Intel-gfx] [PATCH] drm/i915: Skip remap_io_mapping() for non-x86 platforms

On Sat, 13 Nov 2021 at 17:33, Lucas De Marchi wrote: > > On Sat, Nov 13, 2021 at 12:18:10AM +0200, Jani Nikula wrote: > >On Fri, 12 Nov 2021, Mullati Siva wrote: > >> The _PAGE_CACHE_MASK macro is not defined in non-x86 > >> architectures and it's been used in remap_io_mapping(). > >> Only hw

Re: [Intel-gfx] [PATCH v3 5/6] drm/i915/ttm: Implement asynchronous TTM moves

On 14/11/2021 11:12, Thomas Hellström wrote: Don't wait sync while migrating, but rather make the GPU blit await the dependencies and add a moving fence to the object. This also enables asynchronous VRAM management in that on eviction, rather than waiting for the moving fence to expire before

Re: [Intel-gfx] [PATCH v3 2/6] drm/i915: Add support for asynchronous moving fence waiting

On 15/11/2021 12:42, Thomas Hellström wrote: On 11/15/21 13:36, Matthew Auld wrote: On 14/11/2021 11:12, Thomas Hellström wrote: From: Maarten Lankhorst For now, we will only allow async migration when TTM is used, so the paths we care about are related to TTM. The mmap path is handled

Re: [Intel-gfx] [PATCH v3 1/6] drm/i915: Add functions to set/get moving fence

On 14/11/2021 11:12, Thomas Hellström wrote: From: Maarten Lankhorst We want to get rid of i915_vma tracking to simplify the code and lifetimes. Add a way to set/put the moving fence, in preparation for removing the tracking. Signed-off-by: Maarten Lankhorst ---

Re: [Intel-gfx] [PATCH v3 2/6] drm/i915: Add support for asynchronous moving fence waiting

On 14/11/2021 11:12, Thomas Hellström wrote: From: Maarten Lankhorst For now, we will only allow async migration when TTM is used, so the paths we care about are related to TTM. The mmap path is handled by having the fence in ttm_bo->moving, when pinning, the binding only becomes available

Re: [Intel-gfx] [PATCH v3 4/6] drm/i915/ttm: Break refcounting loops at device region unref time

On 14/11/2021 11:12, Thomas Hellström wrote: There is an interesting refcounting loop: struct intel_memory_region has a struct ttm_resource_manager, ttm_resource_manager->move may hold a reference to i915_request, i915_request may hold a reference to intel_context, intel_context may hold a

Re: [Intel-gfx] [PATCH v3 3/6] drm/i915/ttm: Move the i915_gem_obj_copy_ttm() function

On 14/11/2021 11:12, Thomas Hellström wrote: Move the i915_gem_obj_copy_ttm() function to i915_gem_ttm_move.h. This will help keep a number of functions static when introducing async moves. Signed-off-by: Thomas Hellström Reviewed-by: Matthew Auld

Re: [Intel-gfx] [PATCH v3] drm/i915: Skip error capture when wedged on init

i915_disable_error_state when wedging on init/fini. v3: * Handle mock tests. Signed-off-by: Tvrtko Ursulin Reviewed-by: Matthew Auld # v1 Assuming this works locally, r-b still stands. --- drivers/gpu/drm/i915/gt/intel_reset.c| 2 ++ drivers/gpu/drm/i915/selftests/mock_gem_device.c

[Intel-gfx] [PATCH 6/6] drm/i915: Drain the ttm delayed workqueue too

From: Maarten Lankhorst Lets be thorough here. Users of the TTM backend would likely expect this behaviour. Signed-off-by: Maarten Lankhorst Reviewed-by: Matthew Auld Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/i915_drv.h | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers

[Intel-gfx] [PATCH 1/6] drm/i915: move the pre_pin earlier

. For normal user contexts this shouldn't be a concern, since we should already have the default_state ready when initialising the lrc state, and so there should be no concern with active_release somehow prematurely setting the CONTEXT_VALID_BIT. Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc

[Intel-gfx] [PATCH 4/6] drm/i915: vma is always backed by an object.

From: Maarten Lankhorst vma->obj and vma->resv are now never NULL, and some checks can be removed. Signed-off-by: Maarten Lankhorst Reviewed-by: Matthew Auld Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/gt/intel_context.c | 2 +- .../gpu/drm/i915/gt/intel_ring_submis

[Intel-gfx] [PATCH 2/6] drm/i915: Create a dummy object for gen6 ppgtt

ect is created. It just has to look real enough. Also kill pin_mutex, it's not compatible with ww locking, and we can use the vm lock instead. v2: - Drop IS_SHRINKABLE and shorten overly long line v3: - Checkpatch fix for alignment Signed-off-by: Maarten Lankhorst Reviewed-by: Matthew Auld Signed-

[Intel-gfx] [PATCH 5/6] drm/i915: Remove resv from i915_vma

From: Maarten Lankhorst It's just an alias to vma->obj->base.resv, no need to duplicate it. Signed-off-by: Maarten Lankhorst Reviewed-by: Niranjana Vishwanathapura Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 ++-- drivers/gpu/drm/i915/i915

[Intel-gfx] [PATCH 3/6] drm/i915: Create a full object for mock_ring, v2.

hew Auld Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/gt/mock_engine.c | 38 --- 1 file changed, 28 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/mock_engine.c b/drivers/gpu/drm/i915/gt/mock_engine.c index 8b89215afe46..bb99fc03f503 100

Re: [Intel-gfx] [PATCH] drm/i915: Skip error capture when wedged on init

or wedging on init. > > Signed-off-by: Tvrtko Ursulin This fixes the issue with missing GuC wedging the GPU and then blowing up when trying to use the driver? Reviewed-by: Matthew Auld > --- > drivers/gpu/drm/i915/i915_gpu_error.c | 10 +++--- > 1 file changed, 7 insertions(

Re: [Intel-gfx] [PATCH] drm/i915/ttm: Fix illegal addition to shrinker list

have a GEM refcount. Fixes: ebd4a8ec7799 ("drm/i915/ttm: move shrinker management into adjust_lru") Signed-off-by: Thomas Hellström Reviewed-by: Matthew Auld

<    5   6   7   8   9   10   11   12   13   14   >