Re: [RFC] drm/i915: Allow dmabuf mmap forwarding

On 13/12/2023 14:13, Christian König wrote: Am 13.12.23 um 12:46 schrieb Tvrtko Ursulin: Hi, On 12/12/2023 14:10, Christian König wrote: Hi Tvrtko, Thanks for pointing this mail out once more, I've totally missed it. That's okay, if it was really urgent I would have re-raised

Re: [PATCH v3 0/9] drm/i915: Replace kmap_atomic() with kmap_local_page()

On 14/12/2023 15:04, Zhao Liu wrote: On Thu, Dec 14, 2023 at 02:35:26PM +, Tvrtko Ursulin wrote: Date: Thu, 14 Dec 2023 14:35:26 + From: Tvrtko Ursulin Subject: Re: [PATCH v3 0/9] drm/i915: Replace kmap_atomic() with kmap_local_page() On 14/12/2023 13:45, Tvrtko Ursulin wrote

Re: [PATCH v3 0/9] drm/i915: Replace kmap_atomic() with kmap_local_page()

On 14/12/2023 13:45, Tvrtko Ursulin wrote: Hi Zhao, On 14/12/2023 13:19, Zhao Liu wrote: Hi maintainers, Just kindly ping. May I ask if this refresh version could be merged into the next tree of the i915? I certainly spotted your series last week or so but then it slipped my mind to go

Re: [PATCH v3 0/9] drm/i915: Replace kmap_atomic() with kmap_local_page()

Hi Zhao, On 14/12/2023 13:19, Zhao Liu wrote: Hi maintainers, Just kindly ping. May I ask if this refresh version could be merged into the next tree of the i915? I certainly spotted your series last week or so but then it slipped my mind to go through it. Should be able to go through it to

Re: â Fi.CI.BAT: failure for drm/i915: (stolen) memory region related fixes

On 13/12/2023 17:24, Tvrtko Ursulin wrote: Hi Andrzej, On 13/12/2023 16:13, Andrzej Hajda wrote: On 13.12.2023 02:37, Patchwork wrote: *Patch Details* *Series:*    drm/i915: (stolen) memory region related fixes *URL:*    https://patchwork.freedesktop.org/series/127721/ <ht

Re: â Fi.CI.BAT: failure for drm/i915: (stolen) memory region related fixes

Hi Andrzej, On 13/12/2023 16:13, Andrzej Hajda wrote: On 13.12.2023 02:37, Patchwork wrote: *Patch Details* *Series:*    drm/i915: (stolen) memory region related fixes *URL:*    https://patchwork.freedesktop.org/series/127721/ *State:*    f

Re: [RFC] drm/i915: Allow dmabuf mmap forwarding

ing and no known real use cases affected. Am 12.12.23 um 11:37 schrieb Tvrtko Ursulin: On 25/09/2023 14:16, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Allow mmap forwarding for imported buffers in order to allow minigbm mmap to work on aperture-less platforms such as Meteorlake. So far i9

Re: [PATCH] drm/i915/uapi: fix typos/spellos and punctuation

tical. Signed-off-by: Randy Dunlap Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: Tvrtko Ursulin Cc: intel-gfx@lists.freedesktop.org --- include/uapi/drm/i915_drm.h | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff -- a/include/uapi/drm/i915_drm.h b/inclu

Re: [RFC] drm/i915: Allow dmabuf mmap forwarding

On 25/09/2023 14:16, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Allow mmap forwarding for imported buffers in order to allow minigbm mmap to work on aperture-less platforms such as Meteorlake. So far i915 did not allow mmap on imported buffers but from minigbm perspective that worked

Re: [PATCH 1/2] drm/i915/selftests: Fix engine reset count storage for multi-tile

On 07/12/2023 11:46, Andi Shyti wrote: On Thu, Dec 07, 2023 at 11:43:28AM +, Tvrtko Ursulin wrote: On 07/12/2023 11:26, Andi Shyti wrote: Hi Tvrtko, Engine->id namespace is per-tile so struct igt_live_test->reset_engine[] needs to be two-dimensional so engine reset counts fr

Re: [PATCH 1/2] drm/i915/selftests: Fix engine reset count storage for multi-tile

counts would be incorrect for same engine instance on different tiles. Signed-off-by: Tvrtko Ursulin Fixes: 0c29efa23f5c ("drm/i915/selftests: Consider multi-gt instead of to_gt()") Reported-by: Alan Previn Teres Alexis Cc: Tejas Upadhyay Cc: Andi Shyti Cc: Daniele Ceraolo Spurio

Re: [PATCH 2/2] drm/i915: Use internal class when counting engine resets

On 06/12/2023 00:52, Daniele Ceraolo Spurio wrote: On 12/1/2023 4:21 AM, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Commit 503579448db9 ("drm/i915/gsc: Mark internal GSC engine with reserved uabi class") made the GSC0 engine not have a valid uabi class and so broke the en

Re: [Intel-gfx] [PATCH] drm/i915/gt: Reduce log severity on reset prepare.

On 05/12/2023 10:44, Nirmoy Das wrote: Hi Tvrtko, On 12/5/2023 11:05 AM, Tvrtko Ursulin wrote: On 05/12/2023 08:50, Nirmoy Das wrote: Hi Tvrtko, On 12/5/2023 9:34 AM, Tvrtko Ursulin wrote: On 01/12/2023 15:44, Nirmoy Das wrote: gen8_engine_reset_prepare() can fail when HW fails to set

