Touching bo->resource looks like it should require first locking the
object, since this state is dynamic and could potentially change from
under us. It looks we can just use obj->base.size here, which avoids any
issues with locking, since this is immutable state.
Signed-off-by: Matthew Au
tary for why we need to CPU access the buffer.
- Split out the other changes, so we just consider the display change
here.
Fixes: eb1c535f0d69 ("drm/i915: turn on small BAR support")
Reported-by: Jianshui Yu
Signed-off-by: Matthew Auld
Cc: Ville Syrjälä
Cc: Nirmoy Das
Reviewed-
On small-bar systems we could be given something non-mappable here,
which leads to nasty oops. Make this nicer by checking if the resource
is mappable or not, and return an error otherwise.
v2: drop GEM_BUG_ON(flags & I915_BO_ALLOC_GPU_ONLY)
Signed-off-by: Matthew Auld
Cc: Jianshui Yu
In the next patch we want to move the object (if the current resource is
not compatible), to the mappable part of lmem for some display buffers.
Currently that requires being able to unset the I915_BO_ALLOC_GPU_ONLY
hint.
Signed-off-by: Matthew Auld
Cc: Jianshui Yu
Cc: Ville Syrjälä
Cc: Nirmoy
The copy is async (if there even is one), but when later updating the
GGTT we always sync against the binding, which will in turn sync against
any moves.
Signed-off-by: Matthew Auld
Cc: Jianshui Yu
Cc: Ville Syrjälä
Cc: Nirmoy Das
Reviewed-by: Nirmoy Das
---
drivers/gpu/drm/i915/display
Touching bo->resource looks like it should require first locking the
object, since this state is dynamic and could potentially change from
under us.
Signed-off-by: Matthew Auld
Cc: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 9 ++---
1 file changed, 6 insertions(+), 3 deleti
It looks like we need this for local-memory, if we want to use ptrace.
Something more is still needed if we want to handle non-mappable memory,
which looks quite annoying.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/6989
Signed-off-by: Matthew Auld
Cc: Nirmoy Das
---
drivers
On 30/09/2022 15:00, Ville Syrjälä wrote:
On Fri, Sep 30, 2022 at 02:47:30PM +0100, Matthew Auld wrote:
For these types of display buffers, we need to able to CPU access some
part of the backing memory in prepare_plane_clear_colors(). As a result
we need to ensure we always place
On 30/09/2022 14:32, Tejas Upadhyay wrote:
Add these extra EHL entries back since we have
drm-tip commit 13d29c823738
("drm/i915/ehl: unconditionally flush the pages on acquire")
introduces proper flushing to make it work as expected.
Cc: Chris Wilson
Cc: Matthew Auld
Fixes: 04
On small-bar systems we could be given something non-mappable here,
which leads to nasty oops. Make this nicer by checking if the resource
is mappable or not, and return an error otherwise.
v2: drop GEM_BUG_ON(flags & I915_BO_ALLOC_GPU_ONLY)
Signed-off-by: Matthew Auld
Cc: Jianshui Yu
turn on small BAR support")
Reported-by: Jianshui Yu
Signed-off-by: Matthew Auld
Cc: Ville Syrjälä
Cc: Nirmoy Das
---
drivers/gpu/drm/i915/display/intel_fb_pin.c | 11 --
drivers/gpu/drm/i915/gem/i915_gem_object.c| 37 ++-
drivers/gpu/drm/i915/gem/i915_gem_object
On small-bar systems we could be given something non-mappable here,
which leads to nasty oops. Make this nicer by checking if the resource
is mappable or not, and return an error otherwise.
Signed-off-by: Matthew Auld
Cc: Jianshui Yu
Cc: Ville Syrjälä
Cc: Nirmoy Das
---
drivers/gpu/drm/i915
turn on small BAR support")
Reported-by: Jianshui Yu
Signed-off-by: Matthew Auld
Cc: Ville Syrjälä
Cc: Nirmoy Das
---
drivers/gpu/drm/i915/display/intel_fb_pin.c | 11 --
drivers/gpu/drm/i915/gem/i915_gem_object.c| 37 ++-
drivers/gpu/drm/i915/gem/i915_gem_object
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Update the execbuf path to use common execbuf functions to
reduce code duplication with the newer execbuf3 path.
Signed-off-by: Niranjana Vishwanathapura
Acked-by: Matthew Auld
specified fence
+ * @signal: signal the specified fence
+ *
+ * Add the fence specified by drm_syncobj @handle at specified @point in the
+ * timeline to the Execbuffer fence array @f. If @wait is specified, it is an
+ * input fence and if @signal is specified it is an output fence.
+ *
+ * Returns 0 upon success, -ve error upon failure.
Also can return 1, which also means success. Also maybe clarify that
zero here is special.
Acked-by: Matthew Auld
/** @extensions: Zero-terminated chain of extensions. */
__u64 extensions;
- /** @flags: reserved for future usage, currently MBZ */
+#define I915_VM_CREATE_FLAGS_USE_VM_BIND (1u << 0)
Some kernel-doc for that would be good, even if it's kind of obvious.
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Handle persistent (VM_BIND) mappings during the request submission
in the execbuf3 path.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
.../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 188 +-
1
On 29/09/2022 17:38, Niranjana Vishwanathapura wrote:
On Thu, Sep 29, 2022 at 11:49:30AM +0100, Matthew Auld wrote:
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Add uapi and implement support for bind and unbind of an
object at the specified GPU virtual addresses.
The vm_bind mode
Acked-by: Matthew Auld
---
.../drm/i915/gem/i915_gem_vm_bind_object.c| 6 ++
drivers/gpu/drm/i915/gt/intel_gtt.c | 2 ++
drivers/gpu/drm/i915/gt/intel_gtt.h | 4
drivers/gpu/drm/i915/i915_vma.c | 19 +++
drivers/gpu/drm
. ie., multiple
mappings (at different VA) point to the same gtt_view of object.
Skip vma_lookup for persistent vmas to support aliasing.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
Acked-by: Matthew Auld
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Implement new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only
works in vm_bind mode. The vm_bind mode only works with
this new execbuf3 ioctl.
The new execbuf3 ioctl will not have any list of objects to validate
bind as all required objects
On 29/09/2022 10:03, Matthew Auld wrote:
On 29/09/2022 06:24, Niranjana Vishwanathapura wrote:
On Wed, Sep 28, 2022 at 06:52:21PM +0100, Matthew Auld wrote:
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Add uapi and implement support for bind and unbind of an
object at the specified
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Add uapi and implement support for bind and unbind of an
object at the specified GPU virtual addresses.
The vm_bind mode is not supported in legacy execbuf2 ioctl.
It will be supported only in the newer execbuf3 ioctl.
Signed-off-by:
On 29/09/2022 06:24, Niranjana Vishwanathapura wrote:
On Wed, Sep 28, 2022 at 06:52:21PM +0100, Matthew Auld wrote:
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Add uapi and implement support for bind and unbind of an
object at the specified GPU virtual addresses.
The vm_bind mode
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Each VM creates a root_obj and shares it with all of its private objects
to use it as dma_resv object. This has a performance advantage as it
requires a single dma_resv object update for all private BOs vs list of
dma_resv objects update for
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Add uapi and implement support for bind and unbind of an
object at the specified GPU virtual addresses.
The vm_bind mode is not supported in legacy execbuf2 ioctl.
It will be supported only in the newer execbuf3 ioctl.
Signed-off-by:
;max of the min_page_size, or I915_GTT_PAGE_SIZE_4K if zero placements."
Acked-by: Matthew Auld
+ */
+u32 i915_gem_object_max_page_size(struct intel_memory_region **placements,
+ unsigned int n_placements)
{
- u32 max_page_size = 0;
+ u32 max_page_size = I915_G
in jiffies
+ * @gfp: allocation mode
+ *
+ * Setup the @fence to asynchronously wait on dma-resv object @resv for usage
+ * @usage to complete before signaling.
s/usage @usage/@usage/ ?
+ *
+ * Returns 0 if there is nothing to wait on, -ve upon error and >0 upon
What does "-ve"
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Make i915_gem_vm_lookup() function non-static as it will be
used by the vm_bind feature.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
Acked-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 11
@i915_query@query-regions-sanity-check
Suggested-by: Lionel Landwerlin
Signed-off-by: Matthew Auld
Cc: Michal Mrozek
Cc: Thomas Hellström
Cc: Stuart Summers
Cc: Jordan Justen
Cc: Yang A Shi
Cc: Nirmoy Das
---
drivers/gpu/drm/i915/i915_query.c | 1 +
include/uapi/drm/i915_drm.h | 29
restrictions, as documented in:
commit caa574ffc4aaf4f29b890223878c63e2e7772f62
Author: Matthew Auld
Date: Sat Feb 19 00:17:49 2022 +0530
drm/i915/uapi: document behaviour for DG2 64K support
On discrete platforms like DG2, we need to support a minimum page size
of 64K when dealing
unt) to
GEM_BUG_ON(!obj->userfault_count).
Fixes: ad74457a6b5a ("drm/i915/dgfx: Release mmap on rpm suspend")
Suggested-by: Matthew Auld
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 19 +---
drivers/gpu/drm/i915/gem/i915
_count).
Fixes: ad74457a6b5a ("drm/i915/dgfx: Release mmap on rpm suspend")
Suggested-by: Matthew Auld
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 19 +---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 39
drivers/gpu/drm/i9
On Mon, 26 Sept 2022 at 16:50, Matthew Auld wrote:
>
> From: Chris Wilson
>
> The scratch page should never be accessed, and is only assigned as a
> filler page to redirection invalid userspace access. It is not of a
> performance concern and so we prefer to have a
and avoiding the direct device access that would be required to
initialise the scratch page.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 43 ++--
1 file changed, 22 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm
On Mon, 26 Sept 2022 at 16:34, Matthew Auld wrote:
>
> From: Chris Wilson
>
> Now that the scratch page and page directories have a reference back to
> the i915_address_space, we cannot do an immediate free of the ppgtt upon
> error as those buffer objects will perform a
n't free shared locks while shared")
Cc: Thomas Hellström
Cc: Matthew Auld
Cc: # v5.14+
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 16
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 58 ++--
drivers/gpu/drm/i915/gt/intel_gtt.c |
restrictions, as documented in:
commit caa574ffc4aaf4f29b890223878c63e2e7772f62
Author: Matthew Auld
Date: Sat Feb 19 00:17:49 2022 +0530
drm/i915/uapi: document behaviour for DG2 64K support
On discrete platforms like DG2, we need to support a minimum page size
of 64K when dealing
that bug the object is just too large
for the mappable part of lmem, so this just gives -2big or similar on
small-bar systems. I presume that the test needs to be updated to
account for the cpu_size or so.
With the kernel test robot warning fixed:
Acked-by: Matthew Auld
I looked at the GEM_BUG_O
On 22/09/2022 09:09, Tvrtko Ursulin wrote:
On 21/09/2022 19:00, Niranjana Vishwanathapura wrote:
On Wed, Sep 21, 2022 at 10:13:12AM +0100, Tvrtko Ursulin wrote:
On 21/09/2022 08:09, Niranjana Vishwanathapura wrote:
Expose i915_gem_object_max_page_size() function non-static
which will be
On 21/09/2022 06:29, Gupta, Anshuman wrote:
-Original Message-
From: Matthew Auld
Sent: Tuesday, September 20, 2022 7:30 PM
To: Gupta, Anshuman
Cc: intel-gfx@lists.freedesktop.org; ch...@chris-wilson.co.uk; Auld, Matthew
; Vivi, Rodrigo
Subject: Re: [Intel-gfx] [PATCH v5 2/2] drm
drm/intel/-/issues/6850
Signed-off-by: Nirmoy Das
Reviewed-by: Matthew Auld
Christian, as per above it looks like ttm calls into the
delete_mem_notify() hook twice if the object ends up on the delayed
destroy list, is that expected/normal?
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c
On 15/09/2022 08:49, Tvrtko Ursulin wrote:
On 14/09/2022 17:35, Jani Nikula wrote:
The inline function has no place in i915_drv.h. Move it away, un-inline,
and untangle some header dependencies while at it.
Cc: Matthew Auld
Cc: Tvrtko Ursulin
Signed-off-by: Jani Nikula
---
I don't know
t; - Addressed the cosmetics comments. [Andi]
> - Changed i915_gem_runtime_pm_object_release_mmap_offset() name to
> i915_gem_object_runtime_pm_release_mmap_offset() to be rhythmic.
>
> PCIe Specs 5.3.1.4.1
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6331
> Cc: Matthew Auld
> Cc
n path. [Matt Auld]
- Get a wakeref for object destruction patch. [Matt Auld]
- Use intel_wakeref_auto to delay runtime PM. [Matt Auld]
PCIe Specs 5.3.1.4.1
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6331
Cc: Matthew Auld
Cc: Rodrigo Vivi
Signed-off-by: Anshuman Gupta
---
drivers/g
On 08/09/2022 10:46, Das, Nirmoy wrote:
On 9/8/2022 11:40 AM, Matthew Auld wrote:
On 07/09/2022 18:26, Nirmoy Das wrote:
Fix regression introduced by commit:
"drm/i915: Individualize fences before adding to dma_resv obj"
which sets obj->read_domains to 0 for both read and writ
mit.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/6639
Fixes: 842d9346b2fd ("drm/i915: Individualize fences before adding to dma_resv
obj")
Signed-off-by: Nirmoy Das
Cc: # v5.16+
Cc: Matthew Auld
Cc: Andrzej Hajda
Should I go ahead and push this?
---
drivers/g
On Wed, 7 Sept 2022 at 16:23, Christian König
wrote:
>
> Otherwise lockdep will complain about cleaning up the bulk_move.
>
> Not even compile tested.
>
> Signed-off-by: Christian König
CI looks better now. Thanks for the quick fix.
> ---
> drivers/gpu/drm/ttm/ttm_bo_util.c | 10 +-
>
/i915/ttm: disallow CPU fallback mode for ccs pages")
Signed-off-by: Matthew Auld
Cc: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 3 +++
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/dr
On Sat, 6 Aug 2022 at 13:34, Tomas Winkler wrote:
>
> GSC requires more operational memory than available on chip.
> Reserve 4M of LMEM for GSC operation. The memory is provided to the
> GSC as struct resource to the auxiliary data of the child device.
>
> Cc: Alan Previn
> Signed-off-by: Tomas
On 01/09/2022 09:00, Christian König wrote:
Am 31.08.22 um 18:32 schrieb Matthew Auld:
On 31/08/2022 15:53, Matthew Auld wrote:
On 31/08/2022 14:34, Christian König wrote:
Am 31.08.22 um 14:50 schrieb Matthew Auld:
On 31/08/2022 13:35, Christian König wrote:
Am 31.08.22 um 14:06 schrieb
On 31/08/2022 15:53, Matthew Auld wrote:
On 31/08/2022 14:34, Christian König wrote:
Am 31.08.22 um 14:50 schrieb Matthew Auld:
On 31/08/2022 13:35, Christian König wrote:
Am 31.08.22 um 14:06 schrieb Matthew Auld:
On 31/08/2022 12:03, Christian König wrote:
Am 31.08.22 um 12:37 schrieb
/-/issues/6529
Does this fix it? Does CI not complain about the drm_err? Also do we
know what the actual error was?
Suggested-by: Chris P Wilson
Signed-off-by: Nirmoy Das
Passing the error along seems reasonable to me,
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem
On 31/08/2022 14:34, Christian König wrote:
Am 31.08.22 um 14:50 schrieb Matthew Auld:
On 31/08/2022 13:35, Christian König wrote:
Am 31.08.22 um 14:06 schrieb Matthew Auld:
On 31/08/2022 12:03, Christian König wrote:
Am 31.08.22 um 12:37 schrieb Matthew Auld:
[SNIP]
That hopefully just
On 31/08/2022 13:35, Christian König wrote:
Am 31.08.22 um 14:06 schrieb Matthew Auld:
On 31/08/2022 12:03, Christian König wrote:
Am 31.08.22 um 12:37 schrieb Matthew Auld:
[SNIP]
That hopefully just leaves i915_ttm_shrink(), which is swapping
out shmem ttm_tt and is calling
On 31/08/2022 12:03, Christian König wrote:
Am 31.08.22 um 12:37 schrieb Matthew Auld:
[SNIP]
That hopefully just leaves i915_ttm_shrink(), which is swapping out
shmem ttm_tt and is calling ttm_bo_validate() with empty placements
to force the pipeline-gutting path, which importantly
On 31/08/2022 10:38, Christian König wrote:
Am 31.08.22 um 11:26 schrieb Matthew Auld:
On 31/08/2022 09:16, Christian König wrote:
Hi Matthew,
Am 30.08.22 um 12:45 schrieb Matthew Auld:
Hi,
On 30/08/2022 08:33, Christian König wrote:
Hi guys,
can we get an rb/acked-by for this i915 change
On 31/08/2022 09:16, Christian König wrote:
Hi Matthew,
Am 30.08.22 um 12:45 schrieb Matthew Auld:
Hi,
On 30/08/2022 08:33, Christian König wrote:
Hi guys,
can we get an rb/acked-by for this i915 change?
Basically we are just making sure that the driver doesn't crash when
bo->resou
On 27/08/2022 20:43, Andi Shyti wrote:
From: Niranjana Vishwanathapura
Implement the bind and unbind of an object at the specified GPU virtual
addresses.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Prathap Kumar Valsan
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
---
On 27/08/2022 20:43, Andi Shyti wrote:
From: Niranjana Vishwanathapura
Implement the bind and unbind of an object at the specified GPU virtual
addresses.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Prathap Kumar Valsan
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
---
On Tue, 30 Aug 2022 at 14:39, Matthew Auld
wrote:
>
> On Mon, 29 Aug 2022 at 12:15, Gupta, Anshuman
> wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Auld, Matthew
> > Thanks Matt for reviewing this.
> > > Sent: Friday
double checking, this is needed for DG1 and DG2, right? Are there any
> > BSpec
> > links we can add here?
> This is specific to all discrete products with respect to PCIe Spec Section
> 5.3.1.4.1
> I will add the PCIe specs link here.
> >
> > > Cc: M
On 25/08/2022 16:46, Matthew Auld wrote:
On 25/08/2022 16:42, Andrzej Hajda wrote:
In case of Small BAR configurations stolen local memory can be
unmappable.
Since the test does not touch the memory, passing I915_BO_ALLOC_GPU_ONLY
flag to i915_gem_object_create_region, will prevent -ENOSPC
Hi,
On 30/08/2022 08:33, Christian König wrote:
Hi guys,
can we get an rb/acked-by for this i915 change?
Basically we are just making sure that the driver doesn't crash when
bo->resource is NULL and a bo doesn't have any backing store assigned to
it.
The Intel CI seems to be happy with
ded i915_gem_object_lock to check
i915_gem_object_is_lmem. [Matt Auld]
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6331
Just double checking, this is needed for DG1 and DG2, right? Are there
any BSpec links we can add here?
Cc: Matthew Auld
Cc: Rodrigo Vivi
Signed-off-by: Anshuman Gu
.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6565
Signed-off-by: Andrzej Hajda
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
b/drivers/gpu
On 25/08/2022 15:52, Andrzej Hajda wrote:
In case of Small BAR configurations stolen local memory can be unmappable.
Trying to test it causes -ENOSPC error from _i915_gem_object_stolen_init.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6565
Signed-off-by: Andrzej Hajda
Ah right.
On Mon, 15 Aug 2022 at 09:09, Jani Nikula wrote:
>
> Remove unused macros. If needed again, such macros belong in
> .
>
> Signed-off-by: Jani Nikula
Reviewed-by: Matthew Auld
> ---
> drivers/gpu/drm/i915/i915_utils.h | 4
> 1 file changed, 4 deletions(-)
>
>
invalid? For now just revert, unless GuC experts
already have a fix in mind.
[1] https://intel-gfx-ci.01.org/tree/drm-tip/index.html?
Signed-off-by: Matthew Auld
Cc: Matthew Brost
Cc: Alan Previn
Cc: John Harrison
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915
On 17/08/2022 16:09, Anshuman Gupta wrote:
Runtime resume the dgpu(when gem object lies in lmem).
This will transition the dgpu graphics function to D0
state if it was in D3 in order to access the mmap memory
mappings.
Cc: Matthew Auld
Cc: Rodrigo Vivi
Signed-off-by: Anshuman Gupta
On 17/08/2022 16:09, Anshuman Gupta wrote:
Release all mmap mapping for all lmem objects which are associated
with userfault such that, while pcie function in D3hot, any access
to memory mappings will raise a userfault.
Cc: Matthew Auld
Cc: Rodrigo Vivi
Signed-off-by: Anshuman Gupta
)
- Just make TEST_RANDOM use bigger sizes to ensure we get coverage of
objects that require splitting the copy into multiple packets.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
tests/i915/gem_lmem_swapping.c | 18 --
1 file changed, 16 insertions
We only ever need to emit one ccs block copy command.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 35 +++--
1 file changed, 3 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt
Z) is currently broken on DG2.
Fixes: da0595ae91da ("drm/i915/migrate: Evict and restore the flatccs capable
lmem obj")
Testcase: igt@gem_lmem_swapping@basic-big
Testcase: igt@gem_lmem_swapping@verify-ccs-big
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
Everything we are testing here unfortunately fits within one packet (8M)
which means we have zero coverage when we need to split the copy over
multiple packets (including the aux CCS state).
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
tests/i915/gem_lmem_swapping.c
lace->fpfn && !place->lpfn)
+ return true;
+
+ GEM_BUG_ON(!place->lpfn);
+
+ /*
+* If we just want something mappable then we can quickly check
+* if the current victim resource is using any of the CP
Nit: s/CP/CPU/
Reviewed-by:
d of blocking lock for
__i915_gem_free_objects.")
Cc: # v5.17+
Signed-off-by: Chris Wilson
Looks to be missing your sob.
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 16
drivers/gpu/drm/i915/i915_drv.h| 4 ++--
2 files chang
On 28/07/2022 15:33, Arunpravin Paneer Selvam wrote:
Apply new intersect and compatible callback instead
of having a generic placement range verfications.
v2: Added a separate callback for compatiblilty
checks (Christian)
Signed-off-by: Christian König
Signed-off-by: Arunpravin Paneer
On 28/07/2022 15:33, Arunpravin Paneer Selvam wrote:
Implemented a new intersect and compatible callback function
fetching start offset from drm buddy allocator.
v2: move the bits that are specific to buddy_man (Matthew)
Signed-off-by: Christian König
Signed-off-by: Arunpravin Paneer Selvam
The kernel only manages the ccs state with lmem-only objects, however the
kernel should still take
care not to leak the CCS state from the previous user.
Fixes: 48760ffe923a ("drm/i915/gt: Clear compress metadata for Flat-ccs
objects")
Signed-off-by: Matthew Auld
Cc: Thomas Hel
On 26/07/2022 09:32, Nirmoy Das wrote:
PCI bar resize only works with 64 bit BAR so disable
this on 32-bit machine.
Maybe also mention somewhere that this is just to fix a compiler warning
with the 0x1ull being out-of-range with resource_size_t on 32bit?
Acked-by: Matthew Auld
The kernel only manages the ccs state with lmem-only objects, however
the kernel should still take care not to leak the CCS state from the
previous user.
Fixes: 48760ffe923a ("drm/i915/gt: Clear compress metadata for Flat-ccs
objects")
Signed-off-by: Matthew Auld
Cc: Thomas Hel
o:
<4> [437.542716]CPU0CPU1
<4> [437.542719]
<4> [437.542721] lock(fs_reclaim);
<4> [437.542725] lock(acpi_device_lock);
<4> [437.542728]l
On 26/07/2022 15:48, Nirmoy Das wrote:
From: Chris Wilson
The obj->base.resv may be shared across many objects, some of which may
still be live and locked, preventing objects from being freed
indefintely. We could individualise the lock during the free, or rely on
a freed object having no
On 25/07/2022 12:42, Arunpravin Paneer Selvam wrote:
Implemented a new intersect and compatible callback function
fetching start offset from drm buddy allocator.
Signed-off-by: Christian König
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 43
Hi,
On 25/07/2022 15:55, Tvrtko Ursulin wrote:
Hi Matt,
On 29/06/2022 18:43, Matthew Auld wrote:
Falling back to memcpy/memset shouldn't be allowed if we know we have
CCS state to manage using the blitter. Otherwise we are potentially
leaving the aux CCS state in an unknown state, which
On 20/07/2022 13:23, Nirmoy Das wrote:
From: Chris Wilson
We report object allocation failures to userspace with ENOMEM, yet we
still show the memory warning after failing to shrink device allocated
pages. While this warning is similar to other system page allocation
failures, it is
The object here could be very large (8G+), so make sure we allow using
the entire address space, to avoid sometimes hitting -ENOSPC.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6446
Signed-off-by: Matthew Auld
Cc: Nirmoy Das
---
tests/i915/gem_create.c | 2 ++
1 file changed, 2
On Tue, 12 Jul 2022 at 12:46, Christian König
wrote:
>
> Make sure we can at least move and alloc TT objects without backing store.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 6 ++
> drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 2 +-
> 2
length type), so also make it all u32.
Reported-by: Ville Syrjälä
Fixes: bc99f1209f19 ("drm/i915/ttm: fix sg_table construction")
Signed-off-by: Matthew Auld
Cc: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_region.c | 2 ++
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 2 +-
driv
On 08/07/2022 10:41, Dan Carpenter wrote:
The shmem_pin_map() function doesn't return error pointers, it returns
NULL.
Fixes: be1cb55a07bf ("drm/i915/gt: Keep a no-frills swappable copy of the default
context state")
Signed-off-by: Dan Carpenter
Reviewed-by: Matthew Auld
Pus
round_down consistently to avoid udiv errors
v3(Nirmoy):
- Also update the max_segment in the selftest
Fixes: f701b16d4cc5 ("drm/i915/ttm: add i915_sg_from_buddy_resource")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6379
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc:
On 08/07/2022 14:22, Robert Beckett wrote:
On 08/07/2022 08:53, Matthew Auld wrote:
On 07/07/2022 21:02, Robert Beckett wrote:
During testing make can_mmap consider whether the region is private.
Do we still need this with: 938d2fd17d17 ("drm/i915/selftests: skip
the mman tests for s
eep a no-frills swappable copy of
the default context state")
Signed-off-by: Dan Carpenter
There looks to be one more in gvt/cmd_parser.c?
Otherwise,
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff
On 07/07/2022 21:02, Robert Beckett wrote:
During testing make can_mmap consider whether the region is private.
Do we still need this with: 938d2fd17d17 ("drm/i915/selftests: skip the
mman tests for stolen") ?
Signed-off-by: Robert Beckett
Reviewed-by: Thomas Hellström
---
consistently to avoid udiv errors
Fixes: f701b16d4cc5 ("drm/i915/ttm: add i915_sg_from_buddy_resource")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6379
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c
t;drm/i915/ttm: add i915_sg_from_buddy_resource")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6379
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 11 +--
drivers/gpu/drm/i915/i915_scatterlist.c
This reverts commit 3cf110f8dcd1f4f02cf84339664b413abdaebf7d.
This is too big of a hammer it seems, since we can't really support
flat-CCS with lmem + smem objects, and here adding the flag means we
also attach the smem placement, which seems to break kms_ccs.
Signed-off-by: Matthew Auld
Cc
On Wed, 6 Jul 2022 at 16:48, Matthew Auld wrote:
>
> From: Chris Wilson
>
> Since we are not holding a wakeref, shrinking a bound object is not
> guaranteed.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6370
> Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
From: Chris Wilson
Since we are not holding a wakeref, shrinking a bound object is not
guaranteed.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6370
Signed-off-by: Chris Wilson
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 7 ++-
1 file
301 - 400 of 3785 matches
Mail list logo
