[Intel-gfx] [PATCH i-g-t 1/2] tests/kms_pwrite_crc: handle missing get_caching

gem_get_caching is not supported on discrete. The object itself should already be coherent with the display engine as-is on such platforms, by virtue of the scanout happening via local-memory. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4903 Signed-off-by: Matthew Auld Cc: Nirmoy

[Intel-gfx] [PATCH i-g-t 2/2] tests/gem_ctx_engines: handle missing set_caching

Not supported on discrete. Here the object will already have the GTT caching bits enabled, and the mapping will be WB, which looks inline with what the test is expecting here. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4926 Signed-off-by: Matthew Auld Cc: Nirmoy Das --- tests

Re: [Intel-gfx] Small bar recovery vs compressed content on DG2

On 18/03/2022 18:12, Daniel Vetter wrote: Maybe also good to add dri-devel to these discussions. I'm not sure where exactly we landed with dgpu error capture (maybe I should check the code but it's really w/e here), but I think we can also toss in "you need a non-recoverable context for error ca

Re: [Intel-gfx] [PATCH v2] drm: add a check to verify the size alignment

the order value which is 0 > >> and when it compares with min_order = 8, triggers the BUG_ON(order > >> < min_order). To avoid this problem, we added a simple check to > >> return -EINVAL if size is not aligned to the min_page_size. > >> > >> v2

[Intel-gfx] [CI 1/4] drm/i915/gt: Explicitly clear BB_OFFSET for new contexts

From: Chris Wilson Even though the initial protocontext we load onto HW has the register cleared, by the time we save it into the default image, BB_OFFSET has had the enable bit set. Reclear BB_OFFSET for each new context. Testcase: igt/i915_selftests/gt_lrc Signed-off-by: Chris Wilson Cc: Mik

[Intel-gfx] [CI 4/4] drm/i915/selftest: Always cancel semaphore on error

From: Chris Wilson Ensure that we always signal the semaphore when timing out, so that if it happens to be stuck waiting for the semaphore we will quickly recover without having to wait for a reset. Reported-by: CQ Tang Signed-off-by: Chris Wilson Cc: CQ Tang cc: Joonas Lahtinen Signed-off-b

[Intel-gfx] [CI 3/4] drm/i915/selftest: Clear the output buffers before GPU writes

From: Chris Wilson When testing whether we can get the GPU to leak information about non-privileged state, we first need to ensure that the output buffer is set to a known value as the HW may opt to skip the write into memory for a non-privileged read of a sensitive register. We chose POISON_INUS

[Intel-gfx] [CI 2/4] drm/i915/selftests: Check for incomplete LRI from the context image

From: Chris Wilson In order to keep the context image parser simple, we assume that all commands follow a similar format. A few, especially not MI commands on the render engines, have fixed lengths not encoded in a length field. This caused us to incorrectly skip over 3D state commands, and start

[Intel-gfx] [PATCH i-g-t v3] tests/gem_lmem_swapping: limit lmem to 4G

; if it's not supported it will still load the driver just fine. v3(Petri): - Add a helpful debug print in case the kernel is missing support for the lmem_size modparam. Signed-off-by: CQ Tang Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Nirmoy Das Cc: Petri Latvala Review

[Intel-gfx] [PATCH i-g-t v2] tests/gem_lmem_swapping: limit lmem to 4G

; if it's not supported it will still load the driver just fine. Signed-off-by: CQ Tang Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Nirmoy Das Reviewed-by: Thomas Hellström Reviewed-by: Nirmoy Das --- tests/i915/gem_lmem_swapping.c | 6 +- 1 file changed, 5 insertions(

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 3/4] tests/gem_lmem_swapping: limit lmem to 4G

On 25/03/2022 10:18, Petri Latvala wrote: On Thu, Mar 24, 2022 at 02:26:20PM +, Matthew Auld wrote: From: CQ Tang On some systems lmem can be as large as 16G, which seems to trigger various CI timeouts, and in the best case just takes a long time. For the purposes of the test we should be

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for lmem_size modparam