Re: [Intel-gfx] [PATCH] drm/i915/gt: Reduce log severity on reset prepare.

On 05/12/2023 08:50, Nirmoy Das wrote: Hi Tvrtko, On 12/5/2023 9:34 AM, Tvrtko Ursulin wrote: On 01/12/2023 15:44, Nirmoy Das wrote: gen8_engine_reset_prepare() can fail when HW fails to set RESET_CTL_READY_TO_RESET bit. In some cases this is not fatal error as driver will retry. Let the

Re: [Intel-gfx] [PATCH] drm/i915/gt: Reduce log severity on reset prepare.

or not. No complaints per se but I don't see the caller deciding and it is not really reducing log level but converting to trace. So commit message and patch do not align for me which I think should be improved. Regards, Tvrtko Cc: Tvrtko Ursulin Cc: John Harrison Cc: Andi Shyt

[Intel-gfx] [PATCH 2/2] drm/i915: Use internal class when counting engine resets

From: Tvrtko Ursulin Commit 503579448db9 ("drm/i915/gsc: Mark internal GSC engine with reserved uabi class") made the GSC0 engine not have a valid uabi class and so broke the engine reset counting, which in turn was made class based in cb823ed9915b ("drm/i915/gt: Use intel_gt

[Intel-gfx] [PATCH 1/2] drm/i915/selftests: Fix engine reset count storage for multi-tile

From: Tvrtko Ursulin Engine->id namespace is per-tile so struct igt_live_test->reset_engine[] needs to be two-dimensional so engine reset counts from all tiles can be stored with no aliasing. With aliasing, if we had a real multi-tile platform, the reset counts would be incorrect for same

Re: [Intel-gfx] [PATCH v6] drm/i915: handle uncore spinlock when not available

On 30/11/2023 12:26, Coelho, Luciano wrote: On Thu, 2023-11-30 at 12:21 +, Tvrtko Ursulin wrote: On 30/11/2023 11:35, Luca Coelho wrote: The uncore code may not always be available (e.g. when we build the display code with Xe), so we can't always rely on having the uncore's spi

Re: [Intel-gfx] [PATCH v6] drm/i915: handle uncore spinlock when not available

ed in these new functions and all such logic inside the display code. Cc: Tvrtko Ursulin Cc: Jani Nikula Cc: Ville Syrjala Reviewed-by: Rodrigo Vivi Signed-off-by: Luca Coelho --- In v2: * Renamed uncore_spin_*() to intel_spin_*() * Corrected the order: save, lock, unlock,

Re: [Intel-gfx] [PATCH v5] drm/i915/pxp: Add drm_dbgs for critical PXP events.

On 22/11/2023 19:15, Alan Previn wrote: Debugging PXP issues can't even begin without understanding precedding sequence of important events. Add drm_dbg into the most important PXP events. v5 : - rebase. v4 : - rebase. v3 : - move gt_dbg to after mutex block in function i915_gsc

Re: [Intel-gfx] [Intel-xe] [PATCH] drm/i915: don't use uncore spinlock to protect critical section in vblank

On 17/11/2023 12:21, Coelho, Luciano wrote: Adding Tvrtko, for some reason he didn't get CCed before. On Fri, 2023-11-17 at 11:26 +0200, Ville Syrjälä wrote: On Fri, Nov 17, 2023 at 10:41:43AM +0200, Ville Syrjälä wrote: On Fri, Nov 17, 2023 at 08:05:21AM +, Coelho, Luciano wrote: Than

Re: [Intel-gfx] [PATCH v4 3/3] drm/i915/gt: Timeout when waiting for idle in suspending

On 14/11/2023 19:48, Teres Alexis, Alan Previn wrote: On Tue, 2023-11-14 at 17:52 +, Tvrtko Ursulin wrote: On 14/11/2023 17:37, Teres Alexis, Alan Previn wrote: On Tue, 2023-11-14 at 17:27 +, Tvrtko Ursulin wrote: On 13/11/2023 17:57, Teres Alexis, Alan Previn wrote: On Wed, 2023

[Intel-gfx] [PATCH v2] drm/i915/gsc: Mark internal GSC engine with reserved uabi class

From: Tvrtko Ursulin The GSC CS is not exposed to the user, so we skipped assigning a uabi class number for it. However, the trace logs use the uabi class and instance to identify the engine, so leaving uabi class unset makes the GSC CS show up as the RCS in those logs. Given that the engine is

Re: [Intel-gfx] [char-misc-next 3/4] mei: pxp: re-enable client on errors

On 14/11/2023 15:31, Teres Alexis, Alan Previn wrote: On Tue, 2023-11-14 at 16:00 +0200, Ville Syrjälä wrote: On Wed, Oct 11, 2023 at 02:01:56PM +0300, Tomas Winkler wrote: From: Alexander Usyskin Disable and enable mei-pxp client on errors to clean the internal state. This broke i915 on

Re: [Intel-gfx] [PATCH v2] drm/i915: do not clean GT table on error path

enable_rpm_wakeref_asserts(&i915->runtime_pm); i915_driver_late_release(i915); --- base-commit: 1489bab52c281a869295414031a56506a375b036 change-id: 20231114-dont_clean_gt_on_error_path-91cd9c3caa0a Looks okay. Reviewed-by: Tvrtko Ursulin Although on the overall driver init/exit

[Intel-gfx] [PATCH] drm/i915/gsc: Mark internal GSC engine with reserved uabi class

From: Tvrtko Ursulin The GSC CS is not exposed to the user, so we skipped assigning a uabi class number for it. However, the trace logs use the uabi class and instance to identify the engine, so leaving uabi class unset makes the GSC CS show up as the RCS in those logs. Given that the engine is

Re: [Intel-gfx] [PATCH] drm/i915: do not clean GT table on error path

On 14/11/2023 09:48, Andrzej Hajda wrote: The only task of intel_gt_release_all is to zero gt table. Calling it on error path prevents intel_gt_driver_late_release_all (called from i915_driver_late_release) to cleanup GTs, causing leakage. After i915_driver_late_release GT array is not used any

Re: [Intel-gfx] [PATCH v4 3/3] drm/i915/gt: Timeout when waiting for idle in suspending

On 14/11/2023 17:37, Teres Alexis, Alan Previn wrote: On Tue, 2023-11-14 at 17:27 +, Tvrtko Ursulin wrote: On 13/11/2023 17:57, Teres Alexis, Alan Previn wrote: On Wed, 2023-10-25 at 13:58 +0100, Tvrtko Ursulin wrote: On 04/10/2023 18:59, Teres Alexis, Alan Previn wrote: On Thu, 2023

Re: [Intel-gfx] [PATCH v4 3/3] drm/i915/gt: Timeout when waiting for idle in suspending

On 13/11/2023 17:57, Teres Alexis, Alan Previn wrote: On Wed, 2023-10-25 at 13:58 +0100, Tvrtko Ursulin wrote: On 04/10/2023 18:59, Teres Alexis, Alan Previn wrote: On Thu, 2023-09-28 at 13:46 +0100, Tvrtko Ursulin wrote: On 27/09/2023 17:36, Teres Alexis, Alan Previn wrote: alan:snip It

Re: [Intel-gfx] [PATCH] drm/i915/gsc: Assign a uabi class number to the GSC CS

On 14/11/2023 17:03, Daniele Ceraolo Spurio wrote: On 11/13/2023 8:46 AM, Tvrtko Ursulin wrote: On 13/11/2023 15:51, Daniele Ceraolo Spurio wrote: On 11/10/2023 4:00 AM, Tvrtko Ursulin wrote: On 09/11/2023 23:53, Daniele Ceraolo Spurio wrote: The GSC CS is not exposed to the user, so we

Re: [Intel-gfx] [PATCH] drm/i915/gsc: Assign a uabi class number to the GSC CS

On 13/11/2023 15:51, Daniele Ceraolo Spurio wrote: On 11/10/2023 4:00 AM, Tvrtko Ursulin wrote: On 09/11/2023 23:53, Daniele Ceraolo Spurio wrote: The GSC CS is not exposed to the user, so we skipped assigning a uabi class number for it. However, the trace logs use the uabi class and

[Intel-gfx] [PATCH 2/2] drm/i915: Add __rcu annotation to cursor when iterating client objects

From: Tvrtko Ursulin __rcu annotation is needed to avoid the sparse warnings such as: .../i915_drm_client.c:92:9: sparse: sparse: incompatible types in comparison expression (different address spaces): .../i915_drm_client.c:92:9: sparse:struct list_head [noderef] __rcu

[Intel-gfx] [PATCH 1/2] drm/i915: Remove return type from i915_drm_client_remove_object

From: Tvrtko Ursulin There is no need to return anything in the version which was merged and also the implementation of the !CONFIG_PROC_FS wasn't returning anything, causing a build failure there. Signed-off-by: Tvrtko Ursulin Fixes: e4ae85e364fc ("drm/i915: Add ability for track

Re: [Intel-gfx] [PATCH] drm/i915/gsc: Assign a uabi class number to the GSC CS

-by: Daniele Ceraolo Spurio Cc: Tvrtko Ursulin Cc: Alan Previn Cc: Matt Roper --- drivers/gpu/drm/i915/gt/intel_engine_user.c | 17 - drivers/gpu/drm/i915/gt/intel_engine_user.h | 4 drivers/gpu/drm/i915/i915_drm_client.h | 2 +- drivers/gpu/drm/i915/i915_drv.h

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/6] drm/i915: Add ability for tracking buffer objects per client (rev5)

