From: Tvrtko Ursulin
To enable propagation of settings from the cgroup drm controller to drm we
need to start tracking which processes own which drm clients.
Implement that by tracking the struct pid pointer of the owning process in
a new XArray, pointing to a structure containing a list
From: Tvrtko Ursulin
Replace the deprecated macro with the per-device one.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/drm_file.c | 21 +++--
drivers/gpu/drm/drm_ioc32.c | 13 +++--
drivers/gpu/drm/drm_ioctl.c | 25 +
3 files changed, 31
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
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
---
drivers/gpu/drm/drm_cgroup.c | 21 +
include/drm/drm_clients.h| 1 +
include
From: Tvrtko Ursulin
Thread group id (aka pid from userspace point of view) is a more
interesting thing to show as an owner of a DRM fd, so track and show that
instead of the thread id.
In the next patch we will make the owner updated post file descriptor
handover, which will also be tgid based
From: Tvrtko Ursulin
With the typical model where the display server opends the file descriptor
and then hands it over to the client we were showing stale data in
debugfs.
Fix it by updating the drm_file->pid on ioctl access from a different
process.
The field is also made RCU protec
From: Tvrtko Ursulin
*** vvv Read this first please vvv ***
I am re-sending this to dri-devel directly, having realized neither v1 or v2
have reached dri-devel due possible SMTP server issues. Other recipients and
lists however did get both v1 in October and v2 two days ago.
Hence this is a re
On 10/11/2022 05:49, Niranjana Vishwanathapura wrote:
On Wed, Nov 09, 2022 at 04:16:25PM -0800, Zanoni, Paulo R wrote:
On Mon, 2022-11-07 at 00:51 -0800, Niranjana Vishwanathapura wrote:
DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM
buffer objects (BOs) or sections of a
From: Tvrtko Ursulin
Since we are now storing the GT backpointer in the wa list we can drop the
explicit struct intel_gt * argument to wa_list_apply.
Signed-off-by: Tvrtko Ursulin
Cc: Andrzej Hajda
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 10 +-
1 file changed, 5 insertions
On 10/11/2022 11:07, Andrzej Hajda wrote:
On 09.11.2022 11:46, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Convert some usages of legacy DRM logging macros into versions which tell
us on which device have the events occurred.
v2:
* Don't have struct drm_device as local. (Jani, Ville)
v3
Hi,
On 09/11/2022 18:03, Thomas Hellström wrote:
Hi, Andi,
This has been on the list before (three times I think) and at that
point it (the guard pages) was NAK'd by Daniel as yet another
complication, and a VT-d
scanout workaround was implemented and pushed using a different
approach,
On 09/11/2022 19:57, Michal Wajdeczko wrote:
[snip]
Is it really a problem to merge this patch now to get the process
started? And other sub-components get updated as and when people get the
time to do them? You could maybe even help rather than posting
completely conflicting patch sets that
On 09/11/2022 17:46, John Harrison wrote:
On 11/9/2022 03:05, Tvrtko Ursulin wrote:
On 08/11/2022 20:15, John Harrison wrote:
On 11/8/2022 01:01, Tvrtko Ursulin wrote:
On 07/11/2022 19:14, John Harrison wrote:
On 11/7/2022 08:17, Tvrtko Ursulin wrote:
On 07/11/2022 09:33, Tvrtko Ursulin
Hi Dave, Daniel,
Some more fixes for the release candidate window.
Most important are the SG table handling fix for map_dma_buf import, the
userptr probe fixup after VMA iterator conversion and then a display/mouse
stuttering fix for PSR2. Last one only relates to discrete platforms, so
still
On 08/11/2022 19:37, John Harrison wrote:
On 11/8/2022 01:08, Tvrtko Ursulin wrote:
On 07/11/2022 19:45, John Harrison wrote:
On 11/7/2022 06:09, Tvrtko Ursulin wrote:
On 04/11/2022 17:45, John Harrison wrote:
On 11/4/2022 03:01, Tvrtko Ursulin wrote:
On 03/11/2022 19:16, John Harrison
On 08/11/2022 20:15, John Harrison wrote:
On 11/8/2022 01:01, Tvrtko Ursulin wrote:
On 07/11/2022 19:14, John Harrison wrote:
On 11/7/2022 08:17, Tvrtko Ursulin wrote:
On 07/11/2022 09:33, Tvrtko Ursulin wrote:
On 05/11/2022 01:03, Ceraolo Spurio, Daniele wrote:
On 11/4/2022 10:25 AM
From: Tvrtko Ursulin
Convert some usages of legacy DRM logging macros into versions which tell
us on which device have the events occurred.
v2:
* Don't have struct drm_device as local. (Jani, Ville)
v3:
* Store gt, not i915, in workaround list. (John)
Signed-off-by: Tvrtko Ursulin
Reviewed
On 06/11/2022 21:02, Oded Gabbay wrote:
The accelerator devices are exposed to user-space using a dedicated
major. In addition, they are represented in /dev with new, dedicated
device char names: /dev/accel/accel*. This is done to make sure any
user-space software that tries to open a graphic
From: Tvrtko Ursulin
Convert some usages of legacy DRM logging macros into versions which tell
us on which device have the events occurred.
v2:
* Don't have struct drm_device as local. (Jani, Ville)
Signed-off-by: Tvrtko Ursulin
Cc: Jani Nikula
Cc: John Harrison
Cc: Ville Syrjälä
On 08/11/2022 09:24, Hans de Goede wrote:
Hi Alex, et al.,
I just pushed 2 simple DMI quirk patches
(for drivers/gpu/drm/drm_panel_orientation_quirks.c)
to drm-misc-fixes.
At the end of the dim push-branch I noticed that
rebuilding drm-tip failed due to a merge error
when merging in drm-next
On 08/11/2022 12:01, Jani Nikula wrote:
On Tue, 08 Nov 2022, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Convert some usages of legacy DRM logging macros into versions which tell
us on which device have the events occurred.
Signed-off-by: Tvrtko Ursulin
Cc: Jani Nikula
Cc: John Harrison
From: Tvrtko Ursulin
Convert some usages of legacy DRM logging macros into versions which tell
us on which device have the events occurred.
Signed-off-by: Tvrtko Ursulin
Cc: Jani Nikula
Cc: John Harrison
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
.../gpu/drm/i915/gem
onsidering what frequency the engine is operating as a
percentage of it's maximum frequency.
-===
Driver specific implementations
===
Oops - yep.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
On 07/11/2022 19:45, John Harrison wrote:
On 11/7/2022 06:09, Tvrtko Ursulin wrote:
On 04/11/2022 17:45, John Harrison wrote:
On 11/4/2022 03:01, Tvrtko Ursulin wrote:
On 03/11/2022 19:16, John Harrison wrote:
On 11/3/2022 02:38, Tvrtko Ursulin wrote:
On 03/11/2022 09:18, Tvrtko Ursulin
On 07/11/2022 19:14, John Harrison wrote:
On 11/7/2022 08:17, Tvrtko Ursulin wrote:
On 07/11/2022 09:33, Tvrtko Ursulin wrote:
On 05/11/2022 01:03, Ceraolo Spurio, Daniele wrote:
On 11/4/2022 10:25 AM, john.c.harri...@intel.com wrote:
From: John Harrison
When trying to analyse bug
On 07/11/2022 09:33, Tvrtko Ursulin wrote:
On 05/11/2022 01:03, Ceraolo Spurio, Daniele wrote:
On 11/4/2022 10:25 AM, john.c.harri...@intel.com wrote:
From: John Harrison
When trying to analyse bug reports from CI, customers, etc. it can be
difficult to work out exactly what
On 04/11/2022 17:45, John Harrison wrote:
On 11/4/2022 03:01, Tvrtko Ursulin wrote:
On 03/11/2022 19:16, John Harrison wrote:
On 11/3/2022 02:38, Tvrtko Ursulin wrote:
On 03/11/2022 09:18, Tvrtko Ursulin wrote:
On 03/11/2022 01:33, John Harrison wrote:
On 11/2/2022 07:20, Tvrtko Ursulin
On 05/11/2022 01:03, Ceraolo Spurio, Daniele wrote:
On 11/4/2022 10:25 AM, john.c.harri...@intel.com wrote:
From: John Harrison
When trying to analyse bug reports from CI, customers, etc. it can be
difficult to work out exactly what is happening on which GT in a
multi-GT system. So add GT
On 03/11/2022 19:16, John Harrison wrote:
On 11/3/2022 02:38, Tvrtko Ursulin wrote:
On 03/11/2022 09:18, Tvrtko Ursulin wrote:
On 03/11/2022 01:33, John Harrison wrote:
On 11/2/2022 07:20, Tvrtko Ursulin wrote:
On 02/11/2022 12:12, Jani Nikula wrote:
On Tue, 01 Nov 2022, john.c.harri
iel Vetter
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: dri-devel@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Signed-off-by: Steven Rostedt (Google)
---
drivers/gpu/drm/gud/gud_pipe.c | 2 +-
drivers/gpu/drm/i915/i915_sw_fence.c | 2 +-
On 02/11/2022 19:21, john.c.harri...@intel.com wrote:
From: John Harrison
The engine busyness stats has a worker function to do things like
64bit extend the 32bit hardware counters. The GuC's reset prepare
function flushes out this worker function to ensure no corruption
happens during the
On 03/11/2022 09:18, Tvrtko Ursulin wrote:
On 03/11/2022 01:33, John Harrison wrote:
On 11/2/2022 07:20, Tvrtko Ursulin wrote:
On 02/11/2022 12:12, Jani Nikula wrote:
On Tue, 01 Nov 2022, john.c.harri...@intel.com wrote:
From: John Harrison
At the end of each test, IGT does a drop
On 03/11/2022 01:33, John Harrison wrote:
On 11/2/2022 07:20, Tvrtko Ursulin wrote:
On 02/11/2022 12:12, Jani Nikula wrote:
On Tue, 01 Nov 2022, john.c.harri...@intel.com wrote:
From: John Harrison
At the end of each test, IGT does a drop caches call via sysfs with
sysfs?
Sorry
Hi Dave, Daniel,
A few fixes for 6.1.
On the display side fixed a race condition in accessing DKL PHY registers
(TGL+), fixed LVDS EDID fixed mode setup and fixed SDVO invalid mode
filtering. On the GEM side fix running under Xen and use DMA API directly
instead of special casing for SWIOTLB
On 02/11/2022 12:12, Jani Nikula wrote:
On Tue, 01 Nov 2022, john.c.harri...@intel.com wrote:
From: John Harrison
At the end of each test, IGT does a drop caches call via sysfs with
sysfs?
special flags set. One of the possible paths waits for idle with an
infinite timeout. That causes
On 01/11/2022 16:56, John Harrison wrote:
On 11/1/2022 02:58, Tvrtko Ursulin wrote:
On 31/10/2022 18:30, John Harrison wrote:
On 10/31/2022 05:51, Tvrtko Ursulin wrote:
On 31/10/2022 10:09, Tvrtko Ursulin wrote:
On 28/10/2022 20:46, john.c.harri...@intel.com wrote:
From: John Harrison
On 31/10/2022 18:30, John Harrison wrote:
On 10/31/2022 05:51, Tvrtko Ursulin wrote:
On 31/10/2022 10:09, Tvrtko Ursulin wrote:
On 28/10/2022 20:46, john.c.harri...@intel.com wrote:
From: John Harrison
The engine busyness stats has a worker function to do things like
64bit extend
On 28/10/2022 18:00, Ceraolo Spurio, Daniele wrote:
On 10/28/2022 1:38 AM, Tvrtko Ursulin wrote:
On 27/10/2022 23:15, Daniele Ceraolo Spurio wrote:
The GSC CS re-uses the same interrupt bits that the GSC used in older
platforms. This means that we can now have an engine interrupt coming
out
On 31/10/2022 10:09, Tvrtko Ursulin wrote:
On 28/10/2022 20:46, john.c.harri...@intel.com wrote:
From: John Harrison
The engine busyness stats has a worker function to do things like
64bit extend the 32bit hardware counters. The GuC's reset prepare
function flushes out this worker function
On 28/10/2022 20:46, john.c.harri...@intel.com wrote:
From: John Harrison
The engine busyness stats has a worker function to do things like
64bit extend the 32bit hardware counters. The GuC's reset prepare
function flushes out this worker function to ensure no corruption
happens during the
On 27/10/2022 23:15, Daniele Ceraolo Spurio wrote:
The GSC CS re-uses the same interrupt bits that the GSC used in older
platforms. This means that we can now have an engine interrupt coming
out of OTHER_CLASS, so we need to handle that appropriately.
Signed-off-by: Daniele Ceraolo Spurio
)
Reported-by: Marek Marczykowski-Górecki
Signed-off-by: Robert Beckett
Signed-off-by: Christoph Hellwig
[hch: added the Xen hack, rewrote the changelog]
Reviewed-by: Tvrtko Ursulin
I'll merge this in a minute - thanks again for the cleanup!
Regards,
Tvrtko
---
drivers/gpu/dr
Hi Dave, Daniel,
Three fixes for the next release candidate: one display training fix, one
new workaround and disabling of autosuspend for DG2 until things can get
properly fixed.
Regards,
Tvrtko
drm-intel-fixes-2022-10-27-1:
- Extend Wa_1607297627 to Alderlake-P (José Roberto de Souza)
- Keep
From: Mel Gorman
On Mon, Oct 24, 2022 at 02:04:50PM +0100, Tvrtko Ursulin wrote:
>
> Hi Mel, mm experts,
>
> With 6.1-rc2 we started hitting the WARN_ON added in 71e2d666ef85
> ("mm/huge_memory: do not clobber swp_entry_t during THP split") in i915
> automated
On 27/10/2021 01:48, Umesh Nerlige Ramappa wrote:
[snip]
+static void guc_timestamp_ping(struct work_struct *wrk)
+{
+ struct intel_guc *guc = container_of(wrk, typeof(*guc),
+timestamp.work.work);
+ struct intel_uc *uc =
On 20/10/2022 12:03, Christoph Hellwig wrote:
From: Robert Beckett
swiotlb_max_segment used to return either the maximum size that swiotlb
could bounce, or for Xen PV PAGE_SIZE even if swiotlb could bounce buffer
larger mappings. This made i915 on Xen PV work as it bypasses the
coherency
On 20/10/2022 15:18, Ville Syrjälä wrote:
On Thu, Oct 20, 2022 at 02:08:41PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Since a7c01fa93aeb ("signal: break out of wait loops on kthread_stop()")
kthread_stop() started asserting a pending signal which wreaks havoc with
a
From: Tvrtko Ursulin
Since a7c01fa93aeb ("signal: break out of wait loops on kthread_stop()")
kthread_stop() started asserting a pending signal which wreaks havoc with
a few of our selftests. Mainly because they are not fully expecting to
handle signals, but also cutting the int
On 19/10/2022 22:12, Belgaumkar, Vinay wrote:
On 10/19/2022 12:40 AM, Tvrtko Ursulin wrote:
On 18/10/2022 23:15, Vinay Belgaumkar wrote:
Waitboost (when SLPC is enabled) results in a H2G message. This can
result
in thousands of messages during a stress test and fill up an already
full
CTB
On 19/10/2022 13:10, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Warning - not much tested, mainly bypassing trybot for quick turnaround.
Please ignore - this is quite broken and problem more complicated.
Regards,
Tvrtko
Tvrtko Ursulin (2):
drm/i915/selftests: Fix waiting for threads
From: Tvrtko Ursulin
Since a7c01fa93aeb ("signal: break out of wait loops on kthread_stop()")
kthread_stop will mark a pending signal which breaks __igt_timeout when
used from selftests threads. Result of this is overly short test execution
time which renders some tests useless.
From: Tvrtko Ursulin
Tests which want to make sure all threads have started have to do that
explicitly since one yield() can not guarantee it. Issue is that many
tests then proceed to call kthread_stop() which can therefore return even
before the thread has been started and will instead just
From: Tvrtko Ursulin
Warning - not much tested, mainly bypassing trybot for quick turnaround.
Tvrtko Ursulin (2):
drm/i915/selftests: Fix waiting for threads to start
drm/i915/selftests: Fix selftests for 6.1 kthread_stop semantics
.../drm/i915/gem/selftests/i915_gem_context.c | 9
On 18/10/2022 23:15, Vinay Belgaumkar wrote:
Waitboost (when SLPC is enabled) results in a H2G message. This can result
in thousands of messages during a stress test and fill up an already full
CTB. There is no need to request for RP0 if GuC is already requesting the
same.
Signed-off-by:
-fixes-2022-10-13:
- Fix revocation of non-persistent contexts (Tvrtko Ursulin)
- Handle migration for dpt (Matthew Auld)
- Fix display problems after resume (Thomas Hellström)
- Allow control over the flags when migrating (Matthew Auld)
- Consider DG2_RC_CCS_CC when migrating buffers (Matthew Auld
On 11/10/2022 14:59, Andi Shyti wrote:
Commit 3e7abf814193 ("drm/i915: Extract GT render power state management")
removes the "trace_intel_gpu_freq_change()" trace points but
their definition was left without users. Remove it.
Suggested-by: Tvrtko Ursulin
Signed-off-by: A
AICS result is used, just the copy/local variable is not.
For the patch:
Reviewed-by: Tvrtko Ursulin
Thanks for the cleanup, will merge.
Regards,
Tvrtko
CJ
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/i915_perf.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
+= ret;
}
- ret = 0;
ret = i915_gem_object_lock_interruptible(obj, NULL);
if (ret)
Reviewed-by: Tvrtko Ursulin
Thanks for the cleanup, will merge.
Regards,
Tvrtko
m_get(engine);
err = mutex_lock_interruptible(>timeline->mutex);
LGTM - hope it is agreeable to you too.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
Hi Dave, Daniel,
Some fixes for the merge window - one EHL MOCS table fix and the rest is
in the display area around modifier handling and PSR on Gen12+, one fixup
for g4x+ and one fixing recent fastset refactoring.
Regards,
Tvrtko
drm-intel-next-fixes-2022-10-06-1:
- Round to closest in g4x+
On 05/10/2022 19:48, John Harrison wrote:
On 10/3/2022 05:00, Tvrtko Ursulin wrote:
On 03/10/2022 08:53, Tvrtko Ursulin wrote:
On 30/09/2022 18:44, John Harrison wrote:
On 9/30/2022 02:22, Tvrtko Ursulin wrote:
On 29/09/2022 17:21, John Harrison wrote:
On 9/29/2022 00:42, Tvrtko Ursulin
On 04/10/2022 16:13, Ceraolo Spurio, Daniele wrote:
On 10/4/2022 4:14 AM, Tvrtko Ursulin wrote:
On 03/10/2022 13:16, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Patch which added graceful exit for non-persistent contexts missed the
fact it is not enough to set the exiting flag on a context
On 04/10/2022 14:00, Tvrtko Ursulin wrote:
On 04/10/2022 10:29, Tvrtko Ursulin wrote:
On 03/10/2022 20:24, Ashutosh Dixit wrote:
PMU and sysfs use different wakeref's to "interpret" zero freq. Sysfs
uses
runtime PM wakeref (see intel_rps_read_punit_req and
intel_rps_read_actual
On 04/10/2022 10:29, Tvrtko Ursulin wrote:
On 03/10/2022 20:24, Ashutosh Dixit wrote:
PMU and sysfs use different wakeref's to "interpret" zero freq. Sysfs
uses
runtime PM wakeref (see intel_rps_read_punit_req and
intel_rps_read_actual_frequency). PMU uses the GT parked/unpark
On 03/10/2022 13:16, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Patch which added graceful exit for non-persistent contexts missed the
fact it is not enough to set the exiting flag on a context and let the
backend handle it from there.
GuC backend cannot handle it because it runs
On 03/10/2022 20:32, Matt Roper wrote:
On Mon, Oct 03, 2022 at 09:56:18AM +0100, Tvrtko Ursulin wrote:
Hi Matt,
On 01/10/2022 01:45, Matt Roper wrote:
MTL's media GT only has a single type of steering ("OAADDRM") which
selects between media slice 0 and media slice 1. We'll al
5
Reported-by: Ashwin Kumar Kulkarni
Cc: Tvrtko Ursulin
Signed-off-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/i915_pmu.c | 27 ++-
1 file changed, 2 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 95
From: Tvrtko Ursulin
Patch which added graceful exit for non-persistent contexts missed the
fact it is not enough to set the exiting flag on a context and let the
backend handle it from there.
GuC backend cannot handle it because it runs independently in the
firmware and driver might not see
On 03/10/2022 08:53, Tvrtko Ursulin wrote:
On 30/09/2022 18:44, John Harrison wrote:
On 9/30/2022 02:22, Tvrtko Ursulin wrote:
On 29/09/2022 17:21, John Harrison wrote:
On 9/29/2022 00:42, Tvrtko Ursulin wrote:
On 29/09/2022 03:18, john.c.harri...@intel.com wrote:
From: John Harrison
Hi Matt,
On 01/10/2022 01:45, Matt Roper wrote:
MTL's media GT only has a single type of steering ("OAADDRM") which
selects between media slice 0 and media slice 1. We'll always steer to
media slice 0 unless it is fused off (which is the case when VD0, VE0,
and SFC0 are all reported as
On 30/09/2022 15:52, Andrzej Hajda wrote:
On 30.09.2022 11:47, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Patch which added graceful exit for non-persistent contexts missed the
fact it is not enough to set the exiting flag on a context and let the
backend handle it from there.
GuC backend
On 30/09/2022 18:44, John Harrison wrote:
On 9/30/2022 02:22, Tvrtko Ursulin wrote:
On 29/09/2022 17:21, John Harrison wrote:
On 9/29/2022 00:42, Tvrtko Ursulin wrote:
On 29/09/2022 03:18, john.c.harri...@intel.com wrote:
From: John Harrison
Compute workloads are inherently not pre
From: Tvrtko Ursulin
Patch which added graceful exit for non-persistent contexts missed the
fact it is not enough to set the exiting flag on a context and let the
backend handle it from there.
GuC backend cannot handle it because it runs independently in the
firmware and driver might not see
On 29/09/2022 17:21, John Harrison wrote:
On 9/29/2022 00:42, Tvrtko Ursulin wrote:
On 29/09/2022 03:18, john.c.harri...@intel.com wrote:
From: John Harrison
Compute workloads are inherently not pre-emptible for long periods on
current hardware. As a workaround for this, the pre-emption
Hi Dave, Daniel,
A few fixes for the upcoming merge window. Not many but most are pretty
important.
Another rather important one is missing due being too conflicty, but will
arrive via drm-intel-fixes (7738be973fc4 ("drm/i915/gt: Perf_limit_reasons
are only available for Gen11+")).
Regards,
, remove the execlist centric comment from the
existing pre-emption timeout CONFIG option given that it applies to
more than just execlists.
Signed-off-by: John Harrison
Reviewed-by: Daniele Ceraolo Spurio (v1)
Acked-by: Michal Mrozek
Acked-by: Tvrtko Ursulin
Regards,
Tvrtko
---
drivers/gpu
On 29/09/2022 03:18, john.c.harri...@intel.com wrote:
From: John Harrison
Compute workloads are inherently not pre-emptible for long periods on
current hardware. As a workaround for this, the pre-emption timeout
for compute capable engines was disabled. This is undesirable with GuC
functions (Tvrtko)
Signed-off-by: John Harrison
Reviewed-by: Daniele Ceraolo Spurio (v1)
Acked-by: Tvrtko Ursulin
Regards,
Tvrtko
---
drivers/gpu/drm/i915/gt/intel_engine.h| 6 ++
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 69 +++
drivers/gpu/drm/i915/gt
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Add i915_vma_instance_persistent() to create persistent vmas.
Persistent vmas will use i915_gtt_view to support partial binding.
vma_lookup is tied to segment of the object instead of section
of VA space. Hence, it do not support aliasing.
On 26/09/2022 18:09, Niranjana Vishwanathapura wrote:
On Mon, Sep 26, 2022 at 05:26:12PM +0100, Tvrtko Ursulin wrote:
On 24/09/2022 05:30, Niranjana Vishwanathapura wrote:
On Fri, Sep 23, 2022 at 09:40:20AM +0100, Tvrtko Ursulin wrote:
On 21/09/2022 08:09, Niranjana Vishwanathapura wrote
On 23/09/2022 17:16, Ville Syrjälä wrote:
On Fri, Sep 23, 2022 at 03:29:34PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Kernel is trying to eliminate callers of flush_scheduled_work so lets
try to accommodate.
We currently call it from intel_modeset_driver_remove_noirq on the driver
On 24/09/2022 05:30, Niranjana Vishwanathapura wrote:
On Fri, Sep 23, 2022 at 09:40:20AM +0100, Tvrtko Ursulin wrote:
On 21/09/2022 08:09, Niranjana Vishwanathapura wrote:
vma_lookup is tied to segment of the object instead of section
Can be, but not only that. It would be more accurate
On 23/09/2022 16:41, Ceraolo Spurio, Daniele wrote:
On 9/23/2022 3:53 AM, Tvrtko Ursulin wrote:
On 22/09/2022 23:11, Daniele Ceraolo Spurio wrote:
On MTL the primary GT doesn't have any media capabilities, so no video
engines and no HuC. We must therefore skip the HuC fetch and load
From: Tvrtko Ursulin
Kernel is trying to eliminate callers of flush_scheduled_work so lets
try to accommodate.
We currently call it from intel_modeset_driver_remove_noirq on the driver
remove path but the comment next to it does not tell me what exact work it
wants to flush.
I can spot three
On 23/09/2022 11:32, Das, Nirmoy wrote:
Reviewed-by: Nirmoy Das
Thanks!
Pushed now. Should land with 6.2.
Regards,
Tvrtko
On 6/30/2022 2:57 PM, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
There are ongoing efforts to remove usages of flush_scheduled_work() from
drivers in order
On 22/09/2022 23:11, Daniele Ceraolo Spurio wrote:
On MTL the primary GT doesn't have any media capabilities, so no video
engines and no HuC. We must therefore skip the HuC fetch and load on
that specific case. Given that other multi-GT platforms might have HuC
on the primary GT, we can't just
On 21/09/2022 08:09, Niranjana Vishwanathapura wrote:
vma_lookup is tied to segment of the object instead of section
Can be, but not only that. It would be more accurate to say it is based
of gtt views.
of VA space. Hence, it do not support aliasing (ie., multiple
bindings to the same
On 22/09/2022 17:18, Matthew Auld wrote:
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
Hi Nathan,
On 22/09/2022 20:51, Nathan Chancellor wrote:
When booting with clang's kernel control flow integrity series [1],
there are numerous violations when accessing the files under
/sys/devices/pci:00/:00:02.0/drm/card0/gt/gt0:
$ cd
const struct dma_fence_ops *exclude,
bool write,
unsigned long timeout,
gfp_t gfp);
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
On 21/09/2022 19:17, Niranjana Vishwanathapura wrote:
On Wed, Sep 21, 2022 at 11:18:53AM +0100, Tvrtko Ursulin wrote:
On 21/09/2022 08:09, Niranjana Vishwanathapura wrote:
The new execbuf3 ioctl path and the legacy execbuf ioctl
paths have many common functionalities.
Share code between
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 used by the vm_bind feature.
Signed-off
On 21/09/2022 01:02, Dixit, Ashutosh wrote:
On Fri, 16 Sep 2022 08:00:50 -0700, Badal Nilawar wrote:
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index e2974f928e58..bc061238e35c 100644
---
On 21/09/2022 08:09, Niranjana Vishwanathapura wrote:
The new execbuf3 ioctl path and the legacy execbuf ioctl
paths have many common functionalities.
Share code between these two paths by abstracting out the
common functionalities into a separate file where possible.
Looks like a good start
On 21/09/2022 08:09, Niranjana Vishwanathapura wrote:
Expose i915_gem_object_max_page_size() function non-static
which will be used by the vm_bind feature.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 20
On 21/09/2022 08:09, Niranjana Vishwanathapura wrote:
Add function __i915_sw_fence_await_reservation() for
asynchronous wait on a dma-resv object with specified
dma_resv_usage. This is required for async vma unbind
with vm_bind.
Signed-off-by: Niranjana Vishwanathapura
---
On 16/09/2022 10:50, Lucas Stach wrote:
Hi Tvrtko,
Am Freitag, dem 16.09.2022 um 10:31 +0100 schrieb Tvrtko Ursulin:
Hi Lucas,
On 08/09/2022 19:10, Lucas Stach wrote:
This exposes a accumulated GPU active time per client via the
fdinfo infrastructure.
Signed-off-by: Lucas Stach
Hi Lucas,
On 08/09/2022 19:10, Lucas Stach wrote:
This exposes a accumulated GPU active time per client via the
fdinfo infrastructure.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 38 ++-
1 file changed, 37 insertions(+), 1 deletion(-)
On 15/09/2022 21:03, John Harrison wrote:
On 9/15/2022 01:59, Tvrtko Ursulin wrote:
Hi,
On 15/09/2022 00:46, john.c.harri...@intel.com wrote:
From: John Harrison
Going forwards, the intention is for GuC firmware files to be named
for their major version only and HuC firmware files
On 16/09/2022 02:43, Matt Roper wrote:
Although the bspec lists several MMIO ranges as "MSLICE," it turns out
that a subset of these are of a "GAM" subclass that has unique rules and
doesn't followed regular mslice steering behavior.
* Xe_HP SDV: GAM ranges must always be steered to 0,0.
901 - 1000 of 2202 matches
Mail list logo