On 24/03/2022 20:15, Patchwork wrote: *Patch Details* *Series:* lmem_size modparam *URL:* https://patchwork.freedesktop.org/series/101744/ *State:*failure *Details:* https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22671/index.

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/ttm: limit where we apply TTM_PL_FLAG_CONTIGUOUS (rev2)

On 25/03/2022 09:22, Patchwork wrote: *Patch Details* *Series:* series starting with [1/2] drm/i915/ttm: limit where we apply TTM_PL_FLAG_CONTIGUOUS (rev2) *URL:* https://patchwork.freedesktop.org/series/101749/ *State:*failure *Detail

[Intel-gfx] [PATCH i-g-t v2 3/3] tests/gem_lmem_swapping: reduce the timeout

300s is way too much for some BAT test. Drop it down to 45s. Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Nirmoy Das Reviewed-by: Thomas Hellström --- tests/i915/gem_lmem_swapping.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/i915/gem_lmem_swapping.c b

[Intel-gfx] [PATCH i-g-t v2 2/3] test/gem_lmem_swapping: fix physical engine usage

we destroy our newly created contexts(Ashutosh) - Tweak the commit message so that we are talking less nonsense(Tvrtko) - s/i915/fd/ when calling set_persistence Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5192 Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Tvrtko U

[Intel-gfx] [PATCH i-g-t v2 1/3] test/gem_lmem_swapping: account for object rounding

On DG2 the object size might be rounded when allocating lmem. Make sure we account for any rounding up. Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Nirmoy Das Reviewed-by: Thomas Hellström Reviewed-by: Ashutosh Dixit --- tests/i915/gem_lmem_swapping.c | 10 +- 1 file

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 3/4] tests/gem_lmem_swapping: limit lmem to 4G

