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.
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 to have no version
number in the name at all. This patch adds those entries for all
platforms
On 07/09/2022 14:48, Tvrtko Ursulin wrote:
On 06/09/2022 17:14, Tvrtko Ursulin wrote:
On 05/09/2022 10:34, Tvrtko Ursulin wrote:
On 01/09/2022 19:38, Niranjana Vishwanathapura wrote:
So far, different views (normal, partial, rotated and remapped)
into the same object are only supported
On 06/09/2022 17:14, Tvrtko Ursulin wrote:
On 05/09/2022 10:34, Tvrtko Ursulin wrote:
On 01/09/2022 19:38, Niranjana Vishwanathapura wrote:
So far, different views (normal, partial, rotated and remapped)
into the same object are only supported for GGTT mappings.
But with the upcoming
On 05/09/2022 10:34, Tvrtko Ursulin wrote:
On 01/09/2022 19:38, Niranjana Vishwanathapura wrote:
So far, different views (normal, partial, rotated and remapped)
into the same object are only supported for GGTT mappings.
But with the upcoming VM_BIND feature, PPGTT will also use the
partial
On 06/09/2022 12:21, Tvrtko Ursulin wrote:
On 06/09/2022 11:43, Christian König wrote:
Am 06.09.22 um 12:20 schrieb Tvrtko Ursulin:
On 06/09/2022 09:39, Christian König wrote:
Am 05.09.22 um 18:35 schrieb Arvind Yadav:
The core DMA-buf framework needs to enable signaling
before the fence
On 06/09/2022 11:43, Christian König wrote:
Am 06.09.22 um 12:20 schrieb Tvrtko Ursulin:
On 06/09/2022 09:39, Christian König wrote:
Am 05.09.22 um 18:35 schrieb Arvind Yadav:
The core DMA-buf framework needs to enable signaling
before the fence is signaled. The core DMA-buf framework
can
On 06/09/2022 09:39, Christian König wrote:
Am 05.09.22 um 18:35 schrieb Arvind Yadav:
The core DMA-buf framework needs to enable signaling
before the fence is signaled. The core DMA-buf framework
can forget to enable signaling before the fence is signaled.
This sentence is a bit confusing.
Hi Dan,
On 01/09/2022 16:38, Dan Carpenter wrote:
This code uses struct_size() but it stores the result in an int so the
integer overflow checks are not effective. Record the types as size_t
to prevent the size from being truncated.
Fixes: bf3c50837506 ("drm/i915/query: Use struct_size()
On 05/09/2022 12:21, Christian König wrote:
Am 05.09.22 um 12:56 schrieb Arvind Yadav:
The core DMA-buf framework needs to enable signaling
before the fence is signaled. The core DMA-buf framework
can forget to enable signaling before the fence is signaled.
To avoid this scenario on the debug
On 02/09/2022 06:41, Niranjana Vishwanathapura wrote:
On Thu, Sep 01, 2022 at 08:58:57AM +0100, Tvrtko Ursulin wrote:
On 01/09/2022 06:09, Niranjana Vishwanathapura wrote:
On Wed, Aug 31, 2022 at 08:38:48AM +0100, Tvrtko Ursulin wrote:
On 27/08/2022 20:43, Andi Shyti wrote:
From
generic
gtt_view.
Signed-off-by: Niranjana Vishwanathapura
Acked-by: Tvrtko Ursulin
Easily even r-b since I did scroll through it and it all looks
straightforward.
Regards,
Tvrtko
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
drivers/gpu/drm/i915/display/intel_display.h
On 01/09/2022 06:09, Niranjana Vishwanathapura wrote:
On Wed, Aug 31, 2022 at 08:38:48AM +0100, Tvrtko Ursulin wrote:
On 27/08/2022 20:43, Andi Shyti wrote:
From: Niranjana Vishwanathapura
Implement new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only
works in vm_bind mode. The vm_bind
On 27/08/2022 20:43, Andi Shyti wrote:
From: Niranjana Vishwanathapura
Implement new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only
works in vm_bind mode. The vm_bind mode only works with
this new execbuf3 ioctl.
The new execbuf3 ioctl will not have any list of objects to validate
bind as
On 27/08/2022 20:43, Andi Shyti wrote:
Hi,
just sending the original Niranjana's patch as an RFC. It's v3 as
the v2 has been reviewed offline with Ramalingam.
I'm still keeping most of the structure even though some further
discussion can be done starting from here.
Copy pasting Niranjana's
On 30/08/2022 19:19, Matthew Auld wrote:
On 27/08/2022 20:43, Andi Shyti wrote:
From: Niranjana Vishwanathapura
Implement the bind and unbind of an object at the specified GPU virtual
addresses.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Prathap Kumar Valsan
Signed-off-by:
On 17/08/2022 08:34, Thomas Hellström wrote:
On Wed, 2022-08-17 at 09:55 +0300, Sviatoslav Peleshko wrote:
The i915_gem_object_trylock we had in the grab_vma() makes it return
false
when the vma->obj is already locked. In this case we'll skip this vma
during eviction, and eventually might be
On 12/08/2022 16:31, Ceraolo Spurio, Daniele wrote:
On 8/12/2022 12:29 AM, Tvrtko Ursulin wrote:
On 11/08/2022 22:08, Daniele Ceraolo Spurio wrote:
If the GuC CTs are full and we need to stall the request submission
while waiting for space, we save the stalled request and where the stall
On 11/08/2022 22:08, Daniele Ceraolo Spurio wrote:
If the GuC CTs are full and we need to stall the request submission
while waiting for space, we save the stalled request and where the stall
occurred; when the CTs have space again we pick up the request submission
from where we left off.
() calls with dma_max_mapping_size().
In i915_gem_object_get_pages_internal() no longer consider
max_segment
only if CONFIG_SWIOTLB is enabled. There can be other (iommu related)
causes of specific max segment sizes.
Cc: Christoph Hellwig
Cc: Tvrtko Ursulin
Cc: Thomas Hellstrom
Cc: Matthew Auld
On 05/08/2022 10:08, Andi Shyti wrote:
Hi Randy,
+/**
+ * intel_gt_invalidate_tlb_full - do full TLB cache invalidation
+ * @gt: GT structure
In multiple places (here and below) it would be nice to know what a
GT structure is. I looked thru multiple C and header files yesterday
and didn't
On 04/08/2022 00:54, Dave Airlie wrote:
On Thu, 4 Aug 2022 at 06:21, Oded Gabbay wrote:
On Wed, Aug 3, 2022 at 10:04 PM Dave Airlie wrote:
On Sun, 31 Jul 2022 at 22:04, Oded Gabbay wrote:
Hi,
Greg and I talked a couple of months ago about preparing a new accel
subsystem for
On 04/08/2022 08:37, Mauro Carvalho Chehab wrote:
WRITE_ONCE() should happen at the original var, not on a local
copy of it.
Fixes: 5d36acb7198b ("drm/i915/gt: Batch TLB invalidations")
Cc: stable I think, since the above one was. So both hit 5.21 (or 6.1)
together.
Regards,
Tvrtko
On 28/07/2022 07:32, Mauro Carvalho Chehab wrote:
On Wed, 27 Jul 2022 13:56:50 +0100
Tvrtko Ursulin wrote:
Because vma_invalidate_tlb() basically stores a TLB seqno, but the
actual invalidation is deferred to when the pages are unset, at
__i915_gem_object_unset_pages().
So, what happens
Hi Dave, Daniel,
Just one fix this time round to further improve reliability of resets on
execlists platforms in some edge cases.
Not sure if there is scope to do one more fixes pull before 5.19 is out so
just in case. If it doesn't get pulled we'll send it to stable after release.
Regards,
On 27/07/2022 12:48, Mauro Carvalho Chehab wrote:
On Wed, 20 Jul 2022 11:49:59 +0100
Tvrtko Ursulin wrote:
On 20/07/2022 08:13, Mauro Carvalho Chehab wrote:
On Mon, 18 Jul 2022 14:52:05 +0100
Tvrtko Ursulin wrote:
On 14/07/2022 13:06, Mauro Carvalho Chehab wrote:
From: Chris Wilson
consider max_segment
only if CONFIG_SWIOTLB is enabled. There can be other (iommu related)
causes of specific max segment sizes.
Cc: Christoph Hellwig
Cc: Tvrtko Ursulin
Cc: Thomas Hellstrom
Cc: Matthew Auld
v2: - restore UINT_MAX clamp in i915_sg_segment_size()
- drop PAGE_SIZE check
On 26/07/2022 08:46, Thomas Zimmermann wrote:
Hi
Am 25.07.22 um 19:14 schrieb Christian König:
Am 25.07.22 um 17:27 schrieb Tvrtko Ursulin:
On 24/07/2022 19:28, Thomas Zimmermann wrote:
Hi
Am 22.07.22 um 17:47 schrieb Christian König:
Hi Tvrtko,
scratching my head what exactly is going
On 26/07/2022 06:07, Niranjana Vishwanathapura wrote:
On Mon, Jul 18, 2022 at 11:55:41AM +0100, Tvrtko Ursulin wrote:
On 01/07/2022 23:50, Niranjana Vishwanathapura wrote:
Bind and unbind the mappings upon VM_BIND and VM_UNBIND calls.
Signed-off-by: Niranjana Vishwanathapura
Signed-off
st regards
Thomas
Regards,
Christian.
Am 22.07.22 um 16:46 schrieb Tvrtko Ursulin:
On 14/07/2022 09:45, Thomas Zimmermann wrote:
Hi
Am 08.07.22 um 11:30 schrieb Arunpravin Paneer Selvam:
This reverts commit 708d19d9f362766147cab79eccae60912c6d3068.
This commit is only present in drm-misc-ne
On 22/07/2022 20:32, John Harrison wrote:
On 7/19/2022 02:56, Tvrtko Ursulin wrote:
On 19/07/2022 01:13, John Harrison wrote:
On 7/18/2022 05:35, Tvrtko Ursulin wrote:
On 13/07/2022 00:31, john.c.harri...@intel.com wrote:
From: Matthew Brost
The GuC needs a copy of a golden context
On 14/07/2022 09:45, Thomas Zimmermann wrote:
Hi
Am 08.07.22 um 11:30 schrieb Arunpravin Paneer Selvam:
This reverts commit 708d19d9f362766147cab79eccae60912c6d3068.
This commit is only present in drm-misc-next. Should the revert be
cherry-picked into drm-misc-next-fixes?
Seemed like an
On 22/07/2022 10:58, Christoph Hellwig wrote:
On Fri, Jul 22, 2022 at 10:45:54AM +0100, Tvrtko Ursulin wrote:
- unsigned int size = swiotlb_max_segment();
-
- if (size == 0)
- size = UINT_MAX;
On a more detailed look, there was a CI failure which makes me think
consider max_segment
only if CONFIG_SWIOTLB is enabled. There can be other (iommu related)
causes of specific max segment sizes.
Cc: Christoph Hellwig
Cc: Tvrtko Ursulin
Cc: Thomas Hellstrom
Cc: Matthew Auld
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c
you'd take it on fully. Thanks!
Christoph - ack from you? Also, if we merge it via the normal process it
will hit 5.21 only. Does that work for you?
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
Cc: Christoph Hellwig
Cc: Tvrtko Ursulin
Cc: Thomas Hellstrom
Cc: Matthew Auld
Signed-off
On 19/07/2022 16:29, Ceraolo Spurio, Daniele wrote:
On 7/19/2022 12:34 AM, Tvrtko Ursulin wrote:
On 18/07/2022 17:41, Ceraolo Spurio, Daniele wrote:
On 7/18/2022 3:02 AM, Tvrtko Ursulin wrote:
Hi,
On 15/07/2022 23:54, Daniele Ceraolo Spurio wrote:
This patch re-introduces support
On 21/07/2022 01:54, John Harrison wrote:
On 7/19/2022 02:42, Tvrtko Ursulin wrote:
On 19/07/2022 01:05, John Harrison wrote:
On 7/18/2022 05:15, Tvrtko Ursulin wrote:
On 13/07/2022 00:31, john.c.harri...@intel.com wrote:
From: Matthew Brost
Remove bogus GEM_BUG_ON which compared
: rebased to not require moving the code to a separate file]
Cc: sta...@vger.kernel.org
Fixes: 7938d61591d3 ("drm/i915: Flush TLBs before releasing backing store")
Suggested-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Cc: Fei Yang
Signed-off-by: Mauro Carvalho Chehab
---
To avoid m
On 20/07/2022 08:13, Mauro Carvalho Chehab wrote:
On Mon, 18 Jul 2022 14:52:05 +0100
Tvrtko Ursulin wrote:
On 14/07/2022 13:06, Mauro Carvalho Chehab wrote:
From: Chris Wilson
Invalidate TLB in patch, in order to reduce performance regressions.
"in batches"?
Yeah
On 19/07/2022 10:49, Tvrtko Ursulin wrote:
On 19/07/2022 01:09, John Harrison wrote:
On 7/18/2022 05:26, Tvrtko Ursulin wrote:
On 13/07/2022 00:31, john.c.harri...@intel.com wrote:
From: Matthew Brost
The engine registers really shouldn't be touched during GuC submission
as the GuC owns
On 19/07/2022 01:13, John Harrison wrote:
On 7/18/2022 05:35, Tvrtko Ursulin wrote:
On 13/07/2022 00:31, john.c.harri...@intel.com wrote:
From: Matthew Brost
The GuC needs a copy of a golden context for implementing watchdog
resets (aka media resets). This context is larger on newer
On 19/07/2022 01:09, John Harrison wrote:
On 7/18/2022 05:26, Tvrtko Ursulin wrote:
On 13/07/2022 00:31, john.c.harri...@intel.com wrote:
From: Matthew Brost
The engine registers really shouldn't be touched during GuC submission
as the GuC owns the registers. Don't call ring_is_idle
On 19/07/2022 01:05, John Harrison wrote:
On 7/18/2022 05:15, Tvrtko Ursulin wrote:
On 13/07/2022 00:31, john.c.harri...@intel.com wrote:
From: Matthew Brost
Remove bogus GEM_BUG_ON which compared kernel context timeline seqno to
seqno in memory on engine PM unpark. If a GT reset occurred
On 18/07/2022 17:41, Ceraolo Spurio, Daniele wrote:
On 7/18/2022 3:02 AM, Tvrtko Ursulin wrote:
Hi,
On 15/07/2022 23:54, Daniele Ceraolo Spurio wrote:
This patch re-introduces support for GuC v69 in parallel to v70. As this
is a quick fix, v69 has been re-introduced as the single "fal
Hi David,
On 18/07/2022 16:50, David Laight wrote:
From: Mauro Carvalho Chehab
Sent: 18 July 2022 15:54
On Mon, 18 Jul 2022 14:16:10 +0100
Tvrtko Ursulin wrote:
On 14/07/2022 13:06, Mauro Carvalho Chehab wrote:
From: Chris Wilson
Check if the device is powered down prior to any engine
On 18/07/2022 17:06, Mauro Carvalho Chehab wrote:
On Mon, 18 Jul 2022 14:45:22 +0100
Tvrtko Ursulin wrote:
On 14/07/2022 13:06, Mauro Carvalho Chehab wrote:
From: Chris Wilson
Skip all further TLB invalidations once the device is wedged and
had been reset, as, on such cases, it can
On 18/07/2022 15:53, Mauro Carvalho Chehab wrote:
On Mon, 18 Jul 2022 14:16:10 +0100
Tvrtko Ursulin wrote:
On 14/07/2022 13:06, Mauro Carvalho Chehab wrote:
From: Chris Wilson
Check if the device is powered down prior to any engine activity,
as, on such cases, all the TLBs were already
date logic.
[mchehab: rebased to not require moving the code to a separate file]
Cc: sta...@vger.kernel.org
Fixes: 7938d61591d3 ("drm/i915: Flush TLBs before releasing backing store")
Suggested-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Cc: Fei Yang
Signed-off-by: Mauro Carvalho C
On 14/07/2022 13:06, Mauro Carvalho Chehab wrote:
From: Chris Wilson
Skip all further TLB invalidations once the device is wedged and
had been reset, as, on such cases, it can no longer process instructions
on the GPU and the user no longer has access to the TLB's in each engine.
That helps
On 14/07/2022 13:06, Mauro Carvalho Chehab wrote:
From: Chris Wilson
Don't flush TLBs when the buffer is only used in the GGTT under full
control of the kernel, as there's no risk of concurrent access
and stale access from prefetch.
We only need to invalidate the TLB if they are accessible
cking store")
Signed-off-by: Chris Wilson
Cc: Fei Yang
Cc: Andi Shyti
Acked-by: Thomas Hellström
Signed-off-by: Mauro Carvalho Chehab
Acked-by: Tvrtko Ursulin
Regards,
Tvrtko
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATC
in kerneldoc the put is async. Although for me documenting
trivial helpers is a bit over the top by anyway..
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
On 14/07/2022 13:06, Mauro Carvalho Chehab wrote:
From: Chris Wilson
Check if the device is powered down prior to any engine activity,
as, on such cases, all the TLBs were already invalidated, so an
explicit TLB invalidation is not needed, thus reducing the
performance regression impact due
On 13/07/2022 00:31, john.c.harri...@intel.com wrote:
From: John Harrison
When the KMD sends a CLIENT_RESET request to GuC (as part of the
suspend sequence), GuC will mark the CTB buffer as 'UNUSED'. If the
KMD then checked the CTB queue, it would see a non-zero status value
and report the
On 13/07/2022 00:31, john.c.harri...@intel.com wrote:
From: Matthew Brost
The GuC needs a copy of a golden context for implementing watchdog
resets (aka media resets). This context is larger on newer platforms.
So adjust the size being allocated/copied accordingly.
What were the
On 13/07/2022 00:31, john.c.harri...@intel.com wrote:
From: Matthew Brost
The engine registers really shouldn't be touched during GuC submission
as the GuC owns the registers. Don't call ring_is_idle and tie
Touch being just read and it is somehow harmful?
intel_engine_is_idle strictly
On 13/07/2022 00:31, john.c.harri...@intel.com wrote:
From: Matthew Brost
Remove bogus GEM_BUG_ON which compared kernel context timeline seqno to
seqno in memory on engine PM unpark. If a GT reset occurred these values
might not match as a kernel context could be skipped. This bug was
hidden
Hi,
On 12/07/2022 06:00, Christoph Hellwig wrote:
On Mon, Jul 11, 2022 at 04:31:49PM -0400, Rodrigo Vivi wrote:
On Mon, Jul 11, 2022 at 10:26:14AM +0200, Christoph Hellwig wrote:
Hi i915 and nouveau maintainers,
any chance I could get some help to remove the remaining direct
driver calls
t patch [1], it sounds like the media driver already
expected an errno value for all errors cases and is therefore already
compatible with the proposed changes.
I also think this is fine - just more error cases. And I don't see that
it could break something. So from me:
Acked-by: Tvrtko Ursulin
On 01/07/2022 23:50, Niranjana Vishwanathapura wrote:
Bind and unbind the mappings upon VM_BIND and VM_UNBIND calls.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Prathap Kumar Valsan
---
drivers/gpu/drm/i915/Makefile | 1 +
Hi,
On 15/07/2022 23:54, Daniele Ceraolo Spurio wrote:
This patch re-introduces support for GuC v69 in parallel to v70. As this
is a quick fix, v69 has been re-introduced as the single "fallback" guc
version in case v70 is not available on disk. All v69 specific code has
been labeled as such
On 30/06/2022 17:22, Niranjana Vishwanathapura wrote:
On Thu, Jun 30, 2022 at 08:59:09AM +0100, Tvrtko Ursulin wrote:
On 30/06/2022 07:08, Niranjana Vishwanathapura wrote:
On Wed, Jun 29, 2022 at 05:33:49PM -0700, Zanoni, Paulo R wrote:
On Sat, 2022-06-25 at 18:49 -0700, Niranjana
On 30/06/2022 17:01, Mauro Carvalho Chehab wrote:
Em Thu, 30 Jun 2022 09:12:41 +0100
Tvrtko Ursulin escreveu:
On 30/06/2022 08:32, Mauro Carvalho Chehab wrote:
Em Wed, 29 Jun 2022 17:02:59 +0100
Tvrtko Ursulin escreveu:
On 29/06/2022 16:30, Mauro Carvalho Chehab wrote:
On Tue, 28
On 30/06/2022 12:19, Tetsuo Handa wrote:
On 2022/06/30 19:17, Tvrtko Ursulin wrote:
Could you give more context on reasoning here please? What is the difference
between using the system_wq and flushing it from a random context? Or concern
is about flushing from specific contexts?
Excuse me
From: Tvrtko Ursulin
There are ongoing efforts to remove usages of flush_scheduled_work() from
drivers in order to avoid several cases of potentential problems when
flushing is done from certain contexts.
Remove the call from the live_execlists selftest. Its purpose was to be
thorough and sync
On 30/06/2022 09:06, Tetsuo Handa wrote:
On 2022/06/30 16:46, Tvrtko Ursulin wrote:
Hi,
On 10/06/2022 15:57, Tetsuo Handa wrote:
Hello.
Like commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using
a macro") explains, we are removing flush_scheduled_work() call
On 30/06/2022 08:32, Mauro Carvalho Chehab wrote:
Em Wed, 29 Jun 2022 17:02:59 +0100
Tvrtko Ursulin escreveu:
On 29/06/2022 16:30, Mauro Carvalho Chehab wrote:
On Tue, 28 Jun 2022 16:49:23 +0100
Tvrtko Ursulin wrote:
.. which for me means a different patch 1, followed by patch 6
On 30/06/2022 07:08, Niranjana Vishwanathapura wrote:
On Wed, Jun 29, 2022 at 05:33:49PM -0700, Zanoni, Paulo R wrote:
On Sat, 2022-06-25 at 18:49 -0700, Niranjana Vishwanathapura wrote:
VM_BIND and related uapi definitions
v2: Reduce the scope to simple Mesa use case.
v3: Expand VM_UNBIND
Hi,
On 10/06/2022 15:57, Tetsuo Handa wrote:
Hello.
Like commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using
a macro") explains, we are removing flush_scheduled_work() calls. And now
drivers/gpu/drm/i915/display/intel_display.c
On 29/06/2022 16:30, Mauro Carvalho Chehab wrote:
On Tue, 28 Jun 2022 16:49:23 +0100
Tvrtko Ursulin wrote:
.. which for me means a different patch 1, followed by patch 6 (moved
to be patch 2) would be ideal stable material.
Then we have the current patch 2 which is open/unknown (to me
ng support (Daniele Ceraolo Spurio)
- Fix build error without CONFIG_PM (YueHaibing)
- Enable THP on Icelake and beyond (Tvrtko Ursulin)
- Only setup private tmpfs mount when needed and fix logging (Tvrtko Ursulin)
- Make __guc_reset_context aware of guilty engines (Umesh Nerlige Ramappa)
- DG2 small
Hi,
On 27/06/2022 10:00, Mauro Carvalho Chehab (by way of Mauro Carvalho
Chehab ) wrote:
Hi Tvrtko,
On Fri, 24 Jun 2022 09:34:21 +0100
Tvrtko Ursulin wrote:
On 23/06/2022 12:17, Andi Shyti wrote:
Hi Mauro,
On Wed, Jun 15, 2022 at 04:27:39PM +0100, Mauro Carvalho Chehab wrote:
From
On 27/06/2022 19:58, Zeng, Oak wrote:
Thanks,
Oak
-Original Message-
From: Tvrtko Ursulin
Sent: June 27, 2022 4:30 AM
To: Zeng, Oak ; Landwerlin, Lionel G
; Vishwanathapura, Niranjana
Cc: Zanoni, Paulo R ; intel-
g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
u need to record all the VAs that this pa has been
bound to and invalidate all the VA ranges - ugly program.
Someone can setup some benchmarking? :)
Regards,
Tvrtko
Thanks,
Oak
-Original Message-
From: Tvrtko Ursulin
Sent: June 24, 2022 4:32 AM
To: Zeng, Oak ; Landwerlin, Lionel
On 23/06/2022 12:17, Andi Shyti wrote:
Hi Mauro,
On Wed, Jun 15, 2022 at 04:27:39PM +0100, Mauro Carvalho Chehab wrote:
From: Chris Wilson
Don't allow two engines to be reset in parallel, as they would both
try to select a reset bit (and send requests to common registers)
and wait on that
On 23/06/2022 22:05, Zeng, Oak wrote:
-Original Message-
From: Intel-gfx On Behalf Of Tvrtko
Ursulin
Sent: June 23, 2022 7:06 AM
To: Landwerlin, Lionel G ; Vishwanathapura,
Niranjana
Cc: Zanoni, Paulo R ; intel-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org; Hellstrom
On 24/06/2022 06:32, Niranjana Vishwanathapura wrote:
VM_BIND and related uapi definitions
v2: Reduce the scope to simple Mesa use case.
v3: Expand VM_UNBIND documentation and add
I915_GEM_VM_BIND/UNBIND_FENCE_VALID
and I915_GEM_VM_BIND_TLB_FLUSH flags.
v4: Remove
901 - 1000 of 2126 matches
Mail list logo