On 09/11/2023 23:54, Patchwork wrote: *Patch Details* *Series:* series starting with [CI,1/6] drm/i915: Add ability for tracking buffer objects per client (rev5) *URL:* https://patchwork.freedesktop.org/series/126064/ *State:*failure

Re: [Intel-gfx] [PATCH] Remove custom dumb_map_offset implementations in i915 driver

On 10/11/2023 10:58, Dipam Turkar wrote: Making i915 use drm_gem_create_mmap_offset() instead of its custom implementations for associating GEM object with a fake offset. Does it compile? Regards, Tvrtko Signed-off-by: Dipam Turkar --- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 192 ---

[Intel-gfx] [CI 4/6] drm/i915: Account ring buffer and context state storage

From: Tvrtko Ursulin Account ring buffers and logical context space against the owning client memory usage stats. Signed-off-by: Tvrtko Ursulin Reviewed-by: Aravind Iddamsetty --- drivers/gpu/drm/i915/gt/intel_context.c | 14 ++ drivers/gpu/drm/i915/i915_drm_client.c | 10

[Intel-gfx] [CI 2/6] drm/i915: Record which client owns a VM

From: Tvrtko Ursulin To enable accounting of indirect client memory usage (such as page tables) in the following patch, lets start recording the creator of each PPGTT. Signed-off-by: Tvrtko Ursulin Reviewed-by: Aravind Iddamsetty --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 11