On 24/03/2022 17:47, Dixit, Ashutosh wrote: On Thu, 24 Mar 2022 07:26:20 -0700, Matthew Auld wrote: @@ -554,6 +560,7 @@ igt_main_args("", long_options, help_str, opt_handler, NULL) igt_fixture { free(regions);

[Intel-gfx] [PATCH 2/2] drm/i915/migrate: move the sanity check

Move the sanity check that both src and dst are never both system memory, which should never happen on discrete, and likely means we have a bug. The only exception is on integrated where we trigger this path in the selftests. Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Nirmoy Das

[Intel-gfx] [PATCH 1/2] drm/i915/ttm: limit where we apply TTM_PL_FLAG_CONTIGUOUS

e when not needed, since the current placement is seen as not compatible. Suggested-by: Thomas Hellström Fixes: 2ed38cec5606 ("drm/i915: opportunistically apply ALLOC_CONTIGIOUS") Signed-off-by: Matthew Auld Cc: Nirmoy Das --- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 3 +++ 1 file c

[Intel-gfx] [CI 0/1] lmem_size modparam

Test-with: 20220324142621.347452-1-matthew.a...@intel.com -- 2.34.1

[Intel-gfx] [CI 1/1] drm/i915: add lmem_size modparam

From: CQ Tang lmem_size is used to limit the amount of lmem. Default is to use hardware available lmem size, when setting this modpraram which is in MB unit. Signed-off-by: CQ Tang Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Nirmoy Das --- drivers/gpu/drm/i915/gt

[Intel-gfx] [PATCH i-g-t 4/4] tests/gem_lmem_swapping: reduce the timeout

300s is way too much for some BAT test. Drop it down to 45s. Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Nirmoy Das --- tests/i915/gem_lmem_swapping.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/i915/gem_lmem_swapping.c b/tests/i915/gem_lmem_swapping.c

[Intel-gfx] [PATCH i-g-t 3/4] tests/gem_lmem_swapping: limit lmem to 4G

From: CQ Tang On some systems lmem can be as large as 16G, which seems to trigger various CI timeouts, and in the best case just takes a long time. For the purposes of the test we should be able to limit to 4G, without any big loss in coverage. Signed-off-by: CQ Tang Signed-off-by: Matthew

[Intel-gfx] [PATCH i-g-t 2/4] test/gem_lmem_swapping: fix physical engine usage

ses: https://gitlab.freedesktop.org/drm/intel/-/issues/5192 Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Nirmoy Das --- tests/i915/gem_lmem_swapping.c | 27 +++ 1 file changed, 19 insertions(+), 8 deletions(-) diff --git a/tests/i915/gem_lmem_swapping.c b/

[Intel-gfx] [PATCH i-g-t 1/4] test/gem_lmem_swapping: account for object rounding

On DG2 the object size might be rounded when allocating lmem. Make sure we account for any rounding up. Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Nirmoy Das --- tests/i915/gem_lmem_swapping.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/tests/i915

[Intel-gfx] [PATCH i-g-t 0/4] Some gem_lmem_swapping tweaks

-- 2.34.1

Re: [Intel-gfx] [PATCH] drm/i915: Decouple engine->sanitize callback on removing the status page

On Wed, 23 Mar 2022 at 09:44, Gwan-gyeong Mun wrote: > > From: Chris Wilson > > We have to be careful not to call into the submission backend's sanitize > callback if we abort the module load and free the status page. Since we > are only using the sanitize callback to cleanup the status page when

Re: [Intel-gfx] [PATCH] drm/i915/display: Add smem fallback allocation for dpt

On Tue, 22 Mar 2022 at 12:06, Juha-Pekka Heikkila wrote: > > On 22.3.2022 12.45, Matthew Auld wrote: > > On Mon, 21 Mar 2022 at 18:36, Juha-Pekka Heikkila > > wrote: > >> > >> On 21.3.2022 14.29, Matthew Auld wrote: > >>> On Fri, 18 Mar

Re: [Intel-gfx] [PATCH] drm/i915/display: Add smem fallback allocation for dpt

On Mon, 21 Mar 2022 at 18:36, Juha-Pekka Heikkila wrote: > > On 21.3.2022 14.29, Matthew Auld wrote: > > On Fri, 18 Mar 2022 at 09:22, Juha-Pekka Heikkila > > wrote: > >> > >> On 17.3.2022 13.55, Matthew Auld wrote: > >>> On Wed, 16 Mar

Re: [Intel-gfx] [PATCH] drm/i915/display: Add smem fallback allocation for dpt

On Fri, 18 Mar 2022 at 09:22, Juha-Pekka Heikkila wrote: > > On 17.3.2022 13.55, Matthew Auld wrote: > > On Wed, 16 Mar 2022 at 22:23, Juha-Pekka Heikkila > > wrote: > >> > >> Add fallback smem allocation for dpt if stolen memory > >> allocatio

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Introduce multitile support

On Sat, 19 Mar 2022 at 02:06, Patchwork wrote: > > Patch Details > Series:Introduce multitile support > URL:https://patchwork.freedesktop.org/series/101551/ > State:failure > Details:https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22617/index.html > > CI Bug Log - changes from CI_DRM_11384_full

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Introduce multitile support

On Fri, 18 Mar 2022 at 08:18, Andi Shyti wrote: > > > • igt@i915_selftest@mock@requests: > > > > □ shard-kbl: PASS -> DMESG-FAIL > > > > □ shard-tglb: PASS -> DMESG-FAIL > > > > □ shard-apl: PASS -> DMESG-FAIL > > > > □ shard-glk: PASS -> DMESG-FAIL > > > > □ shard-

Re: [Intel-gfx] [PATCH v6 4/7] drm/i915/gt: create per-tile sysfs interface

On 18/03/2022 02:10, Andi Shyti wrote: Now that we have tiles we want each of them to have its own interface. A directory "gt/" is created under "cardN/" that will contain as many diroctories as the tiles. In the coming patches tile related interfaces will be added. For now the sysfs gt structur

Re: [Intel-gfx] [PATCH 2/2] drm/doc: add rfc section for small BAR uapi

-Lionel On 18/02/2022 13:22, Matthew Auld wrote: 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 ---   Documen

Re: [Intel-gfx] [PATCH] drm/i915/display: Add smem fallback allocation for dpt

On Wed, 16 Mar 2022 at 22:23, Juha-Pekka Heikkila wrote: > > Add fallback smem allocation for dpt if stolen memory > allocation failed. > > Signed-off-by: Juha-Pekka Heikkila > --- > drivers/gpu/drm/i915/display/intel_dpt.c | 18 ++ > 1 file changed, 14 insertions(+), 4 deletions

Re: [Intel-gfx] Small bar recovery vs compressed content on DG2

On 17/03/2022 08:43, Joonas Lahtinen wrote: Quoting Thomas Hellström (2022-03-16 09:25:16) Hi! Do we somehow need to clarify in the headers the semantics for this? From my understanding when discussing the CCS migration series with Ram, the kernel will never do any resolving (compressing / d

Re: [Intel-gfx] [PATCH v2] drm: Fix a infinite loop condition when order becomes 0

On 16/03/2022 06:34, Arunpravin Paneer Selvam wrote: handle a situation in the condition order-- == min_order, when order = 0 and min_order = 0, leading to order = -1, it now won't exit the loop. To avoid this problem, added a order check in the same condition, (i.e) when order is 0, we return -E

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/7] drm/i915/lmem: don't treat small BAR as an error

On 16/03/2022 00:38, Patchwork wrote: *Patch Details* *Series:* series starting with [CI,1/7] drm/i915/lmem: don't treat small BAR as an error *URL:* https://patchwork.freedesktop.org/series/101398/ *State:*failure *Details:* https://

[Intel-gfx] [CI 4/7] drm/i915: add i915_gem_object_create_region_at()

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 Reviewed-by: Nirmoy Das --- .../drm/i915/display/intel_plane_initial.c| 4

[Intel-gfx] [CI 2/7] drm/i915/stolen: don't treat small BAR as an error

platforms like DG2). For simplicity we don't attempt to support partially mappable stolen. v2: rearrange the io_mapping_init_wc slightly, since the stolen setup might result in reduced io_size. Signed-off-by: Akeem G Abodunrin Co-developed-by: Matthew Auld Signed-off-by: Matthew Auld Cc: T

