tatic ttm_bo_global instance")
Cc: Christian König
Good catch, path is Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_device.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c
index 5f31acec3ad76..519deea8e39b7 10
pdate documentation and rebase.
Cc: Harry Wentland
Cc: Anson Jacob
Cc: Christian König
Cc: Hersen Wu
Cc: Aric Cyr
Reported-by: kernel test robot
Signed-off-by: Rodrigo Siqueira
---
drivers/gpu/drm/amd/display/dc/Makefile | 1 +
.../drm/amd/display/dc/dcn20/dcn20_resource.c
anges since V2:
- Make sure that we compile FPU operation only in the context that DCN
is enabled.
Cc: Harry Wentland
Cc: Anson Jacob
Cc: Christian König
Cc: Hersen Wu
Cc: Aric Cyr
Signed-off-by: Rodrigo Siqueira
---
.../gpu/drm/amd/display/amdgpu_dm/Makefile| 4 ++
.../amd/di
abled trigger the ASSERT message.
Changes since V1:
- Remove fp_enable variables
- Rename dc_is_fp_enabled to dc_assert_fp_enabled
- Replace wrong variable type
Cc: Harry Wentland
Cc: Anson Jacob
Cc: Christian König
Cc: Hersen Wu
Cc: Aric Cyr
Signed-off-by: Rodrigo Siqueira
Review
access to
kernel_fpu_begin/end.
Change since V2:
- Christian: Do not use this_cpu_* between get/put_cpu_ptr().
Change since V1:
- Use a better variable names
- Use get_cpu_ptr and put_cpu_ptr to better balance preemption enable
and disable
Cc: Harry Wentland
Cc: Anson Jacob
Cc: Christian König
-by: Christian König
Reviewed-by: Greg Kroah-Hartman
---
Changes in v2:
Updated commit message to clarify that the sysfs files being removed
have not yet merged to upstream Linux and are hence not ABI.
Hi Christian,
I have updated the commit message as per your suggestion. Please do take
another
Am 19.07.21 um 07:19 schrieb guangming@mediatek.com:
From: Guangming Cao
Dmabuf sysfs stat is used for dmabuf info track.
but these file maybe still use after buffer release/detach,
should clear it before buffer release/detach.
Please rebase on current drm-misc-next. The attachment sysfs
Am 20.07.21 um 12:31 schrieb guangming@mediatek.com:
From: Guangming Cao
Dmabuf sysfs stat is used for dmabuf info track.
But these file maybe still in use after buffer released,
should clear it before buffer release.
Signed-off-by: Guangming Cao
Reviewed and pushed to drm-misc-next.
T
rop RCU
v5: handle in and out separately
v6: add missing clear of events
v7: change coding style as suggested by Michel, drop unused variables
Signed-off-by: Christian König
CC: sta...@vger.kernel.org
---
drivers/dma-buf/dma-buf.c | 152 ++
include/linux
Am 20.07.21 um 15:50 schrieb Daniel Vetter:
On Fri, Jul 16, 2021 at 09:14:02AM +0200, Christian König wrote:
Am 16.07.21 um 08:16 schrieb Christoph Hellwig:
The define is entirely unused.
Signed-off-by: Christoph Hellwig
I'm not an expert for this particular code, but at least of
Am 20.07.21 um 16:07 schrieb Daniel Vetter:
On Mon, Jul 19, 2021 at 10:40:57AM +0200, Christian König wrote:
Am 17.07.21 um 22:29 schrieb Rob Clark:
From: Rob Clark
Conversion to gpu_scheduler, and bonus removal of
drm_gem_object_put_locked()
Oh yes please!
If I'm not completely mis
Hi Rob,
Am 20.07.21 um 17:07 schrieb Rob Clark:
From: Rob Clark
Somehow we had neither ->wait() nor dma_fence_signal() calls, and no
one noticed. Oops.
I'm not sure if that is a good idea.
The dma_fence->wait() callback is pretty much deprecated and should not
be used any more.
What ex
tatic ttm_bo_global instance")
Reviewed-by: Christian König
I've just pushed this to drm-misc-fixes.
Thanks,
Christian.
---
drivers/gpu/drm/ttm/ttm_device.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c
inde
Am 20.07.21 um 15:50 schrieb Daniel Vetter:
On Fri, Jul 16, 2021 at 09:14:02AM +0200, Christian König wrote:
Am 16.07.21 um 08:16 schrieb Christoph Hellwig:
The define is entirely unused.
Signed-off-by: Christoph Hellwig
I'm not an expert for this particular code, but at least of
Am 21.07.21 um 11:06 schrieb Daniel Vetter:
On Wed, Jul 21, 2021 at 8:36 AM Christian König
wrote:
Am 20.07.21 um 20:13 schrieb Jason Ekstrand:
If we have a failure, decrement the reference count so that the next
call to ttm_global_init() will actually do something instead of assume
This callback is pretty much deprecated and should not be used by new
implementations.
Clarify that in the documentation as well.
Signed-off-by: Christian König
---
include/linux/dma-fence.h | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/include/linux/dma
That the caller doesn't need to keep a reference is rather
risky and not defensive at all.
Especially dma_buf_poll got that horrible wrong, so better
remove that sentence and also clarify that the callback
might be called in atomic or interrupt context.
Signed-off-by: Christian
Am 21.07.21 um 13:44 schrieb Rodrigo Siqueira:
On 07/20, Christian König wrote:
Am 20.07.21 um 02:49 schrieb Rodrigo Siqueira:
We don't have any mechanism for tracing FPU operations inside the
display core, making the debug work a little bit tricky. This commit
introduces a trace mech
This is a known issue and fixed by:
commit a3a9ee4b5254f212c2adaa8cd8ca03bfa112f49d
Author: Christian König
Date: Wed Jun 9 19:25:56 2021 +0200
drm/nouveau: init the base GEM fields for internal BOs
TTMs buffer objects are based on GEM objects for quite a while
and rely on
Am 21.07.21 um 13:52 schrieb Daniel Vetter:
On Wed, Jul 21, 2021 at 11:21:33AM +0200, Christian König wrote:
That the caller doesn't need to keep a reference is rather
risky and not defensive at all.
Especially dma_buf_poll got that horrible wrong, so better
remove that sentence and
Am 21.07.21 um 15:36 schrieb Daniel Vetter:
On Wed, Jul 21, 2021 at 3:18 PM Christian König
wrote:
Am 21.07.21 um 13:52 schrieb Daniel Vetter:
On Wed, Jul 21, 2021 at 11:21:33AM +0200, Christian König wrote:
That the caller doesn't need to keep a reference is rather
risky and not defe
Am 21.07.21 um 16:37 schrieb Daniel Vetter:
On Wed, Jul 21, 2021 at 3:57 PM Christian König
wrote:
Am 21.07.21 um 15:36 schrieb Daniel Vetter:
On Wed, Jul 21, 2021 at 3:18 PM Christian König
wrote:
Am 21.07.21 um 13:52 schrieb Daniel Vetter:
On Wed, Jul 21, 2021 at 11:21:33AM +0200
PM Rob Clark wrote:
On Tue, Jul 20, 2021 at 11:03 AM Christian König
wrote:
Hi Rob,
Am 20.07.21 um 17:07 schrieb Rob Clark:
From: Rob Clark
Somehow we had neither ->wait() nor dma_fence_signal() calls, and no
one noticed. Oops.
I'm not sure if that is a good idea.
The dma_fen
Turned out that doing this in vmw_ttm_destroy() is to late.
Signed-off-by: Christian König
---
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
b/drivers/gpu/drm/vmwgfx
Turned out that doing this in amdgpu_ttm_backend_destroy() is to late.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu
Turned out that doing this in nouveau_ttm_tt_destroy()/nouveau_sgdma_destroy()
is to late.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c| 3 ++-
drivers/gpu/drm/nouveau/nouveau_sgdma.c | 1 -
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers
Turned out that doing this in radeon_ttm_tt_destroy() is to late.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_ttm.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index
7626168fd132009c79a0457bccc58014abc738f5.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 1 -
drivers/gpu/drm/drm_gem_vram_helper.c | 1 -
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 1 -
drivers/gpu/drm/nouveau/nouveau_bo.c | 1 -
drivers/gpu/drm
Am 22.07.21 um 11:11 schrieb Daniel Vetter:
On Thu, Jul 22, 2021 at 10:55:54AM +0200, Christian König wrote:
It turned out that this is not a good idea at all because it leaves pointers
to freed up system memory pages in the GART tables of the drivers.
Instead change the drivers to unbind
Am 22.07.21 um 11:08 schrieb Daniel Vetter:
[SNIP]
As far as I know wake_up_state() tries to run the thread on the CPU it was
scheduled last, while wait_event_* makes the thread run on the CPU who
issues the wake by default.
And yes I've also noticed this already and it was one of the reason wh
Am 22.07.21 um 12:47 schrieb Daniel Vetter:
On Thu, Jul 22, 2021 at 11:28:01AM +0200, Christian König wrote:
Am 22.07.21 um 11:08 schrieb Daniel Vetter:
[SNIP]
As far as I know wake_up_state() tries to run the thread on the CPU it was
scheduled last, while wait_event_* makes the thread run on
Switch back to using a spinlock again by moving the IOMMU unmap outside
of the locked region.
v2: Add a comment explaining why we need sync_shrinkers().
v3: Drop sync_shrinkers() and use an SRCU instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_pool.c | 45
Doing this in vmw_ttm_destroy() is to late.
It turned out that this is not a good idea at all because it leaves pointers
to freed up system memory pages in the GART tables of the drivers.
Signed-off-by: Christian König
---
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 9 +++--
1 file
Doing this in nouveau_ttm_tt_destroy()/nouveau_sgdma_destroy() is to late.
It turned out that this is not a good idea at all because it leaves pointers
to freed up system memory pages in the GART tables of the drivers.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c
Doing this in radeon_ttm_tt_destroy() is to late.
It turned out that this is not a good idea at all because it leaves pointers
to freed up system memory pages in the GART tables of the drivers.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_ttm.c | 5 ++---
1 file changed, 2
Doing this in amdgpu_ttm_backend_destroy() is to late.
It turned out that this is not a good idea at all because it leaves pointers
to freed up system memory pages in the GART tables of the drivers.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 ++-
1 file
7626168fd132009c79a0457bccc58014abc738f5.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 1 -
drivers/gpu/drm/drm_gem_vram_helper.c | 1 -
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 1 -
drivers/gpu/drm/nouveau/nouveau_bo.c | 1 -
drivers/gpu/drm
Am 23.07.21 um 09:36 schrieb Daniel Vetter:
On Thu, Jul 22, 2021 at 08:40:56PM +0200, Thomas Zimmermann wrote:
Hi
Am 13.07.21 um 22:51 schrieb Daniel Vetter:
[SNIP]
+#ifdef CONFIG_X86
+ if (shmem->map_wc)
+ set_pages_array_wc(pages, obj->size >> PAGE_SHIFT);
+#endif
I cann
Am 23.07.21 um 09:58 schrieb Michel Dänzer:
From: Michel Dänzer
This makes sure we don't hit the
BUG_ON(dmabuf->cb_in.active || dmabuf->cb_out.active);
in dma_buf_release, which could be triggered by user space closing the
dma-buf file description while there are outstanding fence cal
Am 23.07.21 um 10:19 schrieb Michel Dänzer:
On 2021-07-23 10:04 a.m., Christian König wrote:
Am 23.07.21 um 09:58 schrieb Michel Dänzer:
From: Michel Dänzer
This makes sure we don't hit the
BUG_ON(dmabuf->cb_in.active || dmabuf->cb_out.active);
in dma_buf_release, whi
Am 23.07.21 um 10:21 schrieb Daniel Vetter:
On Wed, Jul 14, 2021 at 10:51 AM Christian König
wrote:
Am 13.07.21 um 17:28 schrieb Alex Deucher:
On Tue, Jul 13, 2021 at 2:57 AM Christian König
wrote:
Am 13.07.21 um 00:06 schrieb Felix Kuehling:
KFD Thunk maps invisible VRAM BOs with
Am 23.07.21 um 11:00 schrieb Daniel Vetter:
On Fri, Jul 23, 2021 at 10:33:48AM +0200, Christian König wrote:
Am 23.07.21 um 10:21 schrieb Daniel Vetter:
On Wed, Jul 14, 2021 at 10:51 AM Christian König
wrote:
Am 13.07.21 um 17:28 schrieb Alex Deucher:
On Tue, Jul 13, 2021 at 2:57 AM
Am 23.07.21 um 10:47 schrieb Daniel Vetter:
On Thu, Jul 22, 2021 at 02:41:23PM +0200, Christian König wrote:
Doing this in vmw_ttm_destroy() is to late.
It turned out that this is not a good idea at all because it leaves pointers
to freed up system memory pages in the GART tables of the
Am 23.07.21 um 11:21 schrieb Daniel Vetter:
On Fri, Jul 23, 2021 at 11:13 AM Christian König
wrote:
Am 23.07.21 um 10:47 schrieb Daniel Vetter:
On Thu, Jul 22, 2021 at 02:41:23PM +0200, Christian König wrote:
Doing this in vmw_ttm_destroy() is to late.
It turned out that this is not a good
Am 23.07.21 um 13:21 schrieb Tvrtko Ursulin:
On 15/07/2021 10:18, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Same old work but now rebased and series ending with some DRM docs
proposing
the common specification which should enable nice common userspace
tools to be
written.
For the moment
ending attachments
left to the dmabuf which can show up as the 'memory leak'. This should
at least be reported as the WARN().
Signed-off-by: Charan Teja Reddy
Good idea. I would expect a crash immediately, but from such a backtrace
it is quite hard to tell what the problem is.
Patch is Review
Am 26.07.21 um 02:03 schrieb Dave Airlie:
[SNIP]
But you know, normal human: Only equipped with one head and two hands
and not cloneable.
I'm the same, but I'm not seeing where this problem happens at all, do
we have any backtraces or demos for this?
I've stumbled over this while working on s
Cc: Harry Wentland
Cc: Anson Jacob
Cc: Christian König
Cc: Hersen Wu
Cc: Aric Cyr
Cc: Jun Lei
Cc: Dmytro Laktyushkin
Cc: Qingqing Zhuo
Reported-by: kernel test robot
BTW: The "Reported-by" tag is only used for bug fixes, but since this is
a new series and only the test robot has co
and disable
Cc: Harry Wentland
Cc: Anson Jacob
Cc: Christian König
Cc: Hersen Wu
Cc: Aric Cyr
Cc: Jun Lei
Cc: Dmytro Laktyushkin
Cc: Qingqing Zhuo
Signed-off-by: Rodrigo Siqueira
Reviewed-by: Christian König
---
.../gpu/drm/amd/display/amdgpu_dm/Makefile| 4 +
.../amd/display
Jacob
Cc: Christian König
Cc: Hersen Wu
Cc: Aric Cyr
Cc: Jun Lei
Cc: Dmytro Laktyushkin
Cc: Qingqing Zhuo
Reported-by: kernel test robot
Signed-off-by: Rodrigo Siqueira
Reviewed-by: Christian König
---
.../amd/display/amdgpu_dm/amdgpu_dm_trace.h | 13 ++--
.../gpu/drm/amd/display
tions.
- Make dc_assert_fp_enabled trigger the ASSERT message.
Changes since V1:
- Remove fp_enable variables
- Rename dc_is_fp_enabled to dc_assert_fp_enabled
- Replace wrong variable type
Cc: Harry Wentland
Cc: Anson Jacob
Cc: Christian König
Cc: Hersen Wu
Cc: Aric Cyr
Cc: Jun Lei
Cc: D
Am 27.07.21 um 01:38 schrieb Rob Clark:
From: Rob Clark
Add a way to hint to the fence signaler of an upcoming deadline, such as
vblank, which the fence waiter would prefer not to miss. This is to aid
the fence signaler in making power management decisions, like boosting
frequency as the deadl
Am 27.07.21 um 16:25 schrieb Rob Clark:
On Tue, Jul 27, 2021 at 12:11 AM Christian König
wrote:
Am 27.07.21 um 01:38 schrieb Rob Clark:
From: Rob Clark
Add a way to hint to the fence signaler of an upcoming deadline, such as
vblank, which the fence waiter would prefer not to miss. This is
well, but of hand the patch is
Acked-by: Christian König .
Thanks,
Christian.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 21 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.h | 2 +-
3 files changed, 15 insertions(+), 9
Am 26.07.21 um 22:03 schrieb Dave Airlie:
On Tue, 27 Jul 2021 at 05:35, Christian König
wrote:
Am 26.07.21 um 02:03 schrieb Dave Airlie:
[SNIP]
But you know, normal human: Only equipped with one head and two hands
and not cloneable.
I'm the same, but I'm not seeing where th
Am 27.07.21 um 13:09 schrieb Daniel Vetter:
Adding a few more people to this bikeshed.
On Mon, Jul 12, 2021 at 10:02 PM Daniel Vetter wrote:
@@ -349,6 +367,13 @@ int drm_sched_job_init(struct drm_sched_job *job,
struct drm_sched_entity *entity,
Am 27.07.21 um 17:37 schrieb Rob Clark:
On Tue, Jul 27, 2021 at 8:19 AM Michel Dänzer wrote:
On 2021-07-27 5:12 p.m., Rob Clark wrote:
On Tue, Jul 27, 2021 at 7:50 AM Michel Dänzer wrote:
On 2021-07-27 1:38 a.m., Rob Clark wrote:
From: Rob Clark
Based on discussion from a previous series[
Am 28.07.21 um 09:03 schrieb Christian König:
Am 27.07.21 um 16:25 schrieb Rob Clark:
On Tue, Jul 27, 2021 at 12:11 AM Christian König
wrote:
Am 27.07.21 um 01:38 schrieb Rob Clark:
From: Rob Clark
Add a way to hint to the fence signaler of an upcoming deadline,
such as
vblank, which the
x27;m only one end user of this, but at least from the
high level point of view that makes totally sense to me.
Feel free to add an Acked-by: Christian König .
We could run that through the AMD GPU unit tests, but I fear we actually
don't test on a system with SEV/SME active.
Going to rai
Am 28.07.21 um 14:09 schrieb Daniel Vetter:
On Wed, Jul 28, 2021 at 1:29 PM Christian König
wrote:
Am 27.07.21 um 13:09 schrieb Daniel Vetter:
Adding a few more people to this bikeshed.
On Mon, Jul 12, 2021 at 10:02 PM Daniel Vetter wrote:
@@ -349,6 +367,13 @@ int drm_sched_job_init
Doing this in vmw_ttm_destroy() is to late.
It turned out that this is not a good idea at all because it leaves pointers
to freed up system memory pages in the GART tables of the drivers.
Signed-off-by: Christian König
---
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 9 +++--
1 file
Doing this in amdgpu_ttm_backend_destroy() is to late.
It turned out that this is not a good idea at all because it leaves pointers
to freed up system memory pages in the GART tables of the drivers.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 ++-
1 file
Doing this in nouveau_ttm_tt_destroy()/nouveau_sgdma_destroy() is to late.
It turned out that this is not a good idea at all because it leaves pointers
to freed up system memory pages in the GART tables of the drivers.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c
Doing this in radeon_ttm_tt_destroy() is to late.
It turned out that this is not a good idea at all because it leaves pointers
to freed up system memory pages in the GART tables of the drivers.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_ttm.c | 5 ++---
1 file changed, 2
move the functionality to different
places.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 1 -
drivers/gpu/drm/drm_gem_vram_helper.c | 1 -
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 1 -
drivers/gpu/drm/nouveau/nouveau_bo.c | 1 -
drivers/gp
Am 28.07.21 um 15:08 schrieb Michel Dänzer:
On 2021-07-28 1:36 p.m., Christian König wrote:
Am 27.07.21 um 17:37 schrieb Rob Clark:
On Tue, Jul 27, 2021 at 8:19 AM Michel Dänzer wrote:
On 2021-07-27 5:12 p.m., Rob Clark wrote:
On Tue, Jul 27, 2021 at 7:50 AM Michel Dänzer wrote:
On 2021
Am 28.07.21 um 15:24 schrieb Michel Dänzer:
On 2021-07-28 3:13 p.m., Christian König wrote:
Am 28.07.21 um 15:08 schrieb Michel Dänzer:
On 2021-07-28 1:36 p.m., Christian König wrote:
Am 27.07.21 um 17:37 schrieb Rob Clark:
On Tue, Jul 27, 2021 at 8:19 AM Michel Dänzer wrote:
On 2021-07-27
Am 28.07.21 um 15:57 schrieb Pekka Paalanen:
On Wed, 28 Jul 2021 15:31:41 +0200
Christian König wrote:
Am 28.07.21 um 15:24 schrieb Michel Dänzer:
On 2021-07-28 3:13 p.m., Christian König wrote:
Am 28.07.21 um 15:08 schrieb Michel Dänzer:
On 2021-07-28 1:36 p.m., Christian König wrote:
At
Am 28.07.21 um 17:27 schrieb Rob Clark:
On Wed, Jul 28, 2021 at 6:57 AM Pekka Paalanen wrote:
On Wed, 28 Jul 2021 15:31:41 +0200
Christian König wrote:
Am 28.07.21 um 15:24 schrieb Michel Dänzer:
On 2021-07-28 3:13 p.m., Christian König wrote:
Am 28.07.21 um 15:08 schrieb Michel Dänzer
Am 28.07.21 um 17:15 schrieb Rob Clark:
On Wed, Jul 28, 2021 at 4:37 AM Christian König
wrote:
Am 28.07.21 um 09:03 schrieb Christian König:
Am 27.07.21 um 16:25 schrieb Rob Clark:
On Tue, Jul 27, 2021 at 12:11 AM Christian König
wrote:
Am 27.07.21 um 01:38 schrieb Rob Clark:
From: Rob
Only the DRM GPU scheduler, radeon and amdgpu where using them and they depend
on a non existing config option to actually emit some code.
Nuke them and clean up the dma_fence_signal* return value.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-fence.c | 44
iners.
Signed-off-by: Christian König
---
drivers/dma-buf/Kconfig | 13 --
drivers/dma-buf/Makefile | 1 -
drivers/dma-buf/sw_sync.c| 412 ---
drivers/dma-buf/sync_debug.c | 190
drivers/dma-buf/sync_debug.h | 72 --
5 files ch
Entirely unused.
Signed-off-by: Christian König
---
drivers/dma-buf/Makefile | 2 +-
drivers/dma-buf/seqno-fence.c | 71 --
include/linux/seqno-fence.h | 109 --
3 files changed, 1 insertion(+), 181 deletions(-)
delete mode 100644
Am 29.07.21 um 09:22 schrieb Daniel Vetter:
On Thu, Jul 29, 2021 at 09:03:29AM +0200, Christian König wrote:
Only the DRM GPU scheduler, radeon and amdgpu where using them and they depend
on a non existing config option to actually emit some code.
Nuke them and clean up the dma_fence_signal
Am 29.07.21 um 09:23 schrieb Daniel Vetter:
On Thu, Jul 29, 2021 at 09:03:30AM +0200, Christian König wrote:
As we now knew controlling dma_fence synchronization from userspace is
extremely dangerous and can not only deadlock drivers but trivially also the
whole kernel memory management
Am 29.07.21 um 10:23 schrieb Pekka Paalanen:
On Wed, 28 Jul 2021 16:30:13 +0200
Christian König wrote:
Am 28.07.21 um 15:57 schrieb Pekka Paalanen:
On Wed, 28 Jul 2021 15:31:41 +0200
Christian König wrote:
Am 28.07.21 um 15:24 schrieb Michel Dänzer:
On 2021-07-28 3:13 p.m., Christian
Am 29.07.21 um 11:15 schrieb Pekka Paalanen:
[SNIP]
But how does it then help to wait on the CPU instead?
A compositor does not "wait" literally. It would only check which state
set is ready to be used, and uses the most recent set that is ready. Any
state sets that are not ready are ignored an
Am 29.07.21 um 11:03 schrieb Daniel Vetter:
On Thu, Jul 29, 2021 at 10:38 AM Christian König
wrote:
Am 29.07.21 um 09:23 schrieb Daniel Vetter:
On Thu, Jul 29, 2021 at 09:03:30AM +0200, Christian König wrote:
As we now knew controlling dma_fence synchronization from userspace is
extremely
Am 29.07.21 um 13:00 schrieb Pekka Paalanen:
On Thu, 29 Jul 2021 12:14:18 +0200
Christian König wrote:
Am 29.07.21 um 11:15 schrieb Pekka Paalanen:
If the app happens to be frozen (e.g. some weird bug in fence handling
to make it never ready, or maybe it's just bugged itself and
Am 29.07.21 um 13:59 schrieb Daniel Vetter:
On Thu, Jul 29, 2021 at 12:21 PM Christian König
wrote:
Am 29.07.21 um 11:03 schrieb Daniel Vetter:
On Thu, Jul 29, 2021 at 10:38 AM Christian König
wrote:
Am 29.07.21 um 09:23 schrieb Daniel Vetter:
On Thu, Jul 29, 2021 at 09:03:30AM +0200
Am 29.07.21 um 14:49 schrieb Pekka Paalanen:
On Thu, 29 Jul 2021 13:43:20 +0200
Christian König wrote:
Am 29.07.21 um 13:00 schrieb Pekka Paalanen:
On Thu, 29 Jul 2021 12:14:18 +0200
Christian König wrote:
Am 29.07.21 um 11:15 schrieb Pekka Paalanen:
If the app happens to be frozen
Am 31.07.21 um 10:04 schrieb Tuo Li:
The variable ttm is assigned to the variable gtt, and the variable gtt
is checked in:
if (gtt && gtt->userptr)
This indicates that both ttm and gtt can be NULL.
If so, a null-pointer dereference will occur:
if (ttm->page_flags & TTM_PAGE_FLAG_SG)
Also,
Am 31.07.21 um 10:13 schrieb Tuo Li:
The variable ttm is assigned to the variable gtt, and the variable gtt
is checked in:
if (gtt && gtt->userptr)
This indicates that both ttm and gtt can be NULL.
If so, a null-pointer dereference will occur:
if (ttm->page_flags & TTM_PAGE_FLAG_SG)
Also,
.
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Zhenneng Li
---
drivers/gpu/drm/radeon/evergreen.c | 8
(1):
drm/amd/display: Allow idle optimization based on vblank.
Chengming Gui (1):
drm/amd/amdgpu: set MP1 state to UNLOAD before reload its FW for
vega20/ALDEBARAN
Chris Park (1):
drm/amd/display: Disable MALL when SMU not present
Christian König (5):
drm/amdgpu:
Thanks Ray for pointing this out. Looks like the mail ended up in my
spam folder otherwise.
Apart from that this patch is a really really big NAK. I can't count how
often I had to reject stuff like this!
Using the page reference for TTM pages is illegal and can lead to struct
page corruption
Am 07.04.21 um 09:47 schrieb Daniel Gomez:
On Tue, 6 Apr 2021 at 22:56, Alex Deucher wrote:
On Mon, Mar 22, 2021 at 6:34 AM Christian König
wrote:
Hi Daniel,
Am 22.03.21 um 10:38 schrieb Daniel Gomez:
On Fri, 19 Mar 2021 at 21:29, Felix Kuehling wrote:
This caused a regression in kfdtest
fixed by below patch in this series.
drm/amdgpu: fix NULL pointer dereference
Regards,
Guchun
-Original Message-
From: amd-gfx On Behalf Of Christian
König
Sent: Wednesday, April 7, 2021 2:57 PM
To: Kuehling, Felix ; Deucher, Alexander
; amd-...@lists.freedesktop.org;
dri-devel
:3013:8-16:
WARNING: use scnprintf or sprintf
Signed-off-by: Xuezhi Zhang
Acked-by: Christian König
---
drivers/gpu/drm/amd/pm/amdgpu_pm.c | 58 +++---
1 file changed, 29 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
b/drivers/gpu
Hi,
Am 06.04.21 um 17:27 schrieb Felix Kuehling:
Am 2021-04-06 um 6:38 a.m. schrieb Thomas Zimmermann:
Hi
Am 06.04.21 um 11:35 schrieb Christian König:
Am 06.04.21 um 11:08 schrieb Thomas Zimmermann:
Moving the driver-specific mmap code into a GEM object function allows
for using DRM
Am 08.04.21 um 06:59 schrieb David Stevens:
From: David Stevens
This reverts commit 86bbd89d5da66fe760049ad3f04adc407ec0c4d6.
Using the singleton stub fence in drm_syncobj_assign_null_handle means
that all syncobjs created in an already signaled state or any syncobjs
signaled by userspace will
Am 07.04.21 um 21:04 schrieb Alex Deucher:
On Wed, Apr 7, 2021 at 3:23 AM Dave Airlie wrote:
On Wed, 7 Apr 2021 at 06:54, Alex Deucher wrote:
On Fri, Apr 2, 2021 at 12:22 PM Christian König
wrote:
Hey Alex,
the TTM and scheduler changes should already be in the drm-misc-next
branch (not
Am 08.04.21 um 11:30 schrieb David Stevens:
On Thu, Apr 8, 2021 at 4:03 PM Christian König wrote:
Am 08.04.21 um 06:59 schrieb David Stevens:
From: David Stevens
This reverts commit 86bbd89d5da66fe760049ad3f04adc407ec0c4d6.
Using the singleton stub fence in drm_syncobj_assign_null_handle
Am 08.04.21 um 11:34 schrieb David Stevens:
From: David Stevens
Allocate a new private stub fence in drm_syncobj_assign_null_handle,
instead of using a static stub fence.
When userspace creates a fence with DRM_SYNCOBJ_CREATE_SIGNALED or when
userspace signals a fence via DRM_IOCTL_SYNCOBJ_SIG
anged. Instead, the timestamp returned by SYNC_IOC_FILE_INFO
became the first time anything used the static stub fence, which has no
meaning to userspace.
Signed-off-by: David Stevens
Reviewed-by: Christian König
Should I push this to drm-misc-next or how do you want to upstream it?
T
Am 08.04.21 um 09:13 schrieb Christian König:
Am 07.04.21 um 21:04 schrieb Alex Deucher:
On Wed, Apr 7, 2021 at 3:23 AM Dave Airlie wrote:
On Wed, 7 Apr 2021 at 06:54, Alex Deucher
wrote:
On Fri, Apr 2, 2021 at 12:22 PM Christian König
wrote:
Hey Alex,
the TTM and scheduler changes
Am 08.04.21 um 13:08 schrieb Daniel Vetter:
On Thu, Apr 01, 2021 at 03:54:13PM +0200, Christian König wrote:
Switch back to using a spinlock again by moving the IOMMU unmap outside
of the locked region.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_pool.c | 40
Am 08.04.21 um 13:31 schrieb Daniel Vetter:
On Thu, Apr 08, 2021 at 01:17:32PM +0200, Christian König wrote:
Am 08.04.21 um 13:08 schrieb Daniel Vetter:
On Thu, Apr 01, 2021 at 03:54:13PM +0200, Christian König wrote:
[SNIP]
EXPORT_SYMBOL(unregister_shrinker);
+/**
+ * sync_shrinker - Wait
e the device which those pages
belong to.
Taking and releasing the shrinker semaphore on the write side after
unmapping and freeing all pages should make sure that no shrinker is running in
paralell any more.
Signed-off-by: Christian König
---
include/linux/shrinker.h | 1 +
mm/vmscan.c
Switch back to using a spinlock again by moving the IOMMU unmap outside
of the locked region.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_pool.c | 40 +++---
1 file changed, 18 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c
1 - 100 of 9984 matches
Mail list logo