[Intel-gfx] [CI 6/6] drm/i915: Implement fdinfo memory stats printing

From: Tvrtko Ursulin Use the newly added drm_print_memory_stats helper to show memory utilisation of our objects in drm/driver specific fdinfo output. To collect the stats we walk the per memory regions object lists and accumulate object size into the respective drm_memory_stats categories. v2

[Intel-gfx] [CI 5/6] drm/i915: Add stable memory region names

From: Tvrtko Ursulin At the moment memory region names are a bit too varied and too inconsistent to be used for ABI purposes, like for upcoming fdinfo memory stats. System memory can be either system or system-ttm. Local memory has the instance number appended, others do not. Not only

[Intel-gfx] [CI 3/6] drm/i915: Track page table backing store usage

From: Tvrtko Ursulin Account page table backing store against the owning client memory usage stats. Signed-off-by: Tvrtko Ursulin Reviewed-by: Aravind Iddamsetty --- drivers/gpu/drm/i915/gt/intel_gtt.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/gt

[Intel-gfx] [CI 1/6] drm/i915: Add ability for tracking buffer objects per client

From: Tvrtko Ursulin In order to show per client memory usage lets add some infrastructure which enables tracking buffer objects owned by clients. We add a per client list protected by a new per client lock and to support delayed destruction (post client exit) we make tracked objects hold

Re: [Intel-gfx] [PATCH i-g-t 2/9] tests/i915/drm_fdinfo: Stress test context close versus fdinfo reads

On 03/11/2023 18:32, Kamil Konieczny wrote: Hi Tvrtko, On 2023-10-12 at 09:15:40 +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin A short smoke tests to exercise fdinfo reads in parallel to contexts getting created and destroyed. Signed-off-by: Tvrtko Ursulin --- tests/intel

[Intel-gfx] [CI 6/6] drm/i915: Implement fdinfo memory stats printing

From: Tvrtko Ursulin Use the newly added drm_print_memory_stats helper to show memory utilisation of our objects in drm/driver specific fdinfo output. To collect the stats we walk the per memory regions object lists and accumulate object size into the respective drm_memory_stats categories. v2

[Intel-gfx] [CI 3/6] drm/i915: Track page table backing store usage

From: Tvrtko Ursulin Account page table backing store against the owning client memory usage stats. Signed-off-by: Tvrtko Ursulin Reviewed-by: Aravind Iddamsetty --- drivers/gpu/drm/i915/gt/intel_gtt.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/gt

[Intel-gfx] [CI 4/6] drm/i915: Account ring buffer and context state storage

From: Tvrtko Ursulin Account ring buffers and logical context space against the owning client memory usage stats. Signed-off-by: Tvrtko Ursulin Reviewed-by: Aravind Iddamsetty --- drivers/gpu/drm/i915/gt/intel_context.c | 14 ++ drivers/gpu/drm/i915/i915_drm_client.c | 10

[Intel-gfx] [CI 5/6] drm/i915: Add stable memory region names

From: Tvrtko Ursulin At the moment memory region names are a bit too varied and too inconsistent to be used for ABI purposes, like for upcoming fdinfo memory stats. System memory can be either system or system-ttm. Local memory has the instance number appended, others do not. Not only

[Intel-gfx] [CI 1/6] drm/i915: Add ability for tracking buffer objects per client

From: Tvrtko Ursulin In order to show per client memory usage lets add some infrastructure which enables tracking buffer objects owned by clients. We add a per client list protected by a new per client lock and to support delayed destruction (post client exit) we make tracked objects hold

[Intel-gfx] [CI 2/6] drm/i915: Record which client owns a VM

From: Tvrtko Ursulin To enable accounting of indirect client memory usage (such as page tables) in the following patch, lets start recording the creator of each PPGTT. Signed-off-by: Tvrtko Ursulin Reviewed-by: Aravind Iddamsetty --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 11

[Intel-gfx] [CI 0/6] fdinfo memory CI run

From: Tvrtko Ursulin Test-with: 20231106123518.588528-1-tvrtko.ursu...@linux.intel.com Tvrtko Ursulin (6): drm/i915: Add ability for tracking buffer objects per client drm/i915: Record which client owns a VM drm/i915: Track page table backing store usage drm/i915: Account ring buffer

[Intel-gfx] [CI 9/9] tools/intel_gpu_top: Add ability to show memory region breakdown

From: Tvrtko Ursulin Similar as we can toggle between aggregated engines and clients, add the capability to toggle between aggregated and per memory region stats. It starts in aggregated mode by default and interactive command 'm' and command line switch '-m' can be used t