[Intel-gfx] [CI 5/7] drm/i915/ttm: wire up the object offset

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 Reviewed-by: Nirmoy Das --- .../gpu/drm/i915/gem

[Intel-gfx] [CI 6/7] drm/i915/display: Check mappable aperture when pinning preallocated vma

hna Sripada Cc: Ap Kamal Reviewed-by: Matthew Auld Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Ville Syrjälä Reviewed-by: Nirmoy Das --- drivers/gpu/drm/i915/display/intel_plane_initial.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i

[Intel-gfx] [CI 7/7] drm/i915: fixup the initial fb base on DGFX

address, before allocating from stolen. - Bail if it's not located in dsm. v3: - Scratch that. There doesn't seem to be any relationship with the base and PTE address, on at least DG1. Let's instead just grab the lmem address from the PTE itself. Signed-off-by: Matthew A

[Intel-gfx] [CI 3/7] drm/i915/stolen: consider I915_BO_ALLOC_GPU_ONLY

Keep the behaviour consistent with normal lmem, where we assume CPU access if by default required. Signed-off-by: Matthew Auld Cc: Thomas Hellström Reviewed-by: Nirmoy Das --- drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu

[Intel-gfx] [CI 1/7] drm/i915/lmem: don't treat small BAR as an error

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 Reviewed-by: Nirmoy

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Some more bits for small BAR enabling (rev4)

On Mon, 14 Mar 2022 at 16:49, Patchwork wrote: > > Patch Details > Series:Some more bits for small BAR enabling (rev4) > URL:https://patchwork.freedesktop.org/series/101052/ > State:failure > Details:https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22555/index.html > > CI Bug Log - changes from

Re: [Intel-gfx] [PATCH] drm: Fix a infinite loop condition when order becomes 0

On 14/03/2022 19:40, Arunpravin wrote: handle a situation in the condition order-- == min_order, when order = 0, leading to order = -1, it now won't exit the loop. To avoid this problem, added a order check in the same condition, (i.e) when order is 0, we return -ENOSPC Signed-off-by: Arunpravin

