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
On 23/06/2022 09:57, Lionel Landwerlin wrote:
On 23/06/2022 11:27, Tvrtko Ursulin wrote:
After a vm_unbind, UMD can re-bind to same VA range against an active
VM.
Though I am not sue with Mesa usecase if that new mapping is required
for
running GPU job or it will be for the next
On 22/06/2022 17:44, Niranjana Vishwanathapura wrote:
On Wed, Jun 22, 2022 at 04:57:17PM +0100, Tvrtko Ursulin wrote:
On 22/06/2022 16:12, Niranjana Vishwanathapura wrote:
On Wed, Jun 22, 2022 at 09:10:07AM +0100, Tvrtko Ursulin wrote:
On 22/06/2022 04:56, Niranjana Vishwanathapura wrote
On 22/06/2022 22:28, Dixit, Ashutosh wrote:
On Wed, 22 Jun 2022 13:30:23 -0700, Belgaumkar, Vinay wrote:
On 6/21/2022 5:26 PM, Dixit, Ashutosh wrote:
On Sat, 14 May 2022 23:05:06 -0700, Vinay Belgaumkar wrote:
The issue I have is what happens when we de-boost (restore min freq to its
On 22/06/2022 16:12, Niranjana Vishwanathapura wrote:
On Wed, Jun 22, 2022 at 09:10:07AM +0100, Tvrtko Ursulin wrote:
On 22/06/2022 04:56, Niranjana Vishwanathapura wrote:
VM_BIND and related uapi definitions
v2: Reduce the scope to simple Mesa use case.
v3: Expand VM_UNBIND documentation
On 21/06/2022 15:43, Niranjana Vishwanathapura wrote:
On Tue, Jun 21, 2022 at 09:35:16AM +0100, Tvrtko Ursulin wrote:
On 20/06/2022 17:29, Niranjana Vishwanathapura wrote:
On Mon, Jun 20, 2022 at 11:43:10AM +0100, Tvrtko Ursulin wrote:
Hi,
On 17/06/2022 06:14, Niranjana Vishwanathapura
On 22/06/2022 04:56, 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.
Signed-off-by: Niranjana
On 16/06/2022 08:08, 1064094...@qq.com wrote:
From: pengfuyuan
Fix spelling typo in comment.
Reported-by: k2ci
Signed-off-by: pengfuyuan
---
drivers/gpu/drm/i915/gem/i915_gem_tiling.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 21/06/2022 03:26, Katrin Jo wrote:
On Mon, Jun 20, 2022 at 6:19 PM Tvrtko Ursulin
wrote:
On 20/06/2022 11:02, zys.zlj...@gmail.com wrote:
From: katrinzhou
The variable ret is reassigned and the value EINVAL is never used.
Thus, remove the unused assignments.
Addresses-Coverity
On 20/06/2022 17:29, Niranjana Vishwanathapura wrote:
On Mon, Jun 20, 2022 at 11:43:10AM +0100, Tvrtko Ursulin wrote:
Hi,
On 17/06/2022 06:14, Niranjana Vishwanathapura wrote:
VM_BIND design document with description of intended use cases.
v2: Reduce the scope to simple Mesa use case
Hi,
On 17/06/2022 06:14, Niranjana Vishwanathapura wrote:
VM_BIND design document with description of intended use cases.
v2: Reduce the scope to simple Mesa use case.
since I expressed interest please add me to cc when sending out.
How come the direction changed to simplify all of a
On 20/06/2022 11:02, zys.zlj...@gmail.com wrote:
From: katrinzhou
The variable ret is reassigned and the value EINVAL is never used.
Thus, remove the unused assignments.
Addresses-Coverity: ("Unused value")
Fixes: d4433c7600f7 ("drm/i915/gem: Use the proto-context to handle create
mch_gtt_flush();
+}
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_gmch.h
b/drivers/gpu/drm/i915/gt/intel_ggtt_gmch.h
new file mode 100644
index ..370bf321b4e2
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt_gmch.h
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyri
nt pg,
+ unsigned int flags);
+void intel_gmch_gtt_insert_sg_entries(struct sg_table *st,
+ unsigned int pg_start,
+ unsigned int flags);
+void intel_gmch_gtt_clear_range(unsigned int first_entry, unsigned int
num_entries);
/* Special gtt memory types */
#define AGP_DCACHE_MEMORY 1
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
On 16/06/2022 15:15, Jani Nikula wrote:
On Thu, 16 Jun 2022, Tvrtko Ursulin wrote:
On 16/06/2022 13:01, Anshuman Gupta wrote:
DG2 NB SKU need to distinguish between MBD and AIC to probe
the VRAM Self Refresh feature support. Adding those sub platform
accordingly.
Cc: Matt Roper
Signed-off
On 16/06/2022 13:01, Anshuman Gupta wrote:
DG2 NB SKU need to distinguish between MBD and AIC to probe
the VRAM Self Refresh feature support. Adding those sub platform
accordingly.
Cc: Matt Roper
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
On 15/06/2022 16:20, Niranjana Vishwanathapura wrote:
On Wed, Jun 15, 2022 at 08:22:23AM +0100, Tvrtko Ursulin wrote:
On 14/06/2022 17:42, Niranjana Vishwanathapura wrote:
On Tue, Jun 14, 2022 at 05:07:37PM +0100, Tvrtko Ursulin wrote:
On 14/06/2022 17:02, Tvrtko Ursulin wrote:
On 14/06
finitely does not belong in this patch.
Otherwise LGTM:
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
Reported-by: Mika Kuoppala
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Andi Shyti
Cc: sta...@vger.kernel.org
Acked-by: Thomas Hellström
Signed-off-by: Mauro Carvalho Chehab
---
S
On 15/06/2022 16:27, 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 of concurrent access
and stale access from prefetch.
We only need to invalidate the TLB if they are
On 15/06/2022 16:27, 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.
Fixes:
On 15/06/2022 16:27, Mauro Carvalho Chehab wrote:
From: Chris Wilson
As an extension of the current skip TLB invalidations,
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
hereas drm-engine- only reflects
+time active without considering what frequency the engine is operating as a
+percentage of it's maximum frequency.
Slipped my mind to reply to v3..
Acked-by: Tvrtko Ursulin
Regards,
Tvrtko
+
===
Driver specific imple
On 08/06/2022 21:45, Niranjana Vishwanathapura wrote:
On Wed, Jun 08, 2022 at 09:54:24AM +0100, Tvrtko Ursulin wrote:
On 08/06/2022 09:45, Lionel Landwerlin wrote:
On 08/06/2022 11:36, Tvrtko Ursulin wrote:
On 08/06/2022 07:40, Lionel Landwerlin wrote:
On 03/06/2022 09:53, Niranjana
On 14/06/2022 17:42, Niranjana Vishwanathapura wrote:
On Tue, Jun 14, 2022 at 05:07:37PM +0100, Tvrtko Ursulin wrote:
On 14/06/2022 17:02, Tvrtko Ursulin wrote:
On 14/06/2022 16:43, Niranjana Vishwanathapura wrote:
On Tue, Jun 14, 2022 at 08:16:41AM +0100, Tvrtko Ursulin wrote:
On 14/06
On 14/06/2022 17:02, Tvrtko Ursulin wrote:
On 14/06/2022 16:43, Niranjana Vishwanathapura wrote:
On Tue, Jun 14, 2022 at 08:16:41AM +0100, Tvrtko Ursulin wrote:
On 14/06/2022 00:39, Matthew Brost wrote:
On Mon, Jun 13, 2022 at 07:09:06PM +0100, Tvrtko Ursulin wrote:
On 13/06/2022 18:49
1001 - 1100 of 2202 matches
Mail list logo