[Intel-gfx] [CI 8/9] tools/intel_gpu_top: Add per client memory info

From: Tvrtko Ursulin JSON output has the full breakdown but for now the interactive mode only shows total and resident aggregated for all memory regions. Signed-off-by: Tvrtko Ursulin Reviewed-by: Kamil Konieczny --- tools/intel_gpu_top.c | 114 +- 1

[Intel-gfx] [CI 7/9] tools/intel_gpu_top: Fully wrap clients operations

From: Tvrtko Ursulin Wrap all operations on clients via the Intel specific wrappers in order to simplify upcoming work. Signed-off-by: Tvrtko Ursulin Reviewed-by: Kamil Konieczny --- tools/intel_gpu_top.c | 42 ++ 1 file changed, 22 insertions(+), 20

[Intel-gfx] [CI 6/9] lib/igt_drm_clients: Allow passing in the memory region map

From: Tvrtko Ursulin Same concept as with the engine map, allowing callers to pass in fixed map of names to indices, simplifying their implementation and avoiding auto-detection while parsing. Signed-off-by: Tvrtko Ursulin Reviewed-by: Kamil Konieczny --- lib/igt_drm_clients.c | 5 +++-- lib

[Intel-gfx] [CI 5/9] lib/igt_drm_clients: Fix client id type confusion

From: Tvrtko Ursulin Igt_drm_fdinfo defines it as an unsigned long so it is best that it matches here as well. Signed-off-by: Tvrtko Ursulin Reviewed-by: Kamil Konieczny --- lib/igt_drm_clients.c | 2 +- lib/igt_drm_clients.h | 2 +- tools/intel_gpu_top.c | 2 +- 3 files changed, 3

[Intel-gfx] [CI 4/9] lib/igt_drm_fdinfo: Copy over region map name on match

From: Tvrtko Ursulin I will need some record of which regions were found for intel_gpu_top so lets just copy over the region name from the map on the first match. Signed-off-by: Tvrtko Ursulin Reviewed-by: Kamil Konieczny --- lib/igt_drm_fdinfo.c | 4 1 file changed, 4 insertions

[Intel-gfx] [CI 3/9] tests/i915/drm_fdinfo: Add some memory info tests

From: Tvrtko Ursulin A few basic smoke tests to check per client memory info looks legit. Signed-off-by: Tvrtko Ursulin Reviewed-by: Kamil Konieczny --- tests/intel/drm_fdinfo.c | 217 +++ 1 file changed, 217 insertions(+) diff --git a/tests/intel

[Intel-gfx] [CI 2/9] tests/i915/drm_fdinfo: Stress test context close versus fdinfo reads

From: Tvrtko Ursulin A short smoke tests to exercise fdinfo reads in parallel to contexts getting created and destroyed. Signed-off-by: Tvrtko Ursulin Reviewed-by: Kamil Konieczny --- tests/intel/drm_fdinfo.c | 68 1 file changed, 68 insertions

[Intel-gfx] [CI 1/9] tests/i915/drm_fdinfo: Check engine info is supported

From: Tvrtko Ursulin On top of checking that parsing works, check that there are some engines present. This will be needed once the memory stats are added and so return value from __igt_parse_drm_fdinfo() will then be possible to be greater than zero even when engine stats are not supported

Re: [Intel-gfx] [PATCH] drm/i915/mtl: Print SSEU information of all GTs for debugfs

On 03/11/2023 17:24, Matt Roper wrote: On Fri, Nov 03, 2023 at 11:17:18AM +, Tvrtko Ursulin wrote: On 03/11/2023 05:29, Gareth Yu wrote: Print another SSEU information addition to the first one. Cc : Tejas Upadhyay Cc : Matt Roper Cc : Ville Syrjälä Signed-off-by: Gareth Yu

Re: [Intel-gfx] [PATCH v2] drm/i915: Fix potential spectre vulnerability

c7600f7 ("drm/i915/gem: Use the proto-context to handle create parameters (v5)") Cc: # v5.15+ Signed-off-by: Kunwu Chan Suggested-by: Tvrtko Ursulin Reviewed-by: Tvrtko Ursulin Link: https://lore.kernel.org/all/20231102101642.52988-1-chen...@kylinos.cn --- drivers/gpu/drm/i915/gem

[Intel-gfx] [CI 2/2] drm/i915: Remove xehpsdv support

From: Tvrtko Ursulin XeHP SDV was a pre-production hardware used to bring up PVC and was not generally available and has since been decided will be supported in the new xe driver and not i915. v2: * Correct historical fact SDV was for PVC, not ATS. (John) Signed-off-by: Tvrtko Ursulin Cc

[Intel-gfx] [CI 1/2] drm/i915: Remove incomplete PVC plumbing

From: Tvrtko Ursulin PVC support will not be coming to i915 so get rid of its partial enablement and reduce the driver maintenance burden. Signed-off-by: Tvrtko Ursulin Reviewed-by: Andi Shyti Reviewed-by: Andrzej Hajda --- .../gpu/drm/i915/gem/i915_gem_object_types.h | 2 +- drivers/gpu

Re: [Intel-gfx] [PATCH] drm/i915/mtl: Print SSEU information of all GTs for debugfs