Re: [Intel-gfx] [PATCH] drm/i915: round_up the size to the alignment value

On Mon, 14 Mar 2022 at 19:32, Arunpravin wrote: > > handle instances when size is not aligned with the min_page_size. > Unigine Heaven has allocation requests for example required pages > are 161 and alignment request is 128. To allocate the left over > 33 pages, continues the iteration to find th

[Intel-gfx] [PATCH v3 4/7] drm/i915: add i915_gem_object_create_region_at()

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 Acked-by: Nirmoy Das --- .../drm/i915/display/intel_plane_initial.c| 4 +- drivers

[Intel-gfx] [PATCH v3 1/7] drm/i915/lmem: don't treat small BAR as an error

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 Acked-by: Nirmoy Das

[Intel-gfx] [PATCH v3 5/7] drm/i915/ttm: wire up the object offset

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 Acked-by: Nirmoy Das --- .../gpu/drm/i915/gem

[Intel-gfx] [PATCH v3 3/7] drm/i915/stolen: consider I915_BO_ALLOC_GPU_ONLY

Keep the behaviour consistent with normal lmem, where we assume CPU access if by default required. Signed-off-by: Matthew Auld Cc: Thomas Hellström Acked-by: Nirmoy Das --- drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm

[Intel-gfx] [PATCH v3 2/7] drm/i915/stolen: don't treat small BAR as an error

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 Acked-by: Nirmoy Das --- drivers/gpu/drm/i915/gem/i915_gem_stolen.c

[Intel-gfx] [PATCH v3 7/7] drm/i915: fixup the initial fb base on DGFX

address, before allocating from stolen. - Bail if it's not located in dsm. v3: - Scratch that. There doesn't seem to be any relationship with the base and PTE address, on at least DG1. Let's instead just grab the lmem address from the PTE itself. Signed-off-by: Matthew A

[Intel-gfx] [PATCH v3 6/7] drm/i915/display: Check mappable aperture when pinning preallocated vma

hna Sripada Cc: Ap Kamal Reviewed-by: Matthew Auld Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Ville Syrjälä Acked-by: Nirmoy Das --- drivers/gpu/drm/i915/display/intel_plane_initial.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/disp

[Intel-gfx] [PATCH v3 0/7] Some more bits for small BAR enabling

The leftover bits around dealing with stolen-local memory + small BAR, plus some related fixes. v2: some tweaks based on feedback from Ville v3: directly probe the PTE to derive the physical offset within lmem -- 2.34.1

Re: [Intel-gfx] [PATCH v2 6/8] drm/i915/display: Check mappable aperture when pinning preallocated vma

On Thu, 10 Mar 2022 at 12:28, Matthew Auld wrote: > > From: CQ Tang > > When system does not have mappable aperture, ggtt->mappable_end=0. In > this case if we pass PIN_MAPPABLE when pinning vma, the pinning code > will return -ENOSPC. So conditionally set PIN

Re: [Intel-gfx] [v2] drm/i915/gem: missing boundary check in vm_access leads to OOB read/write

On Wed, 9 Mar 2022 at 11:46, Matthew Auld wrote: > > On 09/03/2022 11:19, Katragadda, MastanX wrote: > > Hi, > > > > can we have ack? or we need to do anything further to get r-o-b. > > There was just the potential strangeness around len <= 0, and exactly > how

Re: [Intel-gfx] [PATCH] drm: remove min_order BUG_ON check

On 10/03/2022 14:47, Arunpravin wrote: On 08/03/22 10:31 pm, Matthew Auld wrote: On 08/03/2022 13:59, Arunpravin wrote: On 07/03/22 10:11 pm, Matthew Auld wrote: On 07/03/2022 14:37, Arunpravin wrote: place BUG_ON(order < min_order) outside do..while loop as it fails Unigine Hea

[Intel-gfx] [PATCH v2 6/8] drm/i915/display: Check mappable aperture when pinning preallocated vma

hna Sripada Cc: Ap Kamal Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_plane_initial.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c b/drivers/gpu/drm/i

