For the ttm backend we can use existing placements fpfn and lpfn to
force the allocator to place the object at the requested offset,
potentially evicting stuff if the spot is currently occupied.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
.../gpu/drm/i915/gem/i915_gem_object_types.h
Add a generic interface for allocating an object at some specific
offset, and convert stolen over. Later we will want to hook this up to
different backends.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
.../drm/i915/display/intel_plane_initial.c| 4 +-
drivers/gpu/drm/i915/gem
on platforms like DG2).
For simplicity we don't attempt to support partially mappable stolen.
Signed-off-by: Akeem G Abodunrin
Co-developed-by: Matthew Auld
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 49 --
drivers/gpu/drm/i915
Just pass along the probed io_size. The backend should be able to
utilize the entire range here, even if some of it is non-mappable.
It does leave open with what to do with stolen local-memory.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm
The leftover bits around dealing with stolen-local memory + small BAR, plus
some related fixes.
--
2.34.1
n unneeded continue in clear_vm_list and update comment.
>
> Co-developed-by: Niranjana Vishwanathapura
>
> Signed-off-by: Niranjana Vishwanathapura
> Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
On Thu, 3 Mar 2022 at 10:53, Matthew Auld
wrote:
>
> On Tue, 22 Feb 2022 at 13:32, wrote:
> >
> > From: Xiaoke Wang
> >
> > kstrdup() is a memory allocation function which can return NULL when
> > some internaly memory errors happen. It is better to check t
gned-off-by: Xiaoke Wang
Reviewed-by: Matthew Auld
/i915: enforce min GTT alignment for discrete cards")
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Robert Beckett
Cc: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_gtt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gp
will return -ENOMEM, in ttm_bo_mem_space() after
exhausting all possible placements.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
Acked-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 2 +-
drivers/gpu/drm/i915/selftests
placements permit it.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 54 ++---
1 file changed, 48 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu
+ migration path on devices that don't have the
small BAR limit.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
.../drm/i915/gem/selftests/i915_gem_mman.c| 329 ++
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 10 +
drivers/gpu/drm/i915
hopefully victimize these last.
v2(Thomas): s/TTM_PL_PRIV/I915_PL_LMEM0/
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 65 -
1 file changed, 63 insertions(+), 2 deletions(-)
diff --git
Check that mappable vs non-mappable matches our expectations.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
.../drm/i915/selftests/intel_memory_region.c | 143 ++
1 file changed, 143 insertions(+)
diff --git a/drivers/gpu/drm/i915
Otherwise we get -EINVAL, instead of the more useful -E2BIG if the
allocation doesn't fit within the pfn range, like with mappable lmem.
The hugepages selftest, for example, needs this to know if a smaller
size is needed.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas
even have small BAR. A better name is GPU_ONLY,
which is accurate regardless of the configuration.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
Acked-by: Nirmoy Das
---
.../gpu/drm/i915/gem/i915_gem_object_types.h| 17 -
drivers/gpu/drm
result in an actual move, instead of being turned into a noop.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
Acked-by: Nirmoy Das
---
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/dr
off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
Acked-by: Nirmoy Das
---
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 68 ++-
drivers/gpu/drm/i915/i915_ttm_buddy_manager.h | 8 ++-
drivers/gpu/drm/i915/intel_region_ttm.c | 1 +
3 files changed,
this behaviour.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
Acked-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 4
drivers/gpu/drm/i915/intel_region_ttm.c | 5 +
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem
With small LMEM-BAR we need to be able to differentiate between the
total size of LMEM, and how much of it is CPU mappable. The end goal is
to be able to utilize the entire range, even if part of is it not CPU
accessible.
v2: also update intelfb_create
Signed-off-by: Matthew Auld
Cc: Thomas
Lucas De Marchi
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_region.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.c
b/drivers/gpu/drm/i915/gem/i915_gem_region.c
index a4350227e9ae..6d6
the alloc() returns successfully
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5123
Fixes: 0e05fc49c358 ("drm/ttm: add common accounting to the resource mgr v3")
Signed-off-by: Matthew Auld
Cc: Christian König
Cc: Thomas Hellström
Acked-by: Christian König
---
drivers/gpu/drm
We already completed the steps for this.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: mesa-...@lists.freedesktop.org
---
Documentation/gpu/rfc/i915_gem_lmem.rst | 22 --
Documentation/gpu
Add an entry for the new uapi needed for small BAR on DG2+.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: mesa-...@lists.freedesktop.org
---
Documentation/gpu/rfc/i915_small_bar.h | 153
The new bits of proposed uAPI for the upcoming small BAR support.
--
2.34.1
On Thu, 17 Feb 2022 at 17:55, Lucas De Marchi wrote:
>
> This was useful for early development of lmem, but it's not used
> anymore, so remove it.
>
> v2: Remove unneeded fields from struct intel_memory_region
>
> Cc: Chris Wilson
> Cc: Matthew Auld
> Signed-off-by
rm/i915: Fix a race between vma / object destruction and
unbinding")
Cc: Maarten Lankhorst
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
ev, and also wants to
store the bo reference. Try to keep both working. The mock_bo is a hack
so we can interface directly with the ttm managers alloc() and free() hooks for
our mock testing, without invoking other TTM features like eviction,
moves, etc.
Closes: https://gitlab.freedesktop.or
On 15/02/2022 05:31, Ramalingam C wrote:
i915_perf is not enabled for dg2 yet, hence skip the feature
initialization.
Signed-off-by: Ramalingam C
cc: Umesh Nerlige Ramappa
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_perf.c | 4
1 file changed, 4 insertions(+)
diff
On Mon, 14 Feb 2022 at 13:23, Christian König
wrote:
>
> Am 14.02.22 um 11:34 schrieb Matthew Auld:
> > On Mon, 14 Feb 2022 at 09:34, Christian König
> > wrote:
> >> It makes sense to have this in the common manager for debugging and
> >> accounting of how m
istian König
> Tested-by: Bas Nieuwenhuizen
Reviewed-by: Matthew Auld
On Mon, 14 Feb 2022 at 09:34, Christian König
wrote:
>
> This is provided by TTM now.
>
> Signed-off-by: Christian König
Reviewed-by: Matthew Auld
PORARY) &&
> - atomic64_add_return(num_pages, >used) > man->size) {
> - atomic64_sub(num_pages, >used);
I guess this behaviour is now slightly different, since TEMPORARY will
now get accounted like everything else. Hopefully that is not a
ut:
> /* update statistics */
> atomic64_add(bo->base.size, >num_bytes_moved);
> - radeon_bo_move_notify(bo, old_type, new_mem);
> + radeon_bo_move_notify(bo, new_mem);
> return 0;
> }
>
> @@ -679,16 +676,6 @@ b
INIT_LIST_HEAD(>lru[i]);
> @@ -226,6 +237,24 @@ int ttm_resource_manager_evict_all(struct ttm_device
> *bdev,
> }
> EXPORT_SYMBOL(ttm_resource_manager_evict_all);
>
> +/**
> + * ttm_resource_manager_usage
> + *
> + * @man: A memory manager object.
urce.c
> @@ -153,19 +153,19 @@ void ttm_resource_set_bo(struct ttm_resource *res,
> *
> * @man: memory manager object to init
> * @bdev: ttm device this manager belongs to
> - * @p_size: size managed area in pages.
> + * @size: size of managed resources in arbitary units
s/arb
en
> > - drm_buddy_alloc_range() becomes obsolete and may be removed
> > - enable ttm range allocation (fpfn / lpfn) support in i915 driver
> > - apply enhanced drm_buddy_alloc() function to i915 driver
> >
> > v3(Matthew Auld):
> >- Fix alignment issues a
just for the sake of having more
complete picture.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Jon Bloomfield
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 26 --
include/uapi/drm/i915_drm.h| 31 +-
2 files changed, 48 insertions
robot ):
- Also update the function signature on !CONFIG_DRM_I915_CAPTURE_ERROR
builds.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Jon Bloomfield
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git
be applied on objects that can be
placed in LMEM. The other annoyance would be gem_create_ext vs plain
gem_create, if we were to always apply GPU_ONLY.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Jon Bloomfield
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 8
1 file
placements permit it.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 54 ++---
1 file changed, 48 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu
hopefully victimize these last.
v2(Thomas): s/TTM_PL_PRIV/I915_PL_LMEM0/
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 65 -
1 file changed, 63 insertions(+), 2 deletions(-)
diff --git
Exercise each of the migration scenarios, verifying that the final
placement and buffer contents match our expectations.
v2(Thomas): Replace for_i915_gem_ww() block with simpler object_lock()
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
.../drm/i915/gem
will return -ENOMEM, in ttm_bo_mem_space() after
exhausting all possible placements.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
Acked-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 2 +-
drivers/gpu/drm/i915/selftests
Just pass along the probed io_size. The backend should be able to
utilize the entire range here, even if some of it is non-mappable.
It does leave open with what to do with stolen local-memory.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm
Check that mappable vs non-mappable matches our expectations.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
.../drm/i915/selftests/intel_memory_region.c | 143 ++
1 file changed, 143 insertions(+)
diff --git a/drivers/gpu/drm/i915
result in an actual move, instead of being turned into a noop.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
Acked-by: Nirmoy Das
---
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/dr
even have small BAR. A better name is GPU_ONLY,
which is accurate regardless of the configuration.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
Acked-by: Nirmoy Das
---
.../gpu/drm/i915/gem/i915_gem_object_types.h| 17 -
drivers/gpu/drm
Otherwise we get -EINVAL, instead of the more useful -E2BIG if the
allocation doesn't fit within the pfn range, like with mappable lmem.
The hugepages selftest, for example, needs this to know if a smaller
size is needed.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas
off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
Acked-by: Nirmoy Das
---
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 68 ++-
drivers/gpu/drm/i915/i915_ttm_buddy_manager.h | 8 ++-
drivers/gpu/drm/i915/intel_region_ttm.c | 1 +
3 files changed,
this behaviour.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
Acked-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 4
drivers/gpu/drm/i915/intel_region_ttm.c | 5 +
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem
With small LMEM-BAR we need to be able to differentiate between the
total size of LMEM, and how much of it is CPU mappable. The end goal is
to be able to utilize the entire range, even if part of is it not CPU
accessible.
v2: also update intelfb_create
Signed-off-by: Matthew Auld
Cc: Thomas
Starting from DG2 we will have resizable BAR support for device local-memory,
but in some cases the final BAR size might still be smaller than the total
local-memory size. In such cases only part of local-memory will be CPU
accessible, while the remainder is only accessible via the GPU. This
On Fri, 11 Feb 2022 at 09:56, Thomas Hellström
wrote:
>
>
> On 2/11/22 10:52, Matthew Auld wrote:
> > On Fri, 11 Feb 2022 at 09:49, Thomas Hellström
> > wrote:
> >>
> >> On 2/10/22 13:13, Matthew Auld wrote:
> >>> Starting from DG2+, when dea
On Fri, 11 Feb 2022 at 09:49, Thomas Hellström
wrote:
>
>
> On 2/10/22 13:13, Matthew Auld wrote:
> > Starting from DG2+, when dealing with LMEM, we assume that by default
> > all userspace allocations should be placed in the non-mappable portion
> > of LM
On 08/02/2022 11:20, Arunpravin wrote:
On 04/02/22 6:53 pm, Christian König wrote:
Am 04.02.22 um 12:22 schrieb Arunpravin:
On 28/01/22 7:48 pm, Matthew Auld wrote:
On Thu, 27 Jan 2022 at 14:11, Arunpravin
wrote:
- Remove drm_mm references and replace with drm buddy functionalities
- Add
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
robot ):
- Also update the function signature on !CONFIG_DRM_I915_CAPTURE_ERROR
builds.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915
IGTs. Including now just for the sake
of having more complete picture.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 28 ---
include/uapi/drm/i915_drm.h| 31 +-
2 files changed, 49 insertions
will return -ENOMEM, in ttm_bo_mem_space() after
exhausting all possible placements.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 2 +-
drivers/gpu/drm/i915/selftests/intel_memory_region.c | 8 +++-
2 files changed, 8 insertions(+), 2
userspace will be able to provide a hint if CPU access
to the buffer is needed.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/dr
Just pass along the probed io_size. The backend should be able to
utilize the entire range here, even if some of it is non-mappable.
It does leave open with what to do with stolen local-memory.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gt/intel_region_lmem.c
placements permit it.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 54 ++---
1 file changed, 48 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu
hopefully victimize these last.
v2(Thomas): s/TTM_PL_PRIV/I915_PL_LMEM0/
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 65 -
1 file changed, 63 insertions(+), 2 deletions(-)
diff --git
Check that mappable vs non-mappable matches our expectations.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
.../drm/i915/selftests/intel_memory_region.c | 143 ++
1 file changed, 143 insertions(+)
diff --git a/drivers/gpu/drm/i915
Exercise each of the migration scenarios, verifying that the final
placement and buffer contents match our expectations.
v2(Thomas): Replace for_i915_gem_ww() block with simpler object_lock()
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c
Otherwise we get -EINVAL, instead of the more useful -E2BIG if the
allocation doesn't fit within the pfn range, like with mappable lmem.
The hugepages selftest, for example, needs this to know if a smaller
size is needed.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas
off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 68 ++-
drivers/gpu/drm/i915/i915_ttm_buddy_manager.h | 8 ++-
drivers/gpu/drm/i915/intel_region_ttm.c | 1 +
3 files changed, 75 insertions(+), 2 deletions(-)
diff --git a/drivers/
result in an actual move, instead of being turned into a noop.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
b/d
even have small BAR. A better name is GPU_ONLY,
which is accurate regardless of the configuration.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
.../gpu/drm/i915/gem/i915_gem_object_types.h| 17 -
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 3 +++
drivers
this behaviour.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 4
drivers/gpu/drm/i915/intel_region_ttm.c | 5 +
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem
With small LMEM-BAR we need to be able to differentiate between the
total size of LMEM, and how much of it is CPU mappable. The end goal is
to be able to utilize the entire range, even if part of is it not CPU
accessible.
v2: also update intelfb_create
Signed-off-by: Matthew Auld
Cc: Thomas
Starting from DG2 we will have resizable BAR support for device local-memory,
but in some cases the final BAR size might still be smaller than the total
local-memory size. In such cases only part of local-memory will be CPU
accessible, while the remainder is only accessible via the GPU. This
For some reason we are selecting PRIO_HAS_PAGES when we don't have
mm.pages, and vice versa.
v2(Thomas):
- Add missing fixes tag
Fixes: 213d50927763 ("drm/i915/ttm: Introduce a TTM i915 gem object backend")
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas
On Wed, 9 Feb 2022 at 08:41, Christian König
wrote:
>
> This way we finally fix the problem that new resource are
> not immediately evict-able after allocation.
>
> That has caused numerous problems including OOM on GDS handling
> and not being able to use TTM as general resource manager.
>
> v2:
On Wed, 9 Feb 2022 at 08:41, Christian König
wrote:
>
> This is provided by TTM now.
>
> Also switch man->size to bytes instead of pages and fix the double
> printing of size and usage in debugfs.
>
> Signed-off-by: Christian König
> Tested-by: Bas Nieuwenhuizen
> ---
>
Make sure we pull in the kernel-doc for this.
Reported-by: Daniel Vetter
Signed-off-by: Matthew Auld
Cc: Arunpravin
Cc: Christian König
---
Documentation/gpu/drm-mm.rst | 9 +
1 file changed, 9 insertions(+)
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
on i915_buddy removal
Fixes: 14d1b9a6247c ("drm/i915: buddy allocator")
Signed-off-by: Matthew Auld
Cc: Arunpravin
Cc: Christian König
---
drivers/gpu/drm/drm_buddy.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/d
in .config
Signed-off-by: Arunpravin
At some point I guess we also want some IGT that picks this up? Like we
do in tests/drm_mm.c? That way this can get picked up by CI?
Acked-by: Matthew Auld
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/selftests/Makefile
err = drm_buddy_alloc_blocks(, start, mm_size, size,
min_page_size, , flags);
+ if (err) {
+ pr_info("buddy_alloc hit -ENOME for hole\n");
ENOMEM
Reviewed-by: Matthew Auld
+ goto err;
+
pr_err("alloc_blocks has no blocks\n");
+ err = -EINVAL;
+ break;
+ }
+
+ list_del(>link);
+ list_add_tail(>link, );
Could just make this list_move_ta
link);
+ if (!block) {
+ pr_err("alloc_blocks has no blocks\n");
+ err = -EINVAL;
+ goto err;
+ }
+
+ list_del(>link);
+ drm_buddy_free_block(, block);
+
+ if (!err)
Always true?
Reviewed-by: Matthew Auld
+ pr_info("%
On 03/02/2022 13:32, Arunpravin wrote:
create a mm with one block of each order available, and
try to allocate them all.
Signed-off-by: Arunpravin
Reviewed-by: Matthew Auld
erations."
?
Anyway,
Reviewed-by: Matthew Auld
+ *
+ * @block: DRM buddy block
+ */
+struct drm_buddy_block *
+drm_get_buddy(struct drm_buddy_block *block)
+{
+ return __get_buddy(block);
+}
+EXPORT_SYMBOL(drm_get_buddy);
+
static void __drm_buddy_free(struct
if (!err)
Always true AFAICT?
+ pr_info("%s - succeeded\n", __func__);
I guess this could be made part of the run_selftests()? It looks like it
already prints the current test, perhaps that is already enough?
With the err = -EINVAL change, feel free to add,
On 07/02/2022 11:48, Matthew Auld wrote:
On Fri, 28 Jan 2022 at 18:52, Ramalingam C wrote:
An indirect ctx wabb is implemented as per Wa_22011450934 to avoid rcs
restore hang during context restore of a preempted context in GPGPU mode
Signed-off-by: Ramalingam C
cc: Chris Wilson
Acked
On Fri, 28 Jan 2022 at 18:52, Ramalingam C wrote:
>
> An indirect ctx wabb is implemented as per Wa_22011450934 to avoid rcs
> restore hang during context restore of a preempted context in GPGPU mode
>
> Signed-off-by: Ramalingam C
> cc: Chris Wilson
Acked-by: Matthew Auld
On 03/02/2022 13:56, Thomas Hellström wrote:
On Thu, 2022-02-03 at 11:18 +, Matthew Auld wrote:
On 03/02/2022 09:48, Thomas Hellström wrote:
On 1/26/22 16:21, Matthew Auld wrote:
Just pass along the probed io_size. The backend should be able to
utilize the entire range here, even if some
On 03/02/2022 09:28, Thomas Hellström wrote:
On 1/26/22 16:21, Matthew Auld wrote:
If set, force the allocation to be placed in the mappable portion of
LMEM. One big restriction here is that system memory must be given as a
potential placement for the object, that way we can always spill
On 03/02/2022 09:48, Thomas Hellström wrote:
On 1/26/22 16:21, Matthew Auld wrote:
Just pass along the probed io_size. The backend should be able to
utilize the entire range here, even if some of it is non-mappable.
Changes here LGTM.
It does leave open with what to do with stolen local
On 03/02/2022 09:43, Thomas Hellström wrote:
On 1/26/22 16:21, Matthew Auld wrote:
On platforms where there might be non-mappable LMEM, force userspace to
mark the buffers with the correct hint. When dumping the BO contents
during capture we need CPU access. Note this only applies to buffers
On 03/02/2022 09:17, Thomas Hellström wrote:
On 1/26/22 16:21, Matthew Auld wrote:
Starting from DG2+, when dealing with LMEM, we assume that by default
all userspace allocations should be placed in the non-mappable portion
of LMEM. Note that dumb buffers are not included here, since
On 03/02/2022 09:01, Thomas Hellström wrote:
On 1/26/22 16:21, Matthew Auld wrote:
Exercise each of the migration scenarios, verifying that the final
placement and buffer contents match our expectations.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
.../drm/i915/gem/selftests
On 03/02/2022 09:05, Thomas Hellström wrote:
On 1/26/22 16:21, Matthew Auld wrote:
If we have to contend with non-mappable LMEM, then we need to ensure the
object fits within the mappable portion, like in the selftests, where we
later try to CPU access the pages. However if it can't then we
this might prove to be potentially useful.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_region.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.c
b/drivers/gpu/drm/i915/gem/i915_gem_region.c
index a4350227e9ae
On 01/02/2022 10:41, Ramalingam C wrote:
From: Matthew Auld
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).
v2: Rebased [Ram]
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc
propagate those codes, rather
than retrying with a memcpy move.
Fixes: 2b0a750caf33 ("drm/i915/ttm: Failsafe migration blits")
Cc: Matthew Auld
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
On 31/01/2022 15:28, Thomas Hellström wrote:
On 1/26/22 16:21, Matthew Auld wrote:
If the user doesn't require CPU access for the buffer, then
ALLOC_TOPDOWN should be used, in order to prioritise allocating in the
non-mappable portion of LMEM.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
ed-off-by: Ramalingam C
Acked-by: Matthew Auld
On Mon, 31 Jan 2022 at 10:18, Matthew Auld wrote:
>
> On 28/01/2022 18:52, Ramalingam C wrote:
> > Align the plane vma size to the stolem memory regions' min_page_size.
> >
> > Signed-off-by: Ramalingam C
> > cc: Matthew Auld
> > cc: Chris P Wilson
>
401 - 500 of 1542 matches
Mail list logo