On 03/11/2023 05:29, Gareth Yu wrote: Print another SSEU information addition to the first one. Cc : Tejas Upadhyay Cc : Matt Roper Cc : Ville Syrjälä Signed-off-by: Gareth Yu --- drivers/gpu/drm/i915/i915_debugfs.c | 13 ++--- drivers/gpu/drm/i915/i915_gpu_error.c | 6 +-

[Intel-gfx] [CI] drm/i915: Fix potential spectre vulnerability

# v5.15+ Signed-off-by: Kunwu Chan Reviewed-by: Tvrtko Ursulin Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c index 9a9

Re: [Intel-gfx] [PATCH 0/5] drm/i915/pmu: hide struct i915_pmu

On 02/11/2023 16:47, Jani Nikula wrote: On Thu, 02 Nov 2023, Tvrtko Ursulin wrote: On 02/11/2023 15:42, Jani Nikula wrote: The implementation details of pmu should be implementation details hidden inside i915_pmu.c. Make it so. Don't tell me i915->pmu bothers xe somehow? It

Re: [Intel-gfx] [PATCH v3] drm/i915: handle uncore spinlock when not available

On 03/11/2023 08:58, Coelho, Luciano wrote: On Fri, 2023-11-03 at 03:31 +, Vivi, Rodrigo wrote: Any other suggestions? I think it will boil down to the reason uncore lock is held over the respective sections ie. the comment in i915_get_crtc_scanoutpos. If it is timing sensitive to the

Re: [Intel-gfx] [PATCH] drm/i915/mtl: Increase guard pages when vt-d is enabled

On 02/11/2023 22:14, Sripada, Radhakrishna wrote: Hi Tvrtko, -Original Message- From: Tvrtko Ursulin Sent: Thursday, November 2, 2023 10:41 AM To: Hajda, Andrzej ; Sripada, Radhakrishna ; intel-gfx@lists.freedesktop.org Cc: Chris Wilson Subject: Re: [Intel-gfx] [PATCH] drm/i915/mtl

Re: [Intel-gfx] [PATCH v2] drm/i915: Fix potential spectre vulnerability

gem: Use the proto-context to handle create parameters (v5)") Cc: # v5.15+ Signed-off-by: Kunwu Chan Suggested-by: Tvrtko Ursulin Reviewed-by: Tvrtko Ursulin Where did you receive this tag? There is nothing under link below. Link: https://lore.kernel.org/all/20231102101642.52988-1-che

Re: [Intel-gfx] [PATCH] drm/i915/mtl: Increase guard pages when vt-d is enabled

On 02/11/2023 16:58, Andrzej Hajda wrote: On 02.11.2023 17:06, Radhakrishna Sripada wrote: Experiments were conducted with different multipliers to VTD_GUARD macro with multiplier of 185 we were observing occasional pipe faults when running kms_cursor_legacy --run-subtest single-bo There coul

Re: [Intel-gfx] [PATCH 0/5] drm/i915/pmu: hide struct i915_pmu

On 02/11/2023 15:42, Jani Nikula wrote: The implementation details of pmu should be implementation details hidden inside i915_pmu.c. Make it so. Don't tell me i915->pmu bothers xe somehow? I am not a fan of the series on a glance. Replacing an increment with a function call for instance. R

Re: [Intel-gfx] [PATCH] drm/i915: Fix potential spectre vulnerability

On 02/11/2023 10:16, chentao wrote: Fix smatch warning: drivers/gpu/drm/i915/gem/i915_gem_context.c:847 set_proto_ctx_sseu() warn: potential spectre issue 'pc->user_engines' [r] (local cap) Signed-off-by: chentao I don't know if this is actually exploitable given the time deltas between the

Re: [Intel-gfx] [PATCH 1/7] drm: Do not round to megabytes for greater than 1MiB sizes in fdinfo stats

On 26/10/2023 15:43, Tvrtko Ursulin wrote: On 28/09/2023 13:47, Tvrtko Ursulin wrote: On 27/09/2023 14:48, Steven Price wrote: On 27/09/2023 14:38, Tvrtko Ursulin wrote: From: Tvrtko Ursulin It is better not to lose precision and not revert to 1 MiB size granularity for every size

Re: [Intel-gfx] [PATCH] drm/i915: Remove unused for_each_uabi_class_engine

On 02/11/2023 09:24, Jani Nikula wrote: On Wed, 01 Nov 2023, Tvrtko Ursulin wrote: On 01/11/2023 10:06, Jani Nikula wrote: On Wed, 01 Nov 2023, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Unused macro after 99919be74aa3 ("drm/i915/gem: Zap the i915_gem_object_blt code") re

[Intel-gfx] [PATCH 2/2] drm/i915: Move for_each_engine* out of i915_drv.h

From: Tvrtko Ursulin Iterators operate on struct intel_gt so lets move it to intel_gt.h in order to make i915_drv.h less of a dumping ground for stuff. Signed-off-by: Tvrtko Ursulin Suggested-by: Jani Nikula --- drivers/gpu/drm/i915/gt/intel_engine_pm.h | 1 + drivers/gpu/drm/i915

[Intel-gfx] [PATCH 1/2] drm/i915: Remove unused for_each_uabi_class_engine