[Intel-gfx] [PATCH v2 7/8] drm/i915: fixup the initial fb base on DG1

some offset within lmem, but this also happens to be the exact dsm start, on dg1. Therefore we should only need to fudge the physical address, before allocating from stolen. - Bail if it's not located in dsm. Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Ville Syrjälä --- ..

[Intel-gfx] [PATCH v2 8/8] drm/i915: fixup the initial fb on DG2

On DG2+ the initial fb shouldn't be placed anywhere close to DSM, and so should just be allocated directly from LMEM. Signed-off-by: Matthew Auld Cc: Thomas Hellström --- .../drm/i915/display/intel_plane_initial.c| 46 +++ 1 file changed, 27 insertions(+), 19 dele

[Intel-gfx] [PATCH v2 5/8] drm/i915/ttm: wire up the object offset

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

[Intel-gfx] [PATCH v2 4/8] drm/i915: add i915_gem_object_create_region_at()

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

[Intel-gfx] [PATCH v2 3/8] drm/i915/stolen: consider I915_BO_ALLOC_GPU_ONLY

Keep the behaviour consistent with normal lmem, where we assume CPU access if by default required. Signed-off-by: Matthew Auld Cc: Thomas Hellström --- drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/gem

[Intel-gfx] [PATCH v2 2/8] drm/i915/stolen: don't treat small BAR as an error

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 | 48 -- drivers/gpu/drm

[Intel-gfx] [PATCH v2 1/8] drm/i915/lmem: don't treat small BAR as an error

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

[Intel-gfx] [PATCH v2 0/8] Some more bits for small BAR enabling

The leftover bits around dealing with stolen-local memory + small BAR, plus some related fixes. v2: some tweaks based on feedback from Ville -- 2.34.1

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gem: missing boundary check in vm_access leads to OOB read/write (rev2)

On Thu, 3 Mar 2022 at 06:48, Patchwork wrote: > *Patch Details* > *Series:* drm/i915/gem: missing boundary check in vm_access leads to OOB > read/write (rev2) > *URL:* https://patchwork.freedesktop.org/series/100932/ > *State:* failure > *Details:* > https://intel-gfx-ci.01.org/tree/drm-tip/Patch

Re: [Intel-gfx] [v2] drm/i915/gem: missing boundary check in vm_access leads to OOB read/write

hen feel free to add, Reviewed-by: Matthew Auld Thanks, Mastan -Original Message- From: Katragadda, MastanX Sent: 09 March 2022 07:16 To: Auld, Matthew ; Tvrtko Ursulin ; intel-gfx@lists.freedesktop.org Cc: Surendrakumar Upadhyay, TejaskumarX Subject: RE: [Intel-gfx] [v2] drm/i915/

Re: [Intel-gfx] [PATCH] drm: remove min_order BUG_ON check

On 08/03/2022 13:59, Arunpravin wrote: On 07/03/22 10:11 pm, Matthew Auld wrote: On 07/03/2022 14:37, Arunpravin wrote: place BUG_ON(order < min_order) outside do..while loop as it fails Unigine Heaven benchmark. Unigine Heaven has buffer allocation requests for example required pages

Re: [Intel-gfx] [PATCH] drm/doc: pull in drm_buddy.c

On 09/02/2022 07:32, Christian König wrote: Am 08.02.22 um 16:12 schrieb Matthew Auld: 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 Reviewed-by: Christian König Thanks. Could you also push this

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gtt: reduce overzealous alignment constraints for GGTT (rev3)

On 07/03/2022 16:56, Patchwork wrote: *Patch Details* *Series:* drm/i915/gtt: reduce overzealous alignment constraints for GGTT (rev3) *URL:* https://patchwork.freedesktop.org/series/100991/ *State:*failure *Details:* https://intel-gf

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: opportunistically apply ALLOC_CONTIGIOUS (rev2)

On 07/03/2022 17:52, Patchwork wrote: *Patch Details* *Series:* drm/i915: opportunistically apply ALLOC_CONTIGIOUS (rev2) *URL:* https://patchwork.freedesktop.org/series/99631/ *State:*failure *Details:* https://intel-gfx-ci.01.or

