On 15/04/2024 19:14, Matt Roper wrote:
On Mon, Apr 15, 2024 at 10:07:32AM -0700, Matt Roper wrote:
On Mon, Apr 15, 2024 at 01:44:22PM +0530, Balasubramani Vivekanandan wrote:
From: Matthew Auld
Perform manual transient cache flush prior to flip and at the end of
frontbuffer_flush
more cases
v3: Provide a separate fix for xe_tile_init_noalloc return (Matt)
Adding a new case where display HDCP init calls which
are also called at display probe time.
Cc: Matthew Auld
Signed-off-by: Rodrigo Vivi
Reviewed-by: Matthew Auld
On 07/03/2024 12:25, Paneer Selvam, Arunpravin wrote:
Hi Matthew,
On 3/6/2024 11:19 PM, Matthew Auld wrote:
On 04/03/2024 16:32, Arunpravin Paneer Selvam wrote:
- Add tracking clear page feature.
- Driver should enable the DRM_BUDDY_CLEARED flag if it
successfully clears the blocks
-by: Arunpravin Paneer Selvam
Signed-off-by: Matthew Auld
Suggested-by: Christian König
Suggested-by: Matthew Auld
Is there a unit test for this? What about maybe something roughly like:
- Pick small random mm_size which is not always power-of-two.
- Allocate and free some random portion of the address
On 04/03/2024 12:22, Paneer Selvam, Arunpravin wrote:
Hi Matthew,
On 2/22/2024 12:12 AM, Matthew Auld wrote:
On 21/02/2024 12:18, Arunpravin Paneer Selvam wrote:
Add a function to support defragmentation.
v1:
- Defragment the memory beginning from min_order
till the required memory
allocation and registration
soc: qcom: pmic_glink_altmode: fix drm bridge use-after-free
Matthew Auld (3):
drm/buddy: fix range bias
drm/buddy: check range allocation matches alignment
drm/tests/drm_buddy: add alloc_range_bias test
Note that there is a build fix needed
On 26/02/2024 20:21, Thomas Hellström wrote:
Hi, Christian
On Fri, 2024-02-23 at 15:30 +0100, Christian König wrote:
Am 06.02.24 um 13:56 schrieb Christian König:
Am 06.02.24 um 13:53 schrieb Thomas Hellström:
Hi, Christian,
On Fri, 2024-01-26 at 15:09 +0100, Christian König wrote:
Suggested-by: Matthew Auld
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 17 +++-
drivers/gpu/drm/drm_buddy.c | 93 +---
include/drm/drm_buddy.h | 3 +
3 files changed, 97 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd
On 21/02/2024 12:40, Paneer Selvam, Arunpravin wrote:
On 2/16/2024 5:33 PM, Matthew Auld wrote:
On 08/02/2024 15:49, Arunpravin Paneer Selvam wrote:
- Add tracking clear page feature.
- Driver should enable the DRM_BUDDY_CLEARED flag if it
successfully clears the blocks in the free path
top.org
Cc: # v6.4+
Reviewed-by: Matthew Auld
On 16/02/2024 14:02, Christian König wrote:
Am 16.02.24 um 14:21 schrieb Matthew Auld:
On 16/02/2024 12:33, Christian König wrote:
Am 16.02.24 um 13:23 schrieb Matthew Auld:
On 08/02/2024 15:50, Arunpravin Paneer Selvam wrote:
Add a function to support defragmentation.
v1: Defragment
On 16/02/2024 12:33, Christian König wrote:
Am 16.02.24 um 13:23 schrieb Matthew Auld:
On 08/02/2024 15:50, Arunpravin Paneer Selvam wrote:
Add a function to support defragmentation.
v1: Defragment the memory beginning from min_order
till the required memory space is available.
Signed
On 08/02/2024 15:50, Arunpravin Paneer Selvam wrote:
Add a function to support defragmentation.
v1: Defragment the memory beginning from min_order
till the required memory space is available.
Signed-off-by: Arunpravin Paneer Selvam
Suggested-by: Matthew Auld
---
drivers/gpu/drm
the required blocks.
- Update the xe driver for the drm_buddy_free_list change in arguments.
Signed-off-by: Arunpravin Paneer Selvam
Signed-off-by: Matthew Auld
Suggested-by: Christian König
Probably needs a new unit test.
I think we are missing something to forcefully re-merge everything
t_splice_tail(, blocks);
Sigh. Can we extend the unit test(s) to catch this?
Reviewed-by: Matthew Auld
+
return 0;
err_undo:
base-commit: a64056bb5a3215bd31c8ce17d609ba0f4d5c55ea
On 13/02/2024 13:52, Arunpravin Paneer Selvam wrote:
Sanity check DRM_BUDDY_CONTIGUOUS_ALLOCATION.
References: https://gitlab.freedesktop.org/drm/amd/-/issues/3097
Signed-off-by: Matthew Auld
Reviewed-by: Arunpravin Paneer Selvam
It looks like you changed the patch authorship here.
Cc
On 08/02/2024 14:17, Matthew Auld wrote:
On 08/02/2024 13:47, Arunpravin Paneer Selvam wrote:
Hi Matthew,
On 2/8/2024 7:00 PM, Matthew Auld wrote:
On 07/02/2024 17:44, Arunpravin Paneer Selvam wrote:
Few users have observed display corruption when they boot
the machine to KDE Plasma
On 08/02/2024 13:47, Arunpravin Paneer Selvam wrote:
Hi Matthew,
On 2/8/2024 7:00 PM, Matthew Auld wrote:
On 07/02/2024 17:44, Arunpravin Paneer Selvam wrote:
Few users have observed display corruption when they boot
the machine to KDE Plasma or playing games. We have root
caused the problem
On 07/02/2024 17:44, Arunpravin Paneer Selvam wrote:
Few users have observed display corruption when they boot
the machine to KDE Plasma or playing games. We have root
caused the problem that whenever alloc_range() couldn't
find the required memory blocks the function was returning
SUCCESS in
On 26/01/2024 21:08, Juha-Pekka Heikkila wrote:
Display engine support ccs only with tile4, prevent other modifiers
from using compressed memory. Store pin time pat index to xe_bo.
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/xe/display/xe_fb_pin.c | 19 +++
1 file
On 26/01/2024 21:08, Juha-Pekka Heikkila wrote:
Store pat index from xe_vma to xe_bo and check if bo was pinned
as framebuffer and verify pat index is not changing for pinned
framebuffers.
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/xe/xe_pt.c | 23 +++
1 file
On 22/01/2024 18:26, Juha-Pekka Heikkila wrote:
Hi Matthew, thanks for looking into these. Below few thoughts.
On 19.1.2024 17.45, Matthew Auld wrote:
On 18/01/2024 15:27, Juha-Pekka Heikkila wrote:
Store pat index from xe_vma to xe_bo
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu
On 23/01/2024 08:05, Ville Syrjälä wrote:
On Fri, Jan 19, 2024 at 03:45:22PM +, Matthew Auld wrote:
On 18/01/2024 15:27, Juha-Pekka Heikkila wrote:
Store pat index from xe_vma to xe_bo
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/xe/xe_pt.c | 4
1 file changed, 4
On 18/01/2024 15:27, Juha-Pekka Heikkila wrote:
Store pat index from xe_vma to xe_bo
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/xe/xe_pt.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/xe/xe_pt.c b/drivers/gpu/drm/xe/xe_pt.c
index
On 18/01/2024 15:27, Juha-Pekka Heikkila wrote:
Display engine support ccs only with tile4, prevent other modifiers
from using compressed memory.
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/xe/display/xe_fb_pin.c | 17 +
1 file changed, 17 insertions(+)
diff
n the corner case where the
alignment doesn't fit the min_block_size?
Anyway, for patches 1-3,
Reviewed-by: Matthew Auld
+ } else if (err != -ENOSPC) {
+ drm_buddy_free_list(mm, blocks);
+ return err;
+ }
+
Hi,
On 21/08/2023 11:14, Arunpravin Paneer Selvam wrote:
The way now contiguous requests are implemented such that
the size rounded up to power of 2 and the corresponding order
block picked from the freelist.
In addition to the older method, the new method will rounddown
the size to power of 2
On Sat, 1 Apr 2023 at 07:37, wrote:
>
> From: Fei Yang
>
> To comply with the design that buffer objects shall have immutable
> cache setting through out its life cycle, {set, get}_caching ioctl's
> are no longer supported from MTL onward. With that change caching
> policy can only be set at
e. Easiest use case to observe
> this behaviour was with a full screen clients with close to 100% engine
> load.
>
> Signed-off-by: Tvrtko Ursulin
> Fixes: bb6287cb1886 ("drm/i915: Track context current active time")
> Cc: # v5.19+
Seems reasonable to me, fwiw,
Reviewed-by: Matthew Auld
the object pinned
should also prevent that.
Cc: sta...@vger.kernel.org
Cc: Juha-Pekka Heikkila
Cc: Matthew Auld
Cc: Imre Deak
Fixes: 0dc987b699ce ("drm/i915/display: Add smem fallback allocation for dpt")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dpt.c
On Wed, 15 Mar 2023 at 18:41, Christian König
wrote:
>
> Am 08.03.23 um 13:43 schrieb Steven Rostedt:
> > On Wed, 8 Mar 2023 07:17:38 +0100
> > Christian König wrote:
> >
> >> What test case/environment do you run to trigger this?
> > I'm running a 32bit x86 qemu instance. Attached is the
Marchi,
Lucas ; chris.p.wil...@linux.intel.com
Subject: Re: [PATCH v5 1/2] drm/i915: Migrate platform-dependent mock hugepage
selftests to live
On 28/02/2023 14:08, Matthew Auld wrote:
On 27/02/2023 17:19, Jonathan Cavitt wrote:
Convert the igt_mock_ppgtt_huge_fill and igt_mock_ppgtt_64K mock
On Mon, 13 Mar 2023 at 09:39, Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> Remove the unused i915 variable to fix the build with WERROR=y.
>
> Cc: Lucas De Marchi
> Fixes: d1b3657fb5b6 ("drm/i915: Remove redundant check for DG1")
> Signed-off-by: Ville Syrjälä
Reviewed-by: Matthew Auld
fences upon request
completion to ensure that we have a reliable perpetuation of the
operation outcome.
Fixes: cf586021642d80 ("drm/i915/gt: Pipelined page migration")
Reported-by: Matthew Auld
Suggested-by: Chris Wilson
Signed-off-by: Andi Shyti
Cc: sta...@vger.kernel.org
Reviewed-b
On 06/03/2023 13:31, Das, Nirmoy wrote:
Hi Matt,
On 3/6/2023 1:25 PM, Matthew Auld wrote:
On 06/03/2023 12:07, Nirmoy Das wrote:
Framebuffer is exposed to userspace so set I915_BO_ALLOC_USER
flag for it. This also make sure that ttm allocates offset
for lmem objects.
Signed-off-by: Nirmoy
On 06/03/2023 12:07, Nirmoy Das wrote:
Framebuffer is exposed to userspace so set I915_BO_ALLOC_USER
flag for it. This also make sure that ttm allocates offset
for lmem objects.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/display/intel_dpt.c | 4 +++-
On 28/02/2023 14:08, Matthew Auld wrote:
On 27/02/2023 17:19, Jonathan Cavitt wrote:
Convert the igt_mock_ppgtt_huge_fill and igt_mock_ppgtt_64K mock
selftests into
live selftests as their requirements have recently become
platform-dependent.
Additionally, apply necessary platform dependency
On 27/02/2023 17:19, Jonathan Cavitt wrote:
Convert the igt_mock_ppgtt_huge_fill and igt_mock_ppgtt_64K mock selftests into
live selftests as their requirements have recently become platform-dependent.
Additionally, apply necessary platform dependency checks to these tests.
v2: Reorder
only a selftest so likely meh in practice, but in general we should
always try to keep every commit functional/bisectable.
Otherwise for the series,
Reviewed-by: Matthew Auld
---
.../gpu/drm/i915/gem/selftests/huge_pages.c | 22 ++-
1 file changed, 17 insertions(+), 5
On 27/02/2023 15:06, Cavitt, Jonathan wrote:
-Original Message-
From: Auld, Matthew
Sent: Monday, February 27, 2023 3:20 AM
To: Cavitt, Jonathan ;
intel-gfx@lists.freedesktop.org
Cc: Dutt, Sudeep ; thomas.hellst...@linux.intel.com;
maarten.lankho...@linux.intel.com; Vetter, Daniel ;
On 24/02/2023 17:40, Jonathan Cavitt wrote:
MTL currently uses gen8_ppgtt_insert_huge when managing huge pages. This is
because
MTL reports as not supporting 64K pages, or more accurately, the system that
reports
whether a platform has 64K pages reports false for MTL. This is only half
; De Marchi,
Lucas ; chris.p.wil...@linux.intel.com
Subject: Re: [PATCH] drm/i915: Use correct huge page manager for MTL
On 22/02/2023 15:56, Matthew Auld wrote:
On 22/02/2023 15:26, Jonathan Cavitt wrote:
MTL currently uses gen8_ppgtt_insert_huge when managing huge pages.
This is because
MTL
On 22/02/2023 15:56, Matthew Auld wrote:
On 22/02/2023 15:26, Jonathan Cavitt wrote:
MTL currently uses gen8_ppgtt_insert_huge when managing huge pages.
This is because
MTL reports as not supporting 64K pages, or more accurately, the
system that reports
whether a platform has 64K pages
s failed and
> whether the memory is still invalid.
>
> On copy and clear migration signal fences upon completion.
>
> Fixes: cf586021642d80 ("drm/i915/gt: Pipelined page migration")
> Reported-by: Matthew Auld
> Suggested-by: Chris Wilson
> Signed-off-by: Andi Shyti
> Cc: sta...@vger.kernel.org
Reviewed-by: Matthew Auld
to be properly reported by the GTT, so we
should
remove the check that asserts otherwise.
Signed-off-by: Jonathan Cavitt
Hopefully CI will be happy now,
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 3 ---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c
for the page table to be flushed after initialization, so we must
also
add a flush statement there.
Signed-off-by: Jonathan Cavitt
Reviewed-by: Matthew Auld
Although it looks like the hugepage mock tests are failing with this. I
assume the mock device just uses some "max" gen ver
for the page table to be flushed after initialization, so we must
also
add a flush statement there.
Signed-off-by: Jonathan Cavitt
Reviewed-by: Matthew Auld
Although it looks like the hugepage mock tests are failing with this. I
assume the mock device just uses some "max" gen version or
On Fri, 17 Feb 2023 at 12:23, Christian König
wrote:
>
> We don't need multiple drm_mm nodes any more. Clean that up and remove
> the extra complexity.
>
> Signed-off-by: Christian König
Reviewed-by: Matthew Auld
On Fri, 17 Feb 2023 at 12:23, Christian König
wrote:
>
> From: Somalapuram Amaranath
>
> ttm_resource can allocate size in bytes to support less than page size.
>
> Signed-off-by: Somalapuram Amaranath
> Reviewed-by: Christian König
> Signed-off-by: Christian König
> Link:
>
for the page table to be flushed after initialization, so we must
also
add a flush statement there.
Signed-off-by: Jonathan Cavitt
Reviewed-by: Matthew Auld
Although it looks like the hugepage mock tests are failing with this. I
assume the mock device just uses some "max" gen version or
On 21/02/2023 16:17, Christian König wrote:
Am 21.02.23 um 17:13 schrieb Matthew Auld:
On 10/02/2023 11:03, Christian König wrote:
Am 08.02.23 um 15:53 schrieb Matthew Auld:
The ttm BO now initially has NULL bo->resource, and leaves the driver
the handle that. However it looks like we for
On 10/02/2023 11:03, Christian König wrote:
Am 08.02.23 um 15:53 schrieb Matthew Auld:
The ttm BO now initially has NULL bo->resource, and leaves the driver
the handle that. However it looks like we forgot to handle that for
ttm_bo_move_memcpy() users, like with vram-gem, since it just silen
On 21/02/2023 16:06, Matthew Auld wrote:
On 17/02/2023 19:18, Jonathan Cavitt wrote:
MTL currently uses gen8_ppgtt_insert_huge when managing huge pages.
This is because
MTL reports as not supporting 64K pages, or more accurately, the
system that reports
whether a platform has 64K pages
for the page table to be flushed after initialization, so we must
also
add a flush statement there.
Signed-off-by: Jonathan Cavitt
Reviewed-by: Matthew Auld
Although it looks like the hugepage mock tests are failing with this. I
assume the mock device just uses some "max" gen version or
On Tue, 14 Feb 2023 at 07:43, Christian König
wrote:
>
> From: Somalapuram Amaranath
>
> Change the ttm_range_man_alloc() allocation from pages to size in bytes.
> Fix the dependent drm_mm_nodes start and size from pages to bytes.
>
> v2 (chk): Change the drm_mm_node usage in amdgpu as well.
("drm/ttm: stop allocating dummy resources during BO
creation")
Signed-off-by: Matthew Auld
Cc: Christian König
---
drivers/gpu/drm/radeon/radeon_ttm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/ra
source is TTM_PL_SYSTEM,
otherwise do the multi-hop sequence to ensure can safely call into
ttm_bo_move_memcpy(), since it might also need to clear the memory.
This should give the same behaviour as before.
Fixes: 180253782038 ("drm/ttm: stop allocating dummy resources during BO
creation")
Signed-off-
ame behaviour as before.
While we are here let's also treat calling ttm_bo_move_memcpy() with
NULL bo->resource as programmer error, where expectation is that upper
layers should now handle it.
Fixes: 180253782038 ("drm/ttm: stop allocating dummy resources during BO
creation")
Signed-off-
source is TTM_PL_SYSTEM,
otherwise do the multi-hop sequence to ensure can safely call into
ttm_bo_move_memcpy(), since it might also need to clear the memory.
This should give the same behaviour as before.
Fixes: 180253782038 ("drm/ttm: stop allocating dummy resources during BO
creation")
Signed-off-
On 08/02/2023 11:29, Andrzej Hajda wrote:
On 08.02.2023 12:17, Andrzej Hajda wrote:
On 08.02.2023 12:03, Matthew Auld wrote:
On 08/02/2023 10:51, Andrzej Hajda wrote:
Write-combining memory allows speculative reads by CPU.
ggtt->error_capture is WC mapped to CPU, so CPU/MMU can
On 08/02/2023 10:51, Andrzej Hajda wrote:
Write-combining memory allows speculative reads by CPU.
ggtt->error_capture is WC mapped to CPU, so CPU/MMU can try
to prefetch memory beyond the error_capture, ie it tries
to read memory pointed by next PTE in GGTT.
If this PTE points to invalid address
On Tue, 7 Feb 2023 at 17:19, Dixit, Ashutosh wrote:
>
> On Tue, 07 Feb 2023 08:12:25 -0800, Dixit, Ashutosh wrote:
> >
> > On Tue, 07 Feb 2023 01:32:44 -0800, Matthew Auld wrote:
> > >
> > > On Fri, 3 Feb 2023 at 15:54, Ashutosh Dixit
> > >
On Fri, 3 Feb 2023 at 15:54, Ashutosh Dixit wrote:
>
> Previous documentation suggested that PL1 power limit is always
> enabled. However we now find this not to be the case on some
> platforms (such as ATSM). Therefore enable PL1 power limit during hwmon
> initialization.
For some reason it
On 06/02/2023 09:45, Tvrtko Ursulin wrote:
Hi,
Adding Matt & Thomas as potential candidates to review.
Regards,
Tvrtko
On 03/02/2023 19:30, Deepak R Varma wrote:
The macro definition of gen6_for_all_pdes() expands to a for loop such
that it breaks when the page table is null. Hence there
On 03/02/2023 12:10, Tvrtko Ursulin wrote:
On 03/02/2023 11:57, Aravind Iddamsetty wrote:
Obj flags for shmem objects is not being set correctly.
Cc: Matthew Auld
Signed-off-by: Aravind Iddamsetty
Could even be:
Fixes: 13d29c823738 ("drm/i915/ehl: unconditionally flush the
On 03/02/2023 11:57, Aravind Iddamsetty wrote:
Obj flags for shmem objects is not being set correctly.
Cc: Matthew Auld
Signed-off-by: Aravind Iddamsetty
Subject should have "drm/i915:" prefix.
This is also a bug fix due to not setting BO_ALLOC_USER (the other flags
don't seem
On Wed, 25 Jan 2023 at 16:24, Matthew Auld
wrote:
>
> On Wed, 25 Jan 2023 at 16:15, Christian König
> wrote:
> >
> > Am 25.01.23 um 17:13 schrieb Matthew Auld:
> > > On Wed, 25 Jan 2023 at 15:50, Christian König
> > > wrote:
> > >> This reve
-by: Christian König
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4
drivers/gpu/drm/nouveau/nouveau_bo.c| 3 ---
drivers/gpu/drm/radeon/radeon_ttm.c | 4
drivers/gpu/drm/ttm/ttm_bo.c| 20
ial ttm_tt would be created in
ttm_bo_validate() with the clear parameter always set to true.
Signed-off-by: Matthew Auld
Cc: Christian König
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/
r make i915_ttm_cpu_maps_iomem() return false with NULL
resource.
References: 516198d317d8 ("drm/i915: audit bo->resource usage v3")
Signed-off-by: Matthew Auld
Cc: Christian König
Cc: Nirmoy Das
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 10 --
drive
From: Christian König
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: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/ttm/ttm_bo.c | 7 ---
1 file changed, 7
From: Christian König
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: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 15 ++-
1 file
: kernel test robot
Signed-off-by: Matthew Auld
Cc: Christian König
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_ge
On Mon, 30 Jan 2023 at 11:00, Andrzej Hajda wrote:
>
> On 30.01.2023 11:12, Matthew Auld wrote:
> > In the near future TTM will have NULL bo->resource when the object is
> > initially created, plus after calling into pipeline-gutting. Try to
> > handle the remaining
From: Christian König
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: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/ttm/ttm_bo.c | 7 ---
1 file changed, 7
From: Christian König
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: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 15 ++-
1 file
ial ttm_tt would be created in
ttm_bo_validate() with the clear parameter always set to true.
Signed-off-by: Matthew Auld
Cc: Christian König
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/
-by: Christian König
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4
drivers/gpu/drm/nouveau/nouveau_bo.c| 3 ---
drivers/gpu/drm/radeon/radeon_ttm.c | 4
drivers/gpu/drm/ttm/ttm_bo.c| 20
: kernel test robot
Signed-off-by: Matthew Auld
Cc: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 7420276827a5..4758f2
5: audit bo->resource usage v3")
Signed-off-by: Matthew Auld
Cc: Christian König
Cc: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 12 +---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 7 ++-
drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c | 7 +--
At the very least, we have some tests that force the BAR size for
testing purposes, which would result in different BAR size with
stolen-lmem vs normal lmem, since the BAR is only resized as part of the
normal lmem probing.
Signed-off-by: Matthew Auld
Cc: Andrzej Hajda
Cc: Nirmoy Das
> which changed significantly how this works, perhaps there is something
> still somewhat easily retrievable from your memory lanes to help with this?
Sorry for the delay. Fix looks good to me,
Reviewed-by: Matthew Auld
Looking at the git history, the fixes tag I think needs to be:
Fixes: 9e
y GTT eviction with contended
locks")
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
tests/i915/gem_ppgtt.c | 30 ++
1 file changed, 14 insertions(+), 16 deletions(-)
diff --git a/tests/i915/gem_ppgtt.c b/tests/i915/gem_ppg
On Wed, 25 Jan 2023 at 16:15, Christian König wrote:
>
> Am 25.01.23 um 17:13 schrieb Matthew Auld:
> > On Wed, 25 Jan 2023 at 15:50, Christian König
> > wrote:
> >> This reverts commit 00984ad39599bb2a1e6ec5d4e9c75a749f7f45c9.
> >>
> >> It seems to
On Wed, 25 Jan 2023 at 15:50, Christian König
wrote:
>
> This reverts commit 00984ad39599bb2a1e6ec5d4e9c75a749f7f45c9.
>
> It seems to still breka i915.
We also need to revert the third patch:
b49323aa35d5 drm/ttm: prevent moving of pinned BOs
It introduces the side effect of no longer calling
On Wed, 25 Jan 2023 at 14:20, Christian König
wrote:
>
> Am 25.01.23 um 13:53 schrieb Matthew Auld:
> > On Wed, 25 Jan 2023 at 11:35, Christian König
> > wrote:
> >> Am 25.01.23 um 11:21 schrieb Matthew Auld:
> >>> On Wed, 25 Jan 2023 at 10:07, Christian Kö
On Wed, 25 Jan 2023 at 11:35, Christian König
wrote:
>
> Am 25.01.23 um 11:21 schrieb Matthew Auld:
> > On Wed, 25 Jan 2023 at 10:07, Christian König
> > wrote:
> >> Am 25.01.23 um 10:56 schrieb Matthew Auld:
> >>> On Tue, 24 Jan 2023 at 17:15, Matthew A
On Wed, 25 Jan 2023 at 10:07, Christian König
wrote:
>
>
>
> Am 25.01.23 um 10:56 schrieb Matthew Auld:
> > On Tue, 24 Jan 2023 at 17:15, Matthew Auld
> > wrote:
> >> On Tue, 24 Jan 2023 at 13:48, Matthew Auld
> >> wrote:
> >>> On T
On Tue, 24 Jan 2023 at 17:15, Matthew Auld
wrote:
>
> On Tue, 24 Jan 2023 at 13:48, Matthew Auld
> wrote:
> >
> > On Tue, 24 Jan 2023 at 12:57, Christian König
> > wrote:
> > >
> > > From: Christian König
> > >
> > > Make sure
On Tue, 24 Jan 2023 at 13:48, Matthew Auld
wrote:
>
> On Tue, 24 Jan 2023 at 12:57, Christian König
> wrote:
> >
> > From: Christian König
> >
> > Make sure we can at least move and alloc TT objects without backing store.
> >
> > v2: clear the
n_busy = domain;
domain |= busy;
....
if (domain & VRAM) {
if (non_busy & VRAM)
flags = 0
else
flags = FLAG_BUSY
}
Otherwise if VRAM is set in both "busy" and "domain", it will only try
VRAM when all non-busy first fails, which looks like a change in
behaviour?
The rest of the patch looks good to me, so with the above fixed or explained,
Reviewed-by: Matthew Auld
gt; any more after removing the extra checks in vmwgfx.
>
> Signed-off-by: Christian König
Idea seems reasonable to me,
Reviewed-by: Matthew Auld
On Tue, 24 Jan 2023 at 12:57, Christian König
wrote:
>
> 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: Matthew Auld
On Tue, 24 Jan 2023 at 12:57, Christian König
wrote:
>
> 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: Matthew Auld
t; Signed-off-by: Christian König
Reviewed-by: Matthew Auld
On Tue, 24 Jan 2023 at 09:51, Christian König
wrote:
>
> Am 11.01.23 um 14:17 schrieb Matthew Auld:
> > On Wed, 11 Jan 2023 at 11:43, Christian König
> > wrote:
> >> We have checks for this in the individual drivers move callback, but
> >> it's
offset = 0;
+ if (!length)
+ break;
+ }
+ WARN_ON_ONCE(length);
+
+ return nents;
+}
+
+static noinline struct sg_table *
Not sure why this noinline is needed here?
Reviewed-by: Matthew Auld
+intel_persistent_partial_pages(const
On 18/01/2023 07:16, Niranjana Vishwanathapura wrote:
Support dump capture of persistent mappings upon user request.
Capture of a mapping is requested with the VM_BIND ioctl and
processed during the GPU error handling. They are synchronously
unbound during eviction so that no additional vma
On 13/01/2023 12:02, Das, Nirmoy wrote:
Thanks Matt, I missed the Fixes tag so resent it with fixes and Cc to
stable.
I don't think kernel selftests are really stable material. AFAIK it's
not something normal users care about.
On 1/13/2023 12:51 PM, Matthew Auld wrote:
On 13/01/2023 11
On 13/01/2023 11:49, Nirmoy Das wrote:
From: Chris Wilson
Make sure that upon error after we have acquired the wakeref we do
release it again.
Signed-off-by: Chris Wilson
Signed-off-by: Nirmoy Das
Reviewed-by: Matthew Auld
1 - 100 of 3768 matches
Mail list logo