From: Tvrtko Ursulin Unused macro after 99919be74aa3 ("drm/i915/gem: Zap the i915_gem_object_blt code") removed some code. Signed-off-by: Tvrtko Ursulin Reviewed-by: Jani Nikula --- drivers/gpu/drm/i915/i915_drv.h | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/gp

Re: [Intel-gfx] [PATCH] drm/i915: Remove unused for_each_uabi_class_engine

On 01/11/2023 10:06, Jani Nikula wrote: On Wed, 01 Nov 2023, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Unused macro after 99919be74aa3 ("drm/i915/gem: Zap the i915_gem_object_blt code") removed some code. Signed-off-by: Tvrtko Ursulin \o/ Reviewed-by: Jani Nikula Could

[Intel-gfx] [PATCH] drm/i915: Remove unused for_each_uabi_class_engine

From: Tvrtko Ursulin Unused macro after 99919be74aa3 ("drm/i915/gem: Zap the i915_gem_object_blt code") removed some code. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_drv.h | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/d

[Intel-gfx] [PATCH 2/2] drm/i915: Remove xehpsdv support

From: Tvrtko Ursulin XeHP SDV was a pre-production hardware used to bring up PVC and was not generally available and has since been decided will be supported in the new xe driver and not i915. v2: * Correct historical fact SDV was for PVC, not ATS. (John) Signed-off-by: Tvrtko Ursulin Cc

[Intel-gfx] [PATCH 1/2] drm/i915: Remove incomplete PVC plumbing

From: Tvrtko Ursulin PVC support will not be coming to i915 so get rid of its partial enablement and reduce the driver maintenance burden. Signed-off-by: Tvrtko Ursulin Reviewed-by: Andi Shyti Reviewed-by: Andrzej Hajda --- .../gpu/drm/i915/gem/i915_gem_object_types.h | 2 +- drivers/gpu

Re: [Intel-gfx] [PATCH v2] i915/perf: Fix NULL deref bugs with drm_dbg() calls

On 27/10/2023 18:38, Tvrtko Ursulin wrote: On 27/10/2023 18:28, Harshit Mogalapalli wrote: When i915 perf interface is not available dereferencing it will lead to NULL dereferences. As returning -ENOTSUPP is pretty clear return when perf interface is not available. Fixes: 2fec539112e8

Re: [Intel-gfx] [PATCH v2] i915/perf: Fix NULL deref bugs with drm_dbg() calls

river specific drm_dbg call") Suggested-by: Tvrtko Ursulin Signed-off-by: Harshit Mogalapalli --- v1 --> v2: Remove the debug calls as they don't add much value and -ENOTSUPP is a good enough return value. --- drivers/gpu/drm/i915/i915_perf.c | 15 +++ 1 file changed, 3

Re: [Intel-gfx] [PATCH] i915/perf: Fix NULL deref bugs with drm_dbg() calls

