elapsed_ms, max_acceptable_time_ms);
Sorry for the delay. We are pretty sure these time asserts are not going
to be flaky over many thousands of runs across different types of
machines (maybe some underpowered atom)?
Assuming not a concern,
Reviewed-by: Matthew Auld
+
+ drm_bud
On 25/08/2025 12:31, Arunpravin Paneer Selvam wrote:
On 8/22/2025 5:32 PM, Matthew Auld wrote:
On 21/08/2025 16:06, Arunpravin Paneer Selvam wrote:
Maintain two separate RB trees per order - one for clear (zeroed) blocks
and another for dirty (uncleared) blocks. This separation improves
code
On 22/08/2025 09:37, Matthew Auld wrote:
On 21/08/2025 16:06, Arunpravin Paneer Selvam wrote:
Replace the freelist (O(n)) used for free block management with a
red-black tree, providing more efficient O(log n) search, insert,
and delete operations. This improves scalability and performance
when
tree macro.
- Use the existing dirty/free bit instead of new tree field.
- Make free_trees[] instead of clear_tree and dirty_tree for
more cleaner approach.
Signed-off-by: Arunpravin Paneer Selvam
Suggested-by: Matthew Auld
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4260
On 21/08/2025 16:06, Arunpravin Paneer Selvam wrote:
Replace the freelist (O(n)) used for free block management with a
red-black tree, providing more efficient O(log n) search, insert,
and delete operations. This improves scalability and performance
when managing large numbers of free blocks per
On 06/08/2025 14:28, Christian König wrote:
On some old x86 systems we had the problem that changing the caching flags
of system memory requires changing the global MTRR/PAT tables.
But on any modern x86 system (CPUs introduced rughly after 2004) we
actually don't need that any more and can upda
>display will now be
initialized only if xe->info.probe_display.
The xe_display_create() function becomes empty, and can be removed. Move
its documentation to xe_display_probe()
Signed-off-by: Jani Nikula
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/xe/display/xe_
by: Jani Nikula
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/xe/display/xe_display.c | 40 -
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/xe/display/xe_display.c
b/drivers/gpu/drm/xe/display/xe_display.c
index 8b2aa7dc6e07..1e59b6dd2c
On 16/05/2025 13:16, Jani Nikula wrote:
xe_display_driver_probe_defer() and xe_display_driver_set_hooks() get
called before either struct xe_device or struct intel_display
exist. Make a note of that.
Signed-off-by: Jani Nikula
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/xe/display
On 16/05/2025 13:16, Jani Nikula wrote:
The workqueue init and destroy belongs in display. Move it.
Signed-off-by: Jani Nikula
Reviewed-by: Matthew Auld
---
.../gpu/drm/i915/display/intel_display_driver.c | 11 ++-
drivers/gpu/drm/i915/i915_driver.c | 13
aoxiang Li
Signed-off-by: Jani Nikula
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/xe/display/xe_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/xe/display/xe_display.c
b/drivers/gpu/drm/xe/display/xe_display.c
index 699f401eff10..df897d08255c 100644
--- a/d
move modeset probe/remove functions to
intel_display_driver.c")
Cc: sta...@vger.kernel.org
Signed-off-by: Haoxiang Li
Signed-off-by: Jani Nikula
Reviewed-by: Matthew Auld
---
.../drm/i915/display/intel_display_driver.c | 30 +++
1 file changed, 25 insertions(+), 5
will now also
skip re-programming the GGTT on re-pin? But wouldn't we have this same
issue for all fb, and not just this fbdev stuff or does reuse_vma()
somehow handle this?
+Matthew Brost / +Matthew Auld
I think this was about commit dd886a63d6e2 ("drm/x
f-by: Jani Nikula
Acked-by: Matthew Auld
---
drivers/gpu/drm/xe/display/xe_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xe/display/xe_display.c
b/drivers/gpu/drm/xe/display/xe_display.c
index 957ae763531d..ca00a365080f 100644
--- a/drivers/
5a ("drm/i915/dgfx: Release mmap on rpm suspend")
Cc: Matthew Auld
Cc: Rodrigo Vivi
Cc: Anshuman Gupta
Cc: Andi Shyti
Cc: Nathan Chancellor
Cc: # v6.1+
Reviewed-by: Matthew Auld # v1
Reviewed-by: Andi Shyti # v1
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/gem/i915_gem_ttm
e with the bitwise AND, but with
CONFIG_DRM_I915_DEBUG_RUNTIME_PM=y, there's the off chance that the
condition evaluates to false, and intel_wakeref_auto() doesn't get
called. Switch to the intended logical AND.
Fixes: ad74457a6b5a ("drm/i915/dgfx: Release mmap on rpm suspend")
Cc:
f orthogonal, but we could maybe also move the l2 flush here? I
assume it's better to flush once at the end.
Reviewed-by: Matthew Auld
}
),
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/drm_buddy.c | 25 +++--
drivers/gpu/drm/xe/xe_ttm_vram_mgr.c | 2 +-
include/drm/drm_buddy.h | 2 ++
3 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu
Ah, so we need a non power-of-two alignment. That makes sense, thanks.
Marek
On Tue, Jul 23, 2024, 11:04 Matthew Auld <mailto:matthew.a...@intel.com>> wrote:
On 23/07/2024 14:43, Paneer Selvam, Arunpravin wrote:
> Hi Matthew,
>
> Can we push this versio
On 23/07/2024 14:43, Paneer Selvam, Arunpravin wrote:
Hi Matthew,
Can we push this version for now as we need to mainline the DCC changes
ASAP,
while we continue our discussion and proceed to implement the permanent
solution
for address alignment?
Yeah, we can always merge now and circle ba
On BMG-G21 we need to disable fbc due to complications around the WA.
v2:
- Try to handle with i915_drv.h and compat layer. (Rodrigo)
v3:
- For simplicity retreat back to the original design for now.
- Drop the extra \ from the Makefile (Jani)
Signed-off-by: Matthew Auld
Cc: Jonathan Cavitt
to complications in getting this to work
correctly (in a later patch).
Signed-off-by: Matthew Auld
Cc: Jonathan Cavitt
Cc: Matt Roper
Cc: Lucas De Marchi
Cc: Vinod Govindapillai
Reviewed-by: Jonathan Cavitt
---
drivers/gpu/drm/xe/Makefile| 2 +
drivers/gpu/drm/xe/display
Hi,
On 03/07/2024 10:24, Thomas Hellström wrote:
Hi, Matt
On Tue, 2024-07-02 at 16:06 +0100, Matthew Auld wrote:
This involves enabling l2 caching of host side memory access to VRAM
through the CPU BAR. The main fallout here is with display since VRAM
writes from CPU can now be cached in GPU
On BMG-G21 we need to disable fbc due to complications around the WA.
v2:
- Try to handle with i915_drv.h and compat layer. (Rodrigo)
v3:
- For simplicity retreat back to the original design for now.
- Drop the extra \ from the Makefile (Jani)
Signed-off-by: Matthew Auld
Cc: Jonathan Cavitt
to complications in getting this to work
correctly (in a later patch).
Signed-off-by: Matthew Auld
Cc: Jonathan Cavitt
Cc: Matt Roper
Cc: Lucas De Marchi
Cc: Vinod Govindapillai
Reviewed-by: Jonathan Cavitt
---
drivers/gpu/drm/xe/Makefile| 2 +
drivers/gpu/drm/xe/display
On 02/07/2024 10:26, Jani Nikula wrote:
On Tue, 02 Jul 2024, Matthew Auld wrote:
Hi,
On 02/07/2024 09:17, Jani Nikula wrote:
On Mon, 01 Jul 2024, Matthew Auld wrote:
On BMG-G21 we need to disable fbc due to complications around the WA.
v2:
- Try to handle with i915_drv.h and compat
Hi,
On 02/07/2024 09:17, Jani Nikula wrote:
On Mon, 01 Jul 2024, Matthew Auld wrote:
On BMG-G21 we need to disable fbc due to complications around the WA.
v2:
- Try to handle with i915_drv.h and compat layer. (Rodrigo)
Signed-off-by: Matthew Auld
Cc: Jonathan Cavitt
Cc: Matt Roper
Cc
to complications in getting this to work
correctly (in a later patch).
Signed-off-by: Matthew Auld
Cc: Jonathan Cavitt
Cc: Matt Roper
Cc: Lucas De Marchi
Cc: Vinod Govindapillai
Reviewed-by: Jonathan Cavitt
---
drivers/gpu/drm/xe/Makefile| 2 +
drivers/gpu/drm/xe/display
On BMG-G21 we need to disable fbc due to complications around the WA.
v2:
- Try to handle with i915_drv.h and compat layer. (Rodrigo)
Signed-off-by: Matthew Auld
Cc: Jonathan Cavitt
Cc: Matt Roper
Cc: Lucas De Marchi
Cc: Vinod Govindapillai
Cc: Rodrigo Vivi
Cc: intel-gfx
On 26/06/2024 16:55, Rodrigo Vivi wrote:
On Wed, Jun 26, 2024 at 04:14:02PM +0100, Matthew Auld wrote:
On 25/06/2024 09:09, Matthew Auld wrote:
On 19/06/2024 15:31, Matthew Auld wrote:
On BMG-G21 we need to disable fbc due to complications around the WA.
Signed-off-by: Matthew Auld
Cc
On 26/06/2024 16:53, Rodrigo Vivi wrote:
On Wed, Jun 19, 2024 at 03:31:27PM +0100, Matthew Auld wrote:
On BMG-G21 we need to disable fbc due to complications around the WA.
Signed-off-by: Matthew Auld
Cc: Jonathan Cavitt
Cc: Matt Roper
Cc: Lucas De Marchi
Cc: Vinod Govindapillai
Cc: intel
On 25/06/2024 09:09, Matthew Auld wrote:
On 19/06/2024 15:31, Matthew Auld wrote:
On BMG-G21 we need to disable fbc due to complications around the WA.
Signed-off-by: Matthew Auld
Cc: Jonathan Cavitt
Cc: Matt Roper
Cc: Lucas De Marchi
Cc: Vinod Govindapillai
Cc: intel-gfx
On 19/06/2024 15:31, Matthew Auld wrote:
On BMG-G21 we need to disable fbc due to complications around the WA.
Signed-off-by: Matthew Auld
Cc: Jonathan Cavitt
Cc: Matt Roper
Cc: Lucas De Marchi
Cc: Vinod Govindapillai
Cc: intel-gfx@lists.freedesktop.org
Can this be merged via drm-xe-next
On BMG-G21 we need to disable fbc due to complications around the WA.
Signed-off-by: Matthew Auld
Cc: Jonathan Cavitt
Cc: Matt Roper
Cc: Lucas De Marchi
Cc: Vinod Govindapillai
Cc: intel-gfx@lists.freedesktop.org
---
drivers/gpu/drm/i915/display/intel_display_wa.h | 8
drivers/gpu
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. This is
dding 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 in the
ff-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 ad
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
bridge: aux-hpd: separate 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 th
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:
Previous
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 the
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
e 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 everythi
goto err_free;
}
+ list_splice_tail(&allocated, 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 or
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 som
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 de1030a47588..4b76db698
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 --git
the trim to work
on multiple nodes)? But I guess in practice should be pretty meh, given
that the extra rhs is hopefully not too big in the corner case where the
alignment doesn't fit the min_block_size?
Anyway, for patches 1-3,
Reviewed-by: Matthew Auld
+
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 obje
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
swapped-out? Keeping 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/i
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 config.
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 +++-
drivers/gpu/drm/i915/di
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
Signed-o
It's
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 insert
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 ; De
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
corre
; 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
page sizes 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/ge
ress space 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&quo
space 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
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:
> https://patchwork
space 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
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
space 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
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. re-o
("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
rce 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
rce 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 try
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 look
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 is
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 pag
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
1 - 100 of 1451 matches
Mail list logo