Re: [Intel-gfx] [PATCH 7/8] drm/i915: fixup the initial fb base on DG1

On Mon, 7 Mar 2022 at 18:41, Ville Syrjälä wrote: > > On Mon, Mar 07, 2022 at 06:26:32PM +, Matthew Auld wrote: > > On 07/03/2022 17:06, Ville Syrjälä wrote: > > > On Mon, Mar 07, 2022 at 10:32:36AM +, Matthew Auld wrote: > > >> On 04/03/2022 19:33, Vi

Re: [Intel-gfx] [PATCH 7/8] drm/i915: fixup the initial fb base on DG1

On 07/03/2022 17:06, Ville Syrjälä wrote: On Mon, Mar 07, 2022 at 10:32:36AM +, Matthew Auld wrote: On 04/03/2022 19:33, Ville Syrjälä wrote: On Fri, Mar 04, 2022 at 05:23:32PM +, Matthew Auld wrote: The offset we get looks to be the exact start of DSM, but the inital_plane_vma

Re: [Intel-gfx] [PATCH] drm: remove min_order BUG_ON check

On 07/03/2022 14:37, Arunpravin wrote: place BUG_ON(order < min_order) outside do..while loop as it fails Unigine Heaven benchmark. Unigine Heaven has buffer allocation requests for example required pages are 161 and alignment request is 128. To allocate the remaining 33 pages, continues the ite

Re: [Intel-gfx] [PATCH v3 4/6] drm/i915/gem: Add extra pages in ttm_tt for ccs data

On 07/03/2022 13:40, Ramalingam C wrote: On Xe-HP and later devices, dedicated compression control state (CCS) stored in local memory is used for each surface, to support the 3D and media compression formats. The memory required for the CCS of the entire local memory is 1/256 of the local memory

Re: [Intel-gfx] [PATCH 7/8] drm/i915: fixup the initial fb base on DG1

On 04/03/2022 19:33, Ville Syrjälä wrote: On Fri, Mar 04, 2022 at 05:23:32PM +, Matthew Auld wrote: The offset we get looks to be the exact start of DSM, but the inital_plane_vma expects the address to be relative. Signed-off-by: Matthew Auld Cc: Thomas Hellström --- .../drm/i915

[Intel-gfx] [PATCH] drm/i915: stop checking for NULL vma->obj

This is no longer possible since e6e1a304d759 ("drm/i915: vma is always backed by an object."). Signed-off-by: Matthew Auld Cc: Thomas Hellström --- drivers/gpu/drm/i915/i915_vma.c | 17 +++-- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/drivers/gp

Re: [Intel-gfx] [CI 2/2] drm/i915: limit the async bind to bind_async_flags

On 04/03/2022 16:41, Thomas Hellström wrote: On Fri, 2022-03-04 at 09:59 +, Matthew Auld wrote: If the vm doesn't request async binding, like for example with the dpt, then we should be able to skip the async path and avoid calling i915_vm_lock_objects() altogether. Currently if we h

[Intel-gfx] [PATCH 8/8] drm/i915: fixup the initial fb on DG2

On DG2+ the initial fb shouldn't be placed anywhere close to DSM, and so should just be allocated directly from LMEM. Signed-off-by: Matthew Auld Cc: Thomas Hellström --- drivers/gpu/drm/i915/display/intel_plane_initial.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-)

[Intel-gfx] [PATCH 7/8] drm/i915: fixup the initial fb base on DG1

The offset we get looks to be the exact start of DSM, but the inital_plane_vma expects the address to be relative. Signed-off-by: Matthew Auld Cc: Thomas Hellström --- .../drm/i915/display/intel_plane_initial.c| 22 +++ 1 file changed, 18 insertions(+), 4 deletions(-) diff

[Intel-gfx] [PATCH 6/8] drm/i915/display: Check mappable aperture when pinning preallocated vma