On 27/10/2023 15:11, Andrzej Hajda wrote: On 27.10.2023 16:07, Harshit Mogalapalli wrote: When i915 perf interface is not available dereferencing it will lead to NULL dereferences. Fix this by using DRM_DEBUG() which the scenario before the commit in the Fixes tag. Fixes: 2fec539112e8 ("i915

Re: [Intel-gfx] [PATCH 1/7] drm: Do not round to megabytes for greater than 1MiB sizes in fdinfo stats

On 28/09/2023 13:47, Tvrtko Ursulin wrote: On 27/09/2023 14:48, Steven Price wrote: On 27/09/2023 14:38, Tvrtko Ursulin wrote: From: Tvrtko Ursulin It is better not to lose precision and not revert to 1 MiB size granularity for every size greater than 1 MiB. Sizes in KiB should not be so

Re: [Intel-gfx] [PATCH] drm/i915/gt: Remove assignment from if condition

On 26/10/2023 14:58, Gilbert Adikankwu wrote: Initialize variable "entry" during declaration. Remove assignment from if condition. Fix checkpatch.pl error: ERROR: do not use assignment in if condition Signed-off-by: Gilbert Adikankwu --- drivers/gpu/drm/i915/gt/intel_execlists_submission.c

Re: [Intel-gfx] [PATCH 2/3] drm/i915/pmu: add event_to_pmu() helper

On 26/10/2023 11:36, Andi Shyti wrote: Hi, On 26/10/2023 11:22, Jani Nikula wrote: On Wed, 25 Oct 2023, Andi Shyti wrote: On Wed, Oct 25, 2023 at 11:20:25AM +0100, Tvrtko Ursulin wrote: On 24/10/2023 13:42, Jani Nikula wrote: On Tue, 24 Oct 2023, Andi Shyti wrote: Hi Jani, On Mon

Re: [Intel-gfx] [PATCH 2/3] drm/i915/pmu: add event_to_pmu() helper

On 26/10/2023 11:22, Jani Nikula wrote: On Wed, 25 Oct 2023, Andi Shyti wrote: On Wed, Oct 25, 2023 at 11:20:25AM +0100, Tvrtko Ursulin wrote: On 24/10/2023 13:42, Jani Nikula wrote: On Tue, 24 Oct 2023, Andi Shyti wrote: Hi Jani, On Mon, Oct 23, 2023 at 06:02:55PM +0300, Jani Nikula

Re: [Intel-gfx] [PATCH] file, i915: fix file reference for mmap_singleton()

On 25/10/2023 16:23, Jann Horn wrote: On Wed, Oct 25, 2023 at 2:01 PM Christian Brauner wrote: Today we got a report at [1] for rcu stalls on the i915 testsuite in [2] due to the conversion of files to SLAB_TYPSSAFE_BY_RCU. Afaict, get_file_rcu() goes into an infinite loop trying to carefully

Re: [Intel-gfx] [PATCH v4 3/3] drm/i915/gt: Timeout when waiting for idle in suspending

On 04/10/2023 18:59, Teres Alexis, Alan Previn wrote: On Thu, 2023-09-28 at 13:46 +0100, Tvrtko Ursulin wrote: On 27/09/2023 17:36, Teres Alexis, Alan Previn wrote: Thanks for taking the time to review this Tvrtko, replies inline below. alan:snip Main concern is that we need to be sure

Re: [Intel-gfx] [PATCH v3] drm/i915: handle uncore spinlock when not available

On 25/10/2023 11:32, Coelho, Luciano wrote: On Wed, 2023-10-25 at 11:25 +0100, Tvrtko Ursulin wrote: On 25/10/2023 11:18, Tvrtko Ursulin wrote: On 23/10/2023 11:33, Luca Coelho wrote: The uncore code may not always be available (e.g. when we build the display code with Xe), so we can&#

Re: [Intel-gfx] [PATCH v3] drm/i915: handle uncore spinlock when not available

On 25/10/2023 11:18, Tvrtko Ursulin wrote: On 23/10/2023 11:33, Luca Coelho wrote: The uncore code may not always be available (e.g. when we build the display code with Xe), so we can't always rely on having the uncore's spinlock. To handle this, split the spin_lock/unlock_irqsa

Re: [Intel-gfx] [PATCH 2/3] drm/i915/pmu: add event_to_pmu() helper

On 24/10/2023 13:42, Jani Nikula wrote: On Tue, 24 Oct 2023, Andi Shyti wrote: Hi Jani, On Mon, Oct 23, 2023 at 06:02:55PM +0300, Jani Nikula wrote: It's tedious to duplicate the container_of() everywhere. Add a helper. Also do the logical steps of first getting from struct perf_event to s

Re: [Intel-gfx] [PATCH v3] drm/i915: handle uncore spinlock when not available

On 23/10/2023 11:33, Luca Coelho wrote: The uncore code may not always be available (e.g. when we build the display code with Xe), so we can't always rely on having the uncore's spinlock. To handle this, split the spin_lock/unlock_irqsave/restore() into spin_lock/unlock() followed by a call to

[Intel-gfx] [RFC 8/8] cgroup/drm: Expose GPU utilisation

From: Tvrtko Ursulin To support container use cases where external orchestrators want to make deployment and migration decisions based on GPU load and capacity, we can expose the GPU load as seen by the controller in a new drm.active_us field. This field contains a monotonic cumulative time

[Intel-gfx] [RFC 7/8] drm/i915: Implement cgroup controller over budget throttling

From: Tvrtko Ursulin When notified by the drm core we are over our allotted time budget, i915 instance will check if any of the GPU engines it is reponsible for is fully saturated. If it is, and the client in question is using that engine, it will throttle it. For now throttling is done

[Intel-gfx] [RFC 6/8] cgroup/drm: Introduce weight based drm cgroup control

From: Tvrtko Ursulin Similar to CPU scheduling, implement a concept of weight in the drm cgroup controller. Uses the same range and default as the CPU controller - CGROUP_WEIGHT_MIN, CGROUP_WEIGHT_DFL and CGROUP_WEIGHT_MAX. Later each cgroup is assigned a time budget proportionaly based on the

[Intel-gfx] [RFC 5/8] drm/cgroup: Only track clients which are providing drm_cgroup_ops

From: Tvrtko Ursulin To reduce the number of tracking going on, especially with drivers which will not support any sort of control from the drm cgroup controller side, lets express the funcionality as opt-in and use the presence of drm_cgroup_ops as activation criteria. Signed-off-by: Tvrtko

[Intel-gfx] [RFC 3/8] drm/cgroup: Add ability to query drm cgroup GPU time

From: Tvrtko Ursulin Add a driver callback and core helper which allow querying the time spent on GPUs for processes belonging to a group. Signed-off-by: Tvrtko Ursulin --- include/drm/drm_drv.h | 28 kernel/cgroup/drm.c | 20 2 files

[Intel-gfx] [RFC 4/8] drm/cgroup: Add over budget signalling callback

From: Tvrtko Ursulin Add a new callback via which the drm cgroup controller is notifying the drm core that a certain process is above its allotted GPU time. Signed-off-by: Tvrtko Ursulin --- include/drm/drm_drv.h | 8 kernel/cgroup/drm.c | 16 2 files changed, 24

[Intel-gfx] [RFC 2/8] drm/cgroup: Track DRM clients per cgroup

From: Tvrtko Ursulin To enable propagation of settings from the cgroup DRM controller to DRM and vice-versa, we need to start tracking to which cgroups DRM clients belong. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/drm_file.c | 6 include/drm/drm_file.h | 6 include

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