On 2/9/24 15:08, Michał Winiarski wrote:
Fix one of the tests in drm_mm that was not converted prior to
drm_debug_printer removal, causing tests build failure.
Fixes: e154c4fc7bf2d ("drm: remove drm_debug_printer in favor of
drm_dbg_printer")
Signed-off-by: Michał Winiarski
---
drivers/gpu
On 11/27/23 14:24, Christian König wrote:
Ping? Can I get an rb or acked-by for that?
Thanks,
Christian.
Am 15.11.23 um 10:30 schrieb Christian König:
It's valid to add the same fence multiple times to a dma-resv object and
we shouldn't need one extra slot for each.
Signed-off-by: Christian
On 8/31/23 21:07, Danilo Krummrich wrote:
On Thu, Aug 31, 2023 at 06:53:01PM +0200, Thomas Hellström (Intel) wrote:
Hi,
On 8/31/23 13:18, Danilo Krummrich wrote:
On Thu, Aug 31, 2023 at 11:04:06AM +0200, Thomas Hellström (Intel) wrote:
Hi!
On 8/30/23 17:00, Danilo Krummrich wrote:
On Wed
Hi,
On 8/31/23 13:18, Danilo Krummrich wrote:
On Thu, Aug 31, 2023 at 11:04:06AM +0200, Thomas Hellström (Intel) wrote:
Hi!
On 8/30/23 17:00, Danilo Krummrich wrote:
On Wed, Aug 30, 2023 at 03:42:08PM +0200, Thomas Hellström (Intel) wrote:
On 8/30/23 14:49, Danilo Krummrich wrote:
Hi
Hi!
On 8/30/23 17:00, Danilo Krummrich wrote:
On Wed, Aug 30, 2023 at 03:42:08PM +0200, Thomas Hellström (Intel) wrote:
On 8/30/23 14:49, Danilo Krummrich wrote:
Hi Thomas,
thanks for having a look!
On Wed, Aug 30, 2023 at 09:27:45AM +0200, Thomas Hellström (Intel) wrote:
Hi, Danilo.
Some
On 8/30/23 14:49, Danilo Krummrich wrote:
Hi Thomas,
thanks for having a look!
On Wed, Aug 30, 2023 at 09:27:45AM +0200, Thomas Hellström (Intel) wrote:
Hi, Danilo.
Some quick comments since I'm doing some Xe work in this area. Will probably
get back with more.
On 8/20/23 23:53, D
Hi, Danilo.
Some quick comments since I'm doing some Xe work in this area. Will
probably get back with more.
On 8/20/23 23:53, Danilo Krummrich wrote:
So far the DRM GPUVA manager offers common infrastructure to track GPU VA
allocations and mappings, generically connect GPU VA mappings to the
On 7/6/23 17:48, Danilo Krummrich wrote:
Hi Thomas,
On 7/6/23 10:49, Thomas Hellström (Intel) wrote:
Hi, Danilo
Some review comments below:
On 6/30/23 00:25, Danilo Krummrich wrote:
Add infrastructure to keep track of GPU virtual address (VA) mappings
with a decicated VA space manager
Hi, Danilo
Some review comments below:
On 6/30/23 00:25, Danilo Krummrich wrote:
Add infrastructure to keep track of GPU virtual address (VA) mappings
with a decicated VA space manager implementation.
New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers
start implementing, al
On 6/21/23 18:35, Ira Weiny wrote:
Thomas Hellström (Intel) wrote:
I think one thing worth mentioning in the context of this patch is that
IIRC kmap_local_page() will block offlining of the mapping CPU until
kunmap_local(), so while I haven't seen any guidelines around the usage
of thi
On 6/21/23 15:36, Christian König wrote:
This adds the infrastructure for an execution context for GEM buffers
which is similar to the existing TTMs execbuf util and intended to replace
it in the long term.
The basic functionality is that we abstracts the necessary loop to lock
many different
On 6/20/23 20:07, Sumitra Sharma wrote:
On Tue, Jun 20, 2023 at 06:23:38AM -0700, Ira Weiny wrote:
Sumitra Sharma wrote:
On Sun, Jun 18, 2023 at 11:11:08AM -0700, Ira Weiny wrote:
Sumitra Sharma wrote:
kmap() has been deprecated in favor of the kmap_local_page()
due to high cost, restricted
On 6/19/23 11:48, Christian König wrote:
Hi,
Am 19.06.23 um 11:33 schrieb Thomas Hellström (Intel):
[SNIP]
Sometimes you want to just drop the contended lock after the above
relaxation. (Eviction would be one example), and not add as
prelocked, if the contended object goes out of scope
Hi!
On 6/19/23 11:20, Christian König wrote:
Hi guys,
Am 19.06.23 um 10:59 schrieb Thomas Hellström (Intel):
[SNIP]
I really need to find some time to work on that anyway.
I've been playing with drm_exec for a couple weeks now, and I wanted
to share something I hacked to try and mak
On 6/17/23 13:54, Boris Brezillon wrote:
+Matthew who's been using drm_exec in Xe if I'm correct.
Hello Christian,
On Wed, 14 Jun 2023 15:02:52 +0200
Boris Brezillon wrote:
On Wed, 14 Jun 2023 14:30:53 +0200
Christian König wrote:
Am 14.06.23 um 14:23 schrieb Boris Brezillon:
Hi Christ
On 6/18/23 20:11, Ira Weiny wrote:
Sumitra Sharma wrote:
kmap() has been deprecated in favor of the kmap_local_page()
due to high cost, restricted mapping space, the overhead of a
global lock for synchronization, and making the process sleep
in the absence of free slots.
kmap_local_page() is
On 6/14/23 15:22, Tvrtko Ursulin wrote:
On 14/06/2023 13:35, Sumitra Sharma wrote:
Pages allocated with GFP_KERNEL cannot come from Highmem.
That is why there is no need to call kmap() on them.
Are you sure it is GFP_KERNEL backed and not tmpfs? I am not sure
myself so let me copy Matt and
On 5/4/23 13:51, Christian König wrote:
This adds the infrastructure for an execution context for GEM buffers
which is similar to the existing TTMs execbuf util and intended to replace
it in the long term.
The basic functionality is that we abstracts the necessary loop to lock
many different G
On 4/28/23 19:43, Yang, Fei wrote:
>> On 4/28/23 17:19, Yang, Fei wrote:
>>> On 4/28/23 07:47, fei.y...@intel.com wrote:
From: Fei Yang
The first three patches in this series are taken from
https://patchwork.freedesktop.org/series/116868/
These patches are included here
On 4/28/23 17:19, Yang, Fei wrote:
> On 4/28/23 07:47, fei.y...@intel.com wrote:
>> From: Fei Yang
>>
>> The first three patches in this series are taken from
>> https://patchwork.freedesktop.org/series/116868/
>> These patches are included here because the last patch
>> has dependency on the p
On 4/28/23 07:47, fei.y...@intel.com wrote:
From: Fei Yang
The first three patches in this series are taken from
https://patchwork.freedesktop.org/series/116868/
These patches are included here because the last patch
has dependency on the pat_index refactor.
This series is focusing on uAPI c
_fence_work for the actual work although it's completion fence is
a dma_fence.
Although that goes against the whole idea of a condition for merging the
xe driver would be that we implement some sort of minimal scaffolding
for long-running workloads in the drm scheduler, and the thinking be
Hi Christian
On 2/28/23 09:33, Christian König wrote:
This adds the infrastructure for an execution context for GEM buffers
which is similar to the existinc TTMs execbuf util and intended to replace
it in the long term.
The basic functionality is that we abstracts the necessary loop to lock
man
Hi,
On 3/9/23 06:14, Zack Rusin wrote:
On Wed, 2023-03-08 at 10:10 +0100, Christian König wrote:
Am 08.03.23 um 06:14 schrieb Zack Rusin:
On Tue, 2023-02-28 at 09:34 +0100, Christian König wrote:
VMWGFX is the only remaining user of this and should probably moved over
to drm_exec when it star
On 3/8/23 10:10, Christian König wrote:
Am 08.03.23 um 06:14 schrieb Zack Rusin:
On Tue, 2023-02-28 at 09:34 +0100, Christian König wrote:
VMWGFX is the only remaining user of this and should probably moved
over
to drm_exec when it starts using GEM as well.
Is this because vmwgfx piggybacks
On 2/23/23 17:22, Christian König wrote:
Am 23.02.23 um 15:29 schrieb Thomas Hellström:
On 2/23/23 12:15, Christian König wrote:
Am 23.02.23 um 11:57 schrieb Thomas Hellström:
From: Maarten Lankhorst
Now that we have a generic suballocation helper, Use it in amdgpu.
For lines that get mov
On 1/19/23 05:58, Matthew Brost wrote:
On Thu, Jan 19, 2023 at 04:44:23AM +0100, Danilo Krummrich wrote:
On 1/18/23 21:37, Thomas Hellström (Intel) wrote:
On 1/18/23 07:12, Danilo Krummrich wrote:
This commit provides the implementation for the new uapi motivated by the
Vulkan API. It
On 1/18/23 07:12, Danilo Krummrich wrote:
This commit provides the implementation for the new uapi motivated by the
Vulkan API. It allows user mode drivers (UMDs) to:
1) Initialize a GPU virtual address (VA) space via the new
DRM_IOCTL_NOUVEAU_VM_INIT ioctl for UMDs to specify the portion
Hi, Zack,
On 10/19/22 18:32, Zack Rusin wrote:
On Wed, 2022-10-19 at 12:21 +0200, Thomas Hellström (Intel) wrote:
⚠ External Email
On 10/17/22 21:54, Zack Rusin wrote:
From: Maaz Mombasawala
Vmwgfx's hashtab implementation needs to be replaced with linux/hashtable
to reduce mainte
On 10/17/22 21:54, Zack Rusin wrote:
From: Maaz Mombasawala
Vmwgfx's hashtab implementation needs to be replaced with linux/hashtable
to reduce maintenence burden.
As part of this effort, refactor the res_ht hashtable used for resource
validation during execbuf execution to use linux/hashtabl
Hi, Christian,
On 8/19/22 10:52, Christian König wrote:
Hi Thomas,
IIRC we intentionally dropped that approach of balancing
ttm_mem_io_reserve()/ttm_mem_io_free().
Instead the results from ttm_mem_io_reserve() are cached and that
cached information is freed by ttm_mem_io_free(). In other wo
On 6/30/22 22:22, Dmitry Osipenko wrote:
Hello Thomas,
On 6/30/22 23:15, Thomas Hellström (Intel) wrote:
Hi, Dmitry,
On 6/30/22 22:04, Dmitry Osipenko wrote:
Drivers that use drm_gem_mmap() and drm_gem_mmap_obj() helpers don't
handle imported dma-bufs properly, which results in mappi
Hi, Dmitry,
On 6/30/22 22:04, Dmitry Osipenko wrote:
Drivers that use drm_gem_mmap() and drm_gem_mmap_obj() helpers don't
handle imported dma-bufs properly, which results in mapping of something
else than the imported dma-buf. On NVIDIA Tegra we get a hard lockup when
userspace writes to the mem
On 6/29/22 10:22, Dmitry Osipenko wrote:
On 6/29/22 09:40, Thomas Hellström (Intel) wrote:
On 5/27/22 01:50, Dmitry Osipenko wrote:
Drivers that use drm_gem_mmap() and drm_gem_mmap_obj() helpers don't
handle imported dma-bufs properly, which results in mapping of something
else tha
On 5/27/22 01:50, Dmitry Osipenko wrote:
Unlock reservations on dma_resv_reserve_fences() error to fix recursive
locking of the reservations when this error happens.
Fixes:
Cc: sta...@vger.kernel.org
With that fixed,
Reviewed-by: Thomas Hellström
Signed-off-by: Dmitry Osipenko
---
d
On 5/27/22 01:50, Dmitry Osipenko wrote:
Drivers that use drm_gem_mmap() and drm_gem_mmap_obj() helpers don't
handle imported dma-bufs properly, which results in mapping of something
else than the imported dma-buf. For example, on NVIDIA Tegra we get a hard
lockup when userspace writes to the m
On 6/29/22 01:35, Rob Clark wrote:
From: Rob Clark
drive-by cleanup
Signed-off-by: Rob Clark
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
On 5/30/22 15:57, Dmitry Osipenko wrote:
On 5/30/22 16:41, Christian König wrote:
Hi Dmitry,
Am 30.05.22 um 15:26 schrieb Dmitry Osipenko:
Hello Christian,
On 5/30/22 09:50, Christian König wrote:
Hi Dmitry,
First of all please separate out this patch from the rest of the series,
since th
Hi,
On 5/27/22 01:50, Dmitry Osipenko wrote:
Use ww_acquire_fini() in the error code paths. Otherwise lockdep
thinks that lock is held when lock's memory is freed after the
drm_gem_lock_reservations() error. The WW needs to be annotated
as "freed"
s /WW/ww_acquire_context/ ?
s /"freed"/"releas
On 5/25/22 20:43, Matthew Auld wrote:
If set, force the allocation to be placed in the mappable portion of
I915_MEMORY_CLASS_DEVICE. One big restriction here is that system memory
(i.e I915_MEMORY_CLASS_SYSTEM) must be given as a potential placement for the
object, that way we can always spill
On 5/25/22 20:43, Matthew Auld wrote:
Skip capturing any lmem pages that can't be copied using the CPU. This
in now only best effort on platforms that have small BAR.
Testcase: igt@gem-exec-capture@capture-invisible
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc:
On 5/25/22 20:43, Matthew Auld wrote:
A non-recoverable context must be used if the user wants proper error
capture on discrete platforms. In the future the kernel may want to blit
the contents of some objects when later doing the capture stage.
Testcase: igt@gem_exec_capture@capture-recoverab
On 5/25/22 20:43, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture interactions, including no longer needing
NEEDS_CPU_ACCESS for objects marked for capture. (Tho
On 4/25/22 22:31, Zack Rusin wrote:
From: Zack Rusin
There's no point in explicitly trying to align virtual memory to
facilitate huge page table entries or huge page memory in buffer objects
given that they're not being used.
Transparent hugepages support for vram allocations has been gradua
On 3/14/22 19:20, Ramalingam C wrote:
From: Chris Wilson
In order to keep the context image parser simple, we assume that all
commands follow a similar format. A few, especially not MI commands on
the render engines, have fixed lengths not encoded in a length field.
This caused us to incorrec
On 4/5/22 17:08, Ramalingam C wrote:
When emit_pte doesn't update any PTE with return value as 0, interpret
it as -EINVAL.
v2:
Add missing goto [Thomas]
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
d
On 3/28/22 21:07, Ramalingam C wrote:
Consider the possible round up happened at obj size alignment to
min_page_size during the obj allocation.
Signed-off-by: Ramalingam C
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/selftest_migrate.c | 3 +++
1 file changed, 3 insertio
On 3/21/22 23:44, Ramalingam C wrote:
Handle the src and dst chunk offsets for different instances of the copy
engines.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
b/
Hi, Ram
On 3/21/22 23:44, Ramalingam C wrote:
Xe-HP and latest devices support Flat CCS which reserved a portion of
the device memory to store compression metadata, during the clearing of
device memory buffer object we also need to clear the associated
CCS buffer.
XY_CTRL_SURF_COPY_BLT is a BLT
On 3/21/22 23:44, Ramalingam C wrote:
Move the static calculations out of the loops for copy and clear.
Signed-off-by: Ramalingam C
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 44 -
1 file changed, 21 insertions(+), 23 deletions
Cheng wrote:
+Daniel for additional feedback!
On 2022-03-14 4:06 p.m., Michael Cheng wrote:
On 2022-03-08 10:58 a.m., Lucas De Marchi wrote:
On Tue, Feb 22, 2022 at 08:24:31PM +0100, Thomas Hellström (Intel)
wrote:
Hi, Michael,
On 2/22/22 18:26, Michael Cheng wrote:
This patch removes logi
On 3/3/22 11:02, Matthew Auld wrote:
Currently this will enforce both 2M alignment and padding for any LMEM
pages inserted into the GGTT. However, this was only meant to be applied
to the compact-pt layout with the ppGTT. For the GGTT we can reduce the
alignment and padding to 64K.
Bspec: 4501
Hi, Michael,
On 2/22/22 18:26, Michael Cheng wrote:
This patch removes logic for wbinvd_on_all_cpus and brings in
drm_cache.h. This header has the logic that outputs a warning
when wbinvd_on_all_cpus when its being used on a non-x86 platform.
Signed-off-by: Michael Cheng
Linus has been prett
Hi, Ram,
On 2/7/22 10:37, Ramalingam C wrote:
While evicting the local memory data on flat-ccs capable platform we
need to evict the ccs data associated to the data.
For this, we are
adding extra pages ((size / 256) >> PAGE_SIZE) into the ttm_tt.
To achieve this we are adding a new param
On 1/28/22 09:57, Maarten Lankhorst wrote:
i915_gem_vm_close may take the lock, and we currently have no better way
of handling this. At least for now, allow a path in which holding vm->mutex
is sufficient. This is the case, because the object destroy path will
forcefully take vm->mutex now.
S
On 1/26/22 18:11, Robert Beckett wrote:
On 26/01/2022 13:49, Thomas Hellström (Intel) wrote:
On 1/25/22 20:35, Robert Beckett wrote:
From: Ramalingam C
Add a new platform flag, needs_compact_pt, to mark the requirement of
compact pt layout support for the ppGTT when using 64K GTT pages
On 1/25/22 20:35, Robert Beckett wrote:
From: Matthew Auld
For local-memory objects we need to align the GTT addresses
to 64K, both for the ppgtt and ggtt.
We need to support vm->min_alignment > 4K, depending
on the vm itself and the type of object we are inserting.
With this in mind update
On 1/25/22 20:35, Robert Beckett wrote:
From: Matthew Auld
On discrete platforms like DG2, we need to support a minimum page size
of 64K when dealing with device local-memory. This is quite tricky for
various reasons, so try to document the new implicit uapi for this.
v3: fix typos and less
On 1/25/22 20:35, Robert Beckett wrote:
add test to check handling of misaligned offsets and sizes
v4:
* remove spurious blank lines
* explicitly cast intel_region_id to intel_memory_type in misaligned_pin
Reported-by: kernel test robot
Signed-off-by: Robert Beckett
---
dr
On 1/25/22 20:35, Robert Beckett wrote:
From: Ramalingam C
Add a new platform flag, needs_compact_pt, to mark the requirement of
compact pt layout support for the ppGTT when using 64K GTT pages.
With this flag has_64k_pages will only indicate requirement of 64K
GTT page sizes or larger for d
On 1/24/22 14:03, Christian König wrote:
Drivers should not add containers as shared fences to the dma_resv
object, instead each fence should be added individually.
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
Reviewed-by: Thomas Hellström
Is there any indication that this t
mgblt fb_sys_fops prime_numbers intel_lpss_pci smsc75xx usbnet mii
<4> [184.578349] CPU: 6 PID: 5544 Comm: kms_addfb_basic Not tainted
5.16.0-CI-Patchwork_22006+ #1
<4> [184.578351] Hardware name: Intel Corporation Alder Lake Client
Platform/AlderLake-P DDR4 RVP, BIOS ADL
On 1/20/22 14:27, Christian König wrote:
Consolidate the wrapper functions to check for dma_fence
subclasses in the dma_fence header.
This makes it easier to document and also check the different
requirements for fence containers in the subclasses.
Signed-off-by: Christian König
---
includ
On 1/14/22 14:23, Maarten Lankhorst wrote:
i915_gem_evict_vm will need to be able to evict objects that are
locked by the current ctx. By testing if the current context already
locked the object, we can do this correctly. This allows us to
evict the entire vm even if we already hold some object
On 1/13/22 12:44, Maarten Lankhorst wrote:
i915_gem_evict_vm will need to be able to evict objects that are
locked by the current ctx. By testing if the current context already
locked the object, we can do this correctly. This allows us to
evict the entire vm even if we already hold some object
Hi, Matthew
On 12/15/21 12:07, Matthew Auld wrote:
Add some proper flags for the different modes, and shorten the name to
something more snappy.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Matthew Auld
LGTM.
Reviewed-by: Thomas Hellström
On 12/22/21 16:56, Maarten Lankhorst wrote:
Convert free_work into delayed_work, similar to ttm to allow converting the
blocking lock in __i915_gem_free_objects to a trylock.
Unlike ttm, the object should already be idle, as it's kept alive
by a reference through struct i915_vma->active, which
On 12/8/21 13:59, Matthew Auld wrote:
On Wed, 8 Dec 2021 at 12:43, Thomas Hellström (Intel)
wrote:
Hi,
On 12/7/21 17:51, Ramalingam C wrote:
From: Stuart Summers
Add a new platform flag, has_64k_pages, for platforms supporting
base page sizes of 64k.
Signed-off-by: Stuart Summers
On 12/7/21 17:51, Ramalingam C wrote:
From: Matthew Auld
LMEM should be allocated at 64K granularity, since 4K page support will
eventually be dropped for LMEM when using the PPGTT.
Signed-off-by: Matthew Auld
Signed-off-by: Stuart Summers
Signed-off-by: Ramalingam C
Cc: Joonas Lahtinen
Hi,
On 12/7/21 17:51, Ramalingam C wrote:
From: Stuart Summers
Add a new platform flag, has_64k_pages, for platforms supporting
base page sizes of 64k.
Signed-off-by: Stuart Summers
Signed-off-by: Ramalingam C
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_drv.h | 2
On 12/3/21 16:00, Christian König wrote:
Am 03.12.21 um 15:50 schrieb Thomas Hellström:
On 12/3/21 15:26, Christian König wrote:
[Adding Daniel here as well]
Am 03.12.21 um 15:18 schrieb Thomas Hellström:
[SNIP]
Well that's ok as well. My question is why does this single dma_fence
then sh
On 12/1/21 12:25, Christian König wrote:
Am 01.12.21 um 12:04 schrieb Thomas Hellström (Intel):
On 12/1/21 11:32, Christian König wrote:
Am 01.12.21 um 11:15 schrieb Thomas Hellström (Intel):
[SNIP]
What we could do is to avoid all this by not calling the callback
with the lock held in
On 12/1/21 11:32, Christian König wrote:
Am 01.12.21 um 11:15 schrieb Thomas Hellström (Intel):
[SNIP]
What we could do is to avoid all this by not calling the callback
with the lock held in the first place.
If that's possible that might be a good idea, pls also see below.
The pr
On 12/1/21 09:36, Christian König wrote:
Am 01.12.21 um 09:23 schrieb Thomas Hellström (Intel):
[SNIP]
Jason and I came up with a deep dive iterator for his use case,
but I
think we don't want to use that any more after my dma_resv rework.
In other words when you need to create
On 12/1/21 08:05, Christian König wrote:
Am 30.11.21 um 20:27 schrieb Thomas Hellström:
On 11/30/21 19:12, Thomas Hellström wrote:
On Tue, 2021-11-30 at 16:02 +0100, Christian König wrote:
Am 30.11.21 um 15:35 schrieb Thomas Hellström:
On Tue, 2021-11-30 at 14:26 +0100, Christian König wro
On 9/29/21 10:59, Maarten Lankhorst wrote:
Ensure i915_vma_pin_iomap and vma_unpin are done with dpt->obj lock held.
I don't think there's much of a point in merging intel_dpt_pin() with
intel_pin_fb_obj_dpt(), they touch different objects.
Changes since v1:
- Fix using the wrong pointer to r
see BIOS output.
Add support for the 4321: device number in addition to the
1234: one.
Signed-off-by: H. Peter Anvin (Intel)
---
drivers/gpu/drm/tiny/bochs.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/tiny/bochs.c b/drivers/gpu/drm/tiny/bochs.c
index
Hi, Jason,
A quick question below:
On 7/23/21 7:21 PM, Jason Ekstrand wrote:
From: Thomas Hellström
If our exported dma-bufs are imported by another instance of our driver,
that instance will typically have the imported dma-bufs locked during
dma_buf_map_attachment(). But the exporter also lo
On 8/6/21 1:34 PM, Thomas Hellström (Intel) wrote:
Hi,
On 8/3/21 7:26 PM, Matthew Brost wrote:
On Tue, Aug 03, 2021 at 02:15:13PM +0200, Daniel Vetter wrote:
On Tue, Aug 3, 2021 at 6:53 AM Matthew Brost
wrote:
Minimum set of patches to enable GuC submission on DG1 and enable
it by
On 8/6/21 1:34 PM, Thomas Hellström (Intel) wrote:
Hi,
On 8/3/21 7:26 PM, Matthew Brost wrote:
On Tue, Aug 03, 2021 at 02:15:13PM +0200, Daniel Vetter wrote:
On Tue, Aug 3, 2021 at 6:53 AM Matthew Brost
wrote:
Minimum set of patches to enable GuC submission on DG1 and enable
it by
Hi,
On 8/3/21 7:26 PM, Matthew Brost wrote:
On Tue, Aug 03, 2021 at 02:15:13PM +0200, Daniel Vetter wrote:
On Tue, Aug 3, 2021 at 6:53 AM Matthew Brost wrote:
Minimum set of patches to enable GuC submission on DG1 and enable it by
default.
A little difficult to test as IGTs do not work with
Hi, Christian,
I know you have a lot on your plate, and that the drm community is a bit
lax about following the kernel patch submitting guidelines, but now that
we're also spinning up a number of Intel developers on TTM could we
please make a better effort with cover letters and c
Hi,
On 6/9/21 7:23 PM, Zack Rusin wrote:
The has_dx variable was only set during the initialization which
meant that UPDATE_SUBRESOURCE was never used. We were emulating it
with UPDATE_GB_IMAGE but that's always been a stop-gap. Instead
of has_dx which has been deprecated a long time ago we need
Hi,
On 6/8/21 9:14 AM, Christian König wrote:
Am 08.06.21 um 07:29 schrieb Thomas Hellström (Intel):
Hi,
On 6/7/21 7:59 PM, Christian König wrote:
Am 07.06.21 um 19:58 schrieb Thomas Hellström (Intel):
On 6/7/21 7:54 PM, Christian König wrote:
Am 07.06.21 um 19:06 schrieb Thomas
Hi,
On 6/7/21 7:59 PM, Christian König wrote:
Am 07.06.21 um 19:58 schrieb Thomas Hellström (Intel):
On 6/7/21 7:54 PM, Christian König wrote:
Am 07.06.21 um 19:06 schrieb Thomas Hellström (Intel):
On 6/7/21 6:40 PM, Thomas Hellström (Intel) wrote:
On 6/2/21 12:09 PM, Christian König
On 6/7/21 7:57 PM, Christian König wrote:
After we moved the resource to the ghost the bo->resource pointer needs
to be resetted since the owner of the resource is now the ghost.
s/resetted/reset/
Signed-off-by: Christian König
Reviewed-by: Thomas Hellström
On 6/7/21 7:54 PM, Christian König wrote:
Am 07.06.21 um 19:06 schrieb Thomas Hellström (Intel):
On 6/7/21 6:40 PM, Thomas Hellström (Intel) wrote:
On 6/2/21 12:09 PM, Christian König wrote:
...
@@ -728,14 +728,15 @@ static int ttm_bo_add_move_fence(struct
ttm_buffer_object *bo
On 6/7/21 7:11 PM, Christian König wrote:
The resource is not allocated yet, so no chance that this will work.
Use the placement instead.
Signed-off-by: Christian König
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(
On 6/7/21 6:40 PM, Thomas Hellström (Intel) wrote:
On 6/2/21 12:09 PM, Christian König wrote:
...
@@ -728,14 +728,15 @@ static int ttm_bo_add_move_fence(struct
ttm_buffer_object *bo,
*/
static int ttm_bo_mem_force_space(struct ttm_buffer_object *bo,
const struct
On 6/2/21 12:09 PM, Christian König wrote:
...
@@ -728,14 +728,15 @@ static int ttm_bo_add_move_fence(struct ttm_buffer_object
*bo,
*/
static int ttm_bo_mem_force_space(struct ttm_buffer_object *bo,
const struct ttm_place *place,
-
On 6/7/21 3:58 PM, Christian König wrote:
We discussed if that is really the right approach for quite a while now, but
digging deeper into a bug report on arm turned out that this is actually
horrible broken right now.
The reason for this is that vmf_insert_mixed_prot() always tries to grab
a
Sure. LGTM,
Reviewed-by: Thomas Hellström
On 6/7/21 2:36 PM, Christian König wrote:
Thomas any comments on this?
Is the purpose of this now clear enough?
Thanks,
Christian.
Am 01.06.21 um 14:25 schrieb Christian König:
From: Lang Yu
Sometimes drivers need to use bounce buffers to evict
On 6/7/21 12:40 PM, Christian König wrote:
That somehow got missing.
Signed-off-by: Christian König
Fixes: cb1c81467af3 ("drm/ttm: flip the switch for driver allocated resources
v2")
Reported-by: Thomas Hellström
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/ttm/ttm_range_manag
On 6/7/21 12:37 PM, Christian König wrote:
Am 07.06.21 um 12:15 schrieb Thomas Hellström (Intel):
On 6/2/21 12:09 PM, Christian König wrote:
Instead of both driver and TTM allocating memory finalize embedding the
ttm_resource object as base into the driver backends.
v2: fix typo in vmwgfx
On 6/2/21 12:09 PM, Christian König wrote:
Instead of both driver and TTM allocating memory finalize embedding the
ttm_resource object as base into the driver backends.
v2: fix typo in vmwgfx grid mgr and double init in amdgpu_vram_mgr.c
Signed-off-by: Christian König
Reviewed-by: Matthew Au
Hi, Christian,
It looks like all patches in the series have been reviewed or acked by
Matthew,
and while still a little worried about the final outcome of embedding a
struct ttm_mem_resource, FWIW,
Acked-by: Thomas Hellström
/Thomas
On 6/2/21 12:09 PM, Christian König wrote:
To improve the
On 6/2/21 8:36 PM, Daniel Vetter wrote:
On Wed, Jun 02, 2021 at 02:21:17PM +0200, Thomas Hellström wrote:
On 6/2/21 2:04 PM, Christian König wrote:
Am 02.06.21 um 13:24 schrieb Thomas Hellström (Intel):
[SNIP]
@@ -576,14 +565,10 @@ static void
ttm_bo_mmap_vma_setup(struct
On 6/2/21 8:41 PM, Christian König wrote:
Am 02.06.21 um 17:28 schrieb Thomas Hellström (Intel):
Hi!
On 6/2/21 4:17 PM, Christian König wrote:
Am 02.06.21 um 16:13 schrieb Thomas Hellström (Intel):
On 6/2/21 3:07 PM, Christian König wrote:
Am 02.06.21 um 14:33 schrieb Thomas Hellström
Hi!
On 6/2/21 4:17 PM, Christian König wrote:
Am 02.06.21 um 16:13 schrieb Thomas Hellström (Intel):
On 6/2/21 3:07 PM, Christian König wrote:
Am 02.06.21 um 14:33 schrieb Thomas Hellström (Intel):
On 6/2/21 2:11 PM, Christian König wrote:
Am 02.06.21 um 13:44 schrieb Thomas Hellström
On 6/2/21 3:07 PM, Christian König wrote:
Am 02.06.21 um 14:33 schrieb Thomas Hellström (Intel):
On 6/2/21 2:11 PM, Christian König wrote:
Am 02.06.21 um 13:44 schrieb Thomas Hellström (Intel):
On 6/2/21 12:09 PM, Christian König wrote:
Start with the range manager to make the resource
1 - 100 of 218 matches
Mail list logo