hna Sripada Cc: Ap Kamal Signed-off-by: Matthew Auld Cc: Thomas Hellström --- drivers/gpu/drm/i915/display/intel_plane_initial.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c b/drivers/gpu/drm/i915/disp

[Intel-gfx] [PATCH 4/8] drm/i915/buddy: tweak CONTIGUOUS rounding

If this is an actual range allocation, and not some bias thing then the resultant allocation will already be naturally contiguous without needing any power-of-two rounding. Signed-off-by: Matthew Auld Cc: Thomas Hellström --- drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 3 ++- 1 file

[Intel-gfx] [PATCH 5/8] drm/i915/ttm: wire up the object offset

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

[Intel-gfx] [PATCH 3/8] drm/i915: add i915_gem_object_create_region_at()

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

[Intel-gfx] [PATCH 2/8] drm/i915/stolen: don't treat small BAR as an error

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

[Intel-gfx] [PATCH 1/8] drm/i915/lmem: don't treat small BAR as an error

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

[Intel-gfx] [PATCH 0/8] Some more bits for small BAR enabling

The leftover bits around dealing with stolen-local memory + small BAR, plus some related fixes. -- 2.34.1

[Intel-gfx] [CI 2/2] drm/i915: limit the async bind to bind_async_flags

patch regardless of the bind_async setting, and then later still end up just doing i915_gem_object_wait_moving_fence() anyway. Alternatively we would need to add dummy scratch object which can be locked, just for the dpt. Suggested-by: Thomas Hellström Signed-off-by: Matthew Auld Cc: Stanislav Liso

[Intel-gfx] [CI 1/2] drm/i915/fbdev: fixup setting screen_size

t;size here, which should be the backing store size. Some more rework is needed here to stop using node.size in some other places. Signed-off-by: Matthew Auld Cc: Stanislav Lisovskiy --- drivers/gpu/drm/i915/display/intel_fbdev.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

[Intel-gfx] [CI 2/2] drm/i915/dpt: setup dummy scratch

er vm. Signed-off-by: Matthew Auld Cc: Stanislav Lisovskiy --- drivers/gpu/drm/i915/display/intel_dpt.c | 53 1 file changed, 44 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c b/drivers/gpu/drm/i915/display/intel_dpt.c index 15b2716

[Intel-gfx] [CI 1/2] drm/i915/fbdev: fixup setting screen_size

Since we are actually mapping the object and not the vma, when dealing with LMEM, we should be careful and use the obj->base.size here, since the vma could have all kinds of funny padding constraints. Signed-off-by: Matthew Auld Cc: Stanislav Lisovskiy --- drivers/gpu/drm/i915/disp

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Remove the vm open count

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

Re: [Intel-gfx] [PATCH] drm/i915/dg2: Use I915_BO_ALLOC_CONTIGUOUS flag for DPT

On Thu, 9 Dec 2021 at 17:00, Stanislav Lisovskiy wrote: > > Do mapping using CONTIGUOUS flag - otherwise > i915_gem_object_is_contiguous warn is triggered. > > Signed-off-by: Stanislav Lisovskiy As a temporary fix, Reviewed-by: Matthew Auld > --- > drivers/gpu/drm/i91

Re: [Intel-gfx] [PATCH] drm/i915/selftests: check the return value of kstrdup()

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

Re: [Intel-gfx] [PATCH] drm/i915/selftests: check the return value of kstrdup()

gned-off-by: Xiaoke Wang Reviewed-by: Matthew Auld

Re: [Intel-gfx] [v2] drm/i915/gem: missing boundary check in vm_access leads to OOB read/write

On 03/03/2022 09:00, Tvrtko Ursulin wrote: + Matt On 03/03/2022 06:04, Mastan Katragadda wrote: Intel ID: PSIRT-PTK0002429 A missing bounds check in vm_access()can lead to an out-of-bounds read or write in the adjacent memory area.The len attribute is not validated before the memcpy at  [1]

[Intel-gfx] [PATCH] drm/i915/gtt: reduce overzealous alignment constraints for GGTT

/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

<    2   3   4   5   6   7   8   9   10   11   >