Am 20.04.21 um 09:46 schrieb Michal Hocko:
On Tue 20-04-21 09:32:14, Christian König wrote:
Am 20.04.21 um 09:04 schrieb Michal Hocko:
On Mon 19-04-21 18:37:13, Christian König wrote:
Am 19.04.21 um 18:11 schrieb Michal Hocko:
[...]
What I am trying to bring up with NUMA side
Am 20.04.21 um 09:04 schrieb Michal Hocko:
On Mon 19-04-21 18:37:13, Christian König wrote:
Am 19.04.21 um 18:11 schrieb Michal Hocko:
[...]
The question is not whether it is NUMA aware but whether it is useful to
know per-numa data for the purpose the counter is supposed to serve
Am 19.04.21 um 18:11 schrieb Michal Hocko:
On Mon 19-04-21 17:44:13, Christian König wrote:
Am 19.04.21 um 17:19 schrieb peter.enderb...@sony.com:
On 4/19/21 5:00 PM, Michal Hocko wrote:
On Mon 19-04-21 12:41:58, peter.enderb...@sony.com wrote:
On 4/19/21 2:16 PM, Michal Hocko wrote
Am 19.04.21 um 17:19 schrieb peter.enderb...@sony.com:
On 4/19/21 5:00 PM, Michal Hocko wrote:
On Mon 19-04-21 12:41:58, peter.enderb...@sony.com wrote:
On 4/19/21 2:16 PM, Michal Hocko wrote:
On Sat 17-04-21 12:40:32, Peter Enderborg wrote:
This adds a total used dma-buf memory. Details
can
Am 17.04.21 um 16:21 schrieb Muchun Song:
On Sat, Apr 17, 2021 at 9:44 PM wrote:
On 4/17/21 3:07 PM, Muchun Song wrote:
On Sat, Apr 17, 2021 at 6:41 PM Peter Enderborg
wrote:
This adds a total used dma-buf memory. Details
can be found in debugfs, however it is not for everyone
and not
Am 17.04.21 um 13:20 schrieb peter.enderb...@sony.com:
On 4/17/21 12:59 PM, Christian König wrote:
Am 17.04.21 um 12:40 schrieb Peter Enderborg:
This adds a total used dma-buf memory. Details
can be found in debugfs, however it is not for everyone
and not always available. dma-buf are indirect
that have problems.
Signed-off-by: Peter Enderborg
Reviewed-by: Christian König
How do you want to upstream this?
---
drivers/dma-buf/dma-buf.c | 13 +
fs/proc/meminfo.c | 5 -
include/linux/dma-buf.h | 1 +
3 files changed, 18 insertions(+), 1 deletion(-)
diff
stian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: Jerome Glisse
Cc: amd-...@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones
Reviewed-by: Christian König
---
drivers/g
Am 16.04.21 um 16:37 schrieb Lee Jones:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:169: warning: Function parameter or
member 'sched_score' not described in 'amdgpu_ring_init'
Cc: Alex Deucher
Cc: "Christian König"
Cc: David
Am 16.04.21 um 16:37 schrieb Lee Jones:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:311: warning: expecting prototype for
amdgpu_copy_ttm_mem_to_mem(). Prototype was for amdgpu_ttm_copy_mem_to_mem()
instead
Cc: Alex Deucher
Cc: "Christian
:96: warning: expecting prototype for
amdgpu_dummy_page_fini(). Prototype was for amdgpu_gart_dummy_page_fini()
instead
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Nirmoy Das
Cc: amd-...@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Am 16.04.21 um 16:37 schrieb Lee Jones:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:444: warning: Function parameter or
member 'sched_score' not described in 'amdgpu_fence_driver_init_ring'
Cc: Alex Deucher
Cc: "Christian König"
Am 16.04.21 um 16:37 schrieb Lee Jones:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_device.c:1101: warning: This comment starts
with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
Cc: Alex Deucher
Cc: "Christian
Am 16.04.21 um 16:37 schrieb Lee Jones:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/ttm/ttm_tt.c:398: warning: Function parameter or member
'num_pages' not described in 'ttm_tt_mgr_init'
drivers/gpu/drm/ttm/ttm_tt.c:398: warning: Function parameter or member
...@lists.freedesktop.org
Signed-off-by: Lee Jones
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c
index 9b787b3caeb50..a8bec8358350d 100644
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: dri-de...@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Am 16.04.21 um 14:33 schrieb Peter Enderborg:
This adds a total used dma-buf memory. Details
can be found in debugfs, however it is not for everyone
and not always available. dma-buf are indirect allocated by
userspace. So with this value we can monitor and detect
userspace applications that
Am 16.04.21 um 11:37 schrieb Peter Enderborg:
This adds a total used dma-buf memory. Details
can be found in debugfs, however it is not for everyone
and not always available.
Well you are kind of missing the intention here.
I mean knowing this is certainly useful in some case, but you need to
Am 15.04.21 um 22:33 schrieb Andrew Morton:
On Thu, 15 Apr 2021 13:56:24 +0200 "Christian König"
wrote:
@@ -530,6 +525,11 @@ void ttm_pool_fini(struct ttm_pool *pool)
for (j = 0; j < MAX_ORDER; ++j)
ttm_pool_type_fini(>c
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().
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_pool.c | 44 +-
1 file changed, 22 insertions
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 | 10
Am 13.04.21 um 23:19 schrieb Mikhail Gavrilov:
On Tue, 13 Apr 2021 at 12:29, Christian König wrote:
Hi Mikhail,
the crash is a known issue and should be fixed by:
commit f63da9ae7584280582cbc834b20cc18bfb203b14
Author: Philip Yang
Date: Thu Apr 1 00:22:23 2021 -0400
drm/amdgpu
Hi Mikhail,
the crash is a known issue and should be fixed by:
commit f63da9ae7584280582cbc834b20cc18bfb203b14
Author: Philip Yang
Date: Thu Apr 1 00:22:23 2021 -0400
drm/amdgpu: reserve fence slot to update page table
But that an userspace application can cause a page fault is
,
Christian.
Am 07.04.21 um 20:06 schrieb Mikhail Gavrilov:
On Wed, 7 Apr 2021 at 15:46, Christian König
wrote:
What hardware are you using
$ inxi -bM
System:Host: fedora Kernel: 5.12.0-0.rc6.184.fc35.x86_64+debug
x86_64 bits: 64 Desktop: GNOME 40.0
Distro: Fedora release 35 (Rawhide
Am 01.04.21 um 03:59 schrieb Bernard:
From: "Christian König"
Date: 2021-03-31 21:15:22
To: Bernard Zhao ,Huang Rui ,David Airlie
,Daniel Vetter
,dri-de...@lists.freedesktop.org,linux-kernel@vger.kernel.org
Cc: opensource.ker...@vivo.com
Subject: Re: [PATCH] drm/ttm: cleanup co
Am 09.04.21 um 13:00 schrieb Vlastimil Babka:
On 4/9/21 9:17 AM, Christian König wrote:
To be able to switch to a spinlock and reduce lock contention in the TTM
shrinker we don't want to hold a mutex while unmapping and freeing pages
from the pool.
Does using spinlock instead of mutex really
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 | 10
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
. 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?
Thanks
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
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 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
: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
sizeof(hop));
ba4e7d973dd09 (Thomas Hellstrom 2009-06-10 15:20:19 +0200 1476)
ba4e7d973dd09 (Thomas Hellstrom 2009-06-10 15:20:19 +0200 1477)
evict_mem = bo->mem;
ba4e7d973dd09 (Thomas Hellstrom 2009-06-10 15:20:19 +0200 1478)
evict_mem.mm_node = NULL;
ce65b874001d7 (Christian K
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
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
Hi Qu,
Am 06.04.21 um 08:04 schrieb Qu Huang:
Hi Christian,
On 2021/4/3 16:49, Christian König wrote:
Hi Qu,
Am 03.04.21 um 07:08 schrieb Qu Huang:
Hi Christian,
On 2021/4/3 0:25, Christian König wrote:
Hi Qu,
Am 02.04.21 um 05:18 schrieb Qu Huang:
Before dma_resv_lock(bo->base.r
Hi Qu,
Am 03.04.21 um 07:08 schrieb Qu Huang:
Hi Christian,
On 2021/4/3 0:25, Christian König wrote:
Hi Qu,
Am 02.04.21 um 05:18 schrieb Qu Huang:
Before dma_resv_lock(bo->base.resv, NULL) in
amdgpu_bo_release_notify(),
the bo->base.resv lock may be held by ttm_mem_evict
Hi Qu,
Am 02.04.21 um 05:18 schrieb Qu Huang:
Before dma_resv_lock(bo->base.resv, NULL) in amdgpu_bo_release_notify(),
the bo->base.resv lock may be held by ttm_mem_evict_first(),
That can't happen since when bo_release_notify is called the BO has not
more references and is therefore
Am 24.10.20 um 02:47 schrieb Rasmus Villemoes:
Keep sparse happy by preserving the __user annotation when casting.
Reported-by: kernel test robot
Signed-off-by: Rasmus Villemoes
Reviewed-by: Christian König
Going over old patches and stumbled over that once.
Alex did you missed to pick
Am 31.03.21 um 15:12 schrieb Bernard Zhao:
Fix sparse warning:
drivers/gpu/drm/ttm/ttm_bo.c:52:1: warning: symbol 'ttm_global_mutex' was not
declared. Should it be static?
drivers/gpu/drm/ttm/ttm_bo.c:53:10: warning: symbol 'ttm_bo_glob_use_count' was
not declared. Should it be static?
Reviewed-by: Christian König for the entire
series.
Alex will probably pick them up for the next feature pull request.
Regards,
Christian.
Am 30.03.21 um 17:33 schrieb Xℹ Ruoyao:
In AMDGPU driver, the bo mapping should always align to CPU page or
the page table is corrupted.
The first
Am 30.03.21 um 15:23 schrieb Dan Horák:
On Tue, 30 Mar 2021 21:09:12 +0800
Xi Ruoyao wrote:
On 2021-03-30 21:02 +0800, Xi Ruoyao wrote:
On 2021-03-30 14:55 +0200, Christian König wrote:
I rather see this as a kernel bug. Can you test if this code fragment
fixes your issue:
diff --git
Am 30.03.21 um 15:00 schrieb Dan Horák:
On Tue, 30 Mar 2021 14:55:01 +0200
Christian König wrote:
Am 30.03.21 um 14:04 schrieb Xi Ruoyao:
On 2021-03-30 03:40 +0800, Xi Ruoyao wrote:
On 2021-03-29 21:36 +0200, Christian König wrote:
Am 29.03.21 um 21:27 schrieb Xi Ruoyao:
Hi Christian,
I
Am 30.03.21 um 14:04 schrieb Xi Ruoyao:
On 2021-03-30 03:40 +0800, Xi Ruoyao wrote:
On 2021-03-29 21:36 +0200, Christian König wrote:
Am 29.03.21 um 21:27 schrieb Xi Ruoyao:
Hi Christian,
I don't think there is any constraint implemented to ensure `num_entries %
AMDGPU_GPU_PAGES_IN_CPU_PAGE
On 2021-03-30 02:30 +0800, Xi Ruoyao wrote:
On 2021-03-30 02:21 +0800, Xi Ruoyao wrote:
On 2021-03-29 20:10 +0200, Christian König wrote:
You need to identify the root cause of this, most likely start or last
are not a multiple of AMDGPU_GPU_PAGES_IN_CPU_PAGE.
I printk'ed t
Am 29.03.21 um 20:08 schrieb Xi Ruoyao:
On 2021-03-29 20:04 +0200, Christian König wrote:
Am 29.03.21 um 19:53 schrieb Xℹ Ruoyao:
If the initial value of `num_entires` (calculated at line 1654) is not
an integral multiple of `AMDGPU_GPU_PAGES_IN_CPU_PAGE`, in line 1681 a
value greater than
Am 29.03.21 um 19:53 schrieb Xℹ Ruoyao:
If the initial value of `num_entires` (calculated at line 1654) is not
an integral multiple of `AMDGPU_GPU_PAGES_IN_CPU_PAGE`, in line 1681 a
value greater than the initial value will be assigned to it. That causes
`start > last + 1` after line 1708.
a1f091f8ef2b680a5184db065527612247cb4cae
Author: Christian König
Date: Tue Oct 6 17:26:42 2020 +0200
drm/ttm: switch to per device LRU lock
Instead of having a global lock for potentially less contention.
The analysis is as follows:
617 int ttm_mem_evict_first(struct ttm_device *bdev,
618
Am 25.03.21 um 14:33 schrieb Jason Gunthorpe:
On Thu, Mar 25, 2021 at 02:26:50PM +0100, Christian König wrote:
Am 25.03.21 um 14:17 schrieb Jason Gunthorpe:
On Thu, Mar 25, 2021 at 02:05:14PM +0100, Christian König wrote:
Am 25.03.21 um 13:42 schrieb Jason Gunthorpe:
On Thu, Mar 25, 2021
Am 25.03.21 um 14:17 schrieb Jason Gunthorpe:
On Thu, Mar 25, 2021 at 02:05:14PM +0100, Christian König wrote:
Am 25.03.21 um 13:42 schrieb Jason Gunthorpe:
On Thu, Mar 25, 2021 at 01:09:14PM +0100, Christian König wrote:
Am 25.03.21 um 13:01 schrieb Jason Gunthorpe:
On Thu, Mar 25, 2021
Am 25.03.21 um 13:42 schrieb Jason Gunthorpe:
On Thu, Mar 25, 2021 at 01:09:14PM +0100, Christian König wrote:
Am 25.03.21 um 13:01 schrieb Jason Gunthorpe:
On Thu, Mar 25, 2021 at 12:53:15PM +0100, Thomas Hellström (Intel) wrote:
Nope. The point here was that in this case, to make sure
Am 25.03.21 um 13:36 schrieb Thomas Hellström (Intel):
On 3/25/21 1:09 PM, Christian König wrote:
Am 25.03.21 um 13:01 schrieb Jason Gunthorpe:
On Thu, Mar 25, 2021 at 12:53:15PM +0100, Thomas Hellström (Intel)
wrote:
Nope. The point here was that in this case, to make sure mmap uses
Am 25.03.21 um 13:01 schrieb Jason Gunthorpe:
On Thu, Mar 25, 2021 at 12:53:15PM +0100, Thomas Hellström (Intel) wrote:
Nope. The point here was that in this case, to make sure mmap uses the
correct VA to give us a reasonable chance of alignement, the driver might
need to be aware of and do
Am 25.03.21 um 09:50 schrieb Greg Kroah-Hartman:
On Thu, Mar 25, 2021 at 09:14:59AM +0100, Christian König wrote:
Hi Greg,
sorry just realized this after users started to complain. This patch
shouldn't been backported to 5.11 in the first place.
The warning itself is a good idea, but we also
Hi,
Am 25.03.21 um 09:17 schrieb Oleksandr Natalenko:
Hello.
On Thu, Mar 25, 2021 at 07:57:33AM +0200, Ilkka Prusi wrote:
On 24.3.2021 16.16, Chris Rankin wrote:
Hi,
Theee warnings ares not present in my dmesg log from 5.11.8:
[ 43.390159] [ cut here ]
[
Am 25.03.21 um 08:48 schrieb Thomas Hellström (Intel):
On 3/25/21 12:14 AM, Jason Gunthorpe wrote:
On Wed, Mar 24, 2021 at 09:07:53PM +0100, Thomas Hellström (Intel)
wrote:
On 3/24/21 7:31 PM, Christian König wrote:
Am 24.03.21 um 17:38 schrieb Jason Gunthorpe:
On Wed, Mar 24, 2021 at 04
a problem for ttm, but very likely a driver bug and
pretty big time confusing for reviewing code.
So warn about it, both at cleanup time (so we catch these for sure)
and at pin/unpin time (so we know who's the culprit).
Reviewed-by: Huang Rui
Reviewed-by: Christian König
Signed-off-by: Daniel
Am 25.03.21 um 00:14 schrieb Jason Gunthorpe:
On Wed, Mar 24, 2021 at 09:07:53PM +0100, Thomas Hellström (Intel) wrote:
On 3/24/21 7:31 PM, Christian König wrote:
Am 24.03.21 um 17:38 schrieb Jason Gunthorpe:
On Wed, Mar 24, 2021 at 04:50:14PM +0100, Thomas Hellström (Intel)
wrote:
On 3/24
Am 24.03.21 um 18:21 schrieb Jason Gunthorpe:
On Mon, Mar 15, 2021 at 10:27:08AM -0600, Logan Gunthorpe wrote:
In this case the WARN_ON is just to guard against misuse of the
function. It should never happen unless a developer changes the code in
a way that is incorrect. So I think that's the
Am 24.03.21 um 17:38 schrieb Jason Gunthorpe:
On Wed, Mar 24, 2021 at 04:50:14PM +0100, Thomas Hellström (Intel) wrote:
On 3/24/21 2:48 PM, Jason Gunthorpe wrote:
On Wed, Mar 24, 2021 at 02:35:38PM +0100, Thomas Hellström (Intel) wrote:
In an ideal world the creation/destruction of page
Am 22.03.21 um 09:13 schrieb Thomas Hellström (Intel):
Hi!
On 3/22/21 8:47 AM, Christian König wrote:
Am 21.03.21 um 19:45 schrieb Thomas Hellström (Intel):
To block fast gup we need to make sure TTM ptes are always special.
With MIXEDMAP we, on architectures that don't support pte_special
Am 22.03.21 um 13:02 schrieb Wan Jiabing:
amdgpu_hdp.h has been included at line 91, so remove
the duplicate include.
Signed-off-by: Wan Jiabing
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd
, the same way a previous patch did for
another instance of the same warning.
Fixes: 0b437e64e0af ("drm/amdgpu: remove h from printk format specifier")
Signed-off-by: Arnd Bergmann
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 2 +-
1 file changed, 1
_userptr if memory hasn't been allocated.
Any other ideas?
Regards,
Daniel
Reverting this patch fixes the problem for me.
Regards,
Felix
On 2021-03-18 10:57 p.m., Alex Deucher wrote:
Applied. Thanks!
Alex
On Thu, Mar 18, 2021 at 5:00 AM Koenig, Christian
wrote:
BOs in the first place.
But either way this patch is Reviewed-by: Christian König
.
Thanks,
Christian.
There was previously a comment in the code that WC mappings together
with x86 PAT + PFNMAP was bad for performance. However from looking at
vmf_insert_mixed() it looks like in the current
]
[2.169224] radeon_driver_unload_kms+0x44/0xa0 [radeon]
[2.169534] radeon_driver_load_kms+0x174/0x210 [radeon]
[2.169843] drm_dev_register+0xd9/0x1c0 [drm]
[2.170104] radeon_pci_probe+0x117/0x1a0 [radeon]
Suggested-by: Christian König
Signed-off-by: Tong Zhang
Reviewed
Am 20.03.21 um 21:10 schrieb Tong Zhang:
TTM_PL_VRAM may not initialized at all when calling
radeon_bo_evict_vram(). We need to check before doing eviction.
[2.160837] BUG: kernel NULL pointer dereference, address: 0020
[2.161212] #PF: supervisor read access in kernel
‘calculate_bandwidth’:
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:2016:1:
warning: the frame size of 1216 bytes is larger than 1024 bytes
[-Wframe-larger-than=]
Cc: Harry Wentland
Cc: Leo Li
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Coli
General question for the audience: Is there any way to silence the build
bot here?
This is a well known false positive.
Regards,
Christian.
Am 18.03.21 um 19:13 schrieb kernel test robot:
Hi "Christian,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
Am 19.03.21 um 03:58 schrieb Wang Qing:
Using wake_up_process() is more simpler and friendly,
and it is more convenient for analysis and statistics
Signed-off-by: Wang Qing
Reviewed-by: Christian König
Should I pick it up or do you want to push it through some other tree
than DRM
Am 17.03.21 um 17:08 schrieb Daniel Gomez:
If userptr pages have been pinned but not bounded,
they remain uncleared.
Signed-off-by: Daniel Gomez
Good catch, not sure if that can ever happen in practice but better save
than sorry.
Reviewed-by: Christian König
---
drivers/gpu/drm/amd
Hi Mike,
I'm pretty sure your bisection is a bit off.
The patch you mentioned is completely unrelated to Nouveau and I think
the code path in question is not even used by this driver.
Regards,
Christian.
Am 14.03.21 um 05:48 schrieb Mike Galbraith:
This little bugger bisected to...
Reported-by: Arnd Bergmann
Signed-off-by: Felix Kuehling
Ping. Can I get an R-b for this patch.
Reviewed-by: Christian König
Thanks,
Felix
---
drivers/gpu/drm/amd/amdkfd/kfd_iommu.c | 6 ++
drivers/gpu/drm/amd/amdkfd/kfd_iommu.h | 9 +++--
2 files changed, 13 insertions(+), 2
Am 09.03.21 um 18:59 schrieb Alex Deucher:
On Tue, Mar 9, 2021 at 12:55 PM Jean-Philippe Brucker
wrote:
Hi Felix,
On Tue, Mar 09, 2021 at 11:30:19AM -0500, Felix Kuehling wrote:
I think the proper fix would be to not rely on custom hooks into a particular
IOMMU driver, but to instead ensure
Am 08.03.21 um 21:02 schrieb Felix Kuehling:
Am 2021-03-08 um 2:33 p.m. schrieb Arnd Bergmann:
On Mon, Mar 8, 2021 at 8:11 PM Felix Kuehling wrote:
Am 2021-03-08 um 2:05 p.m. schrieb Arnd Bergmann:
On Mon, Mar 8, 2021 at 5:24 PM Felix Kuehling wrote:
The driver build should work without
ng
process state, allow accessing fdinfo under PTRACE_MODE_READ_FSCRED.
Suggested-by: Jann Horn
Signed-off-by: Kalesh Singh
Both patches are Acked-by: Christian König
---
Hi everyone,
The initial posting of this patch can be found at [1].
I didn't receive any feedback last time, so resending h
The radeon warning is trivial to fix, going to send out a patch in a few
moments.
Regards,
Christian.
Am 08.03.21 um 13:14 schrieb Christophe Leroy:
+Evgeniy for W1 Dallas
+Alex & Christian for RADEON
Le 07/03/2021 à 11:23, kernel test robot a écrit :
Hi Christophe,
I love your patch!
Am 05.03.21 um 16:31 schrieb Sasha Levin:
On Fri, Mar 05, 2021 at 03:27:00PM +, Deucher, Alexander wrote:
Not sure if Sasha picked that up or not. Would need to check that.
If it's not, this patch should be dropped.
Yes, it went in via autosel. I can drop it if it's not needed.
IIRC
into
mmSPI_WCL_PIPE_PERCENT_GFX register. Enable only one high priority
compute queue to avoid race condition between multiple high priority
compute queues writing that register simultaneously.
Signed-off-by: Nirmoy Das
Acked-by: Christian König
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha
-by: Christian König
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 15 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 2 +-
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 6 ++
drivers/gpu/drm/amd/amdgpu
Am 05.03.21 um 00:20 schrieb John Stultz:
This patch provides infrastructure for deferring buffer frees.
This is a feature ION provided which when used with some form
of a page pool, provides a nice performance boost in an
allocation microbenchmark. The reason it helps is it allows the
Am 05.03.21 um 00:20 schrieb John Stultz:
This patch reworks the ttm_pool logic to utilize the recently
added drm_page_pool code.
This adds drm_page_pool structures to the ttm_pool_type
structures, and then removes all the ttm_pool_type shrinker
logic (as its handled in the drm_page_pool
ROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors: Christian König, John Stultz
+ */
+
+#include
+#include
+#include
+#include
+
+static unsigned long page_pool_size;
+
+MODULE_PARM_DESC(page_pool_size, "Number of pages in th
Am 03.03.21 um 14:20 schrieb Thomas Gleixner:
From: Thomas Gleixner
There is no reason to disable pagefaults and preemption as a side effect of
kmap_atomic_prot().
Use kmap_local_page_prot() instead and document the reasoning for the
mapping usage with the given pgprot.
Remove the NULL
I also already send a patch to the list to mitigate the warnings into a
WARN_ON_ONCE().
Christian.
Am 04.03.21 um 08:42 schrieb Thomas Zimmermann:
(cc'ing Gerd)
This might be related to the recent clean-up patches for the BO
handling in qxl.
Am 03.03.21 um 16:07 schrieb Petr Mladek:
On
Hi Petr,
yes that is a known bug in qxl and yes the patch you mentioned makes it
worse.
Going to reduce the warning into a WARN_ON_ONCE().
Regards,
Christian.
Am 03.03.21 um 15:34 schrieb Petr Mladek:
Hi,
the following warning is filling my kernel log buffer
with 5.12-rc1+ kernels:
[
Cc: Leo Li
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Colin Ian King
Cc: amd-...@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
.../gpu/drm/amd/display/dc/calcs/dce_calcs.c | 29 ---
1 fi
n King
Reviewed-by: Christian König
Let's hope that this doesn't break UAPI.
Christian.
---
drivers/gpu/drm/radeon/radeon_kms.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index 2479d6ab7a36..5
Am 23.02.21 um 18:31 schrieb Alex Deucher:
On Wed, Feb 10, 2021 at 8:14 AM Daniel Vetter wrote:
On Wed, Feb 10, 2021 at 08:45:56AM +0100, Christian König wrote:
Reviewed-by: Christian König for the series.
Smash it into -misc?
@Christian Koenig did these ever land? I don't see them in drm
Well coding style clean ups are usually welcome, but not necessarily one
by one.
We can probably merge this if you clean up all checkpatch.pl warnings in
the whole file.
Christian.
Am 26.02.21 um 07:05 schrieb wangjingyu:
drm_property_create_range(rdev->ddev, 0 , "coherent", 0, 1);
n I realized that this totally makes sense.
We should probably have the same for radeon as well.
Apart from that the patch is Acked-by: Christian König
select IOMMU_API
select FW_LOADER
select DRM_KMS_HELPER
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/Kbuild
b
Am 23.02.21 um 09:54 schrieb Jiapeng Chong:
Fix the following sparse warning:
drivers/gpu/drm/ttm/ttm_bo.c:53:10: warning: symbol
'ttm_bo_glob_use_count' was not declared. Should it be static?
IIRC we already have a patch for this on the mailing list and the mutex
can be static as well.
Am 16.02.21 um 11:13 schrieb Peter Zijlstra:
On Tue, Feb 16, 2021 at 10:29:00AM +0100, Daniel Vetter wrote:
On Tue, Feb 16, 2021 at 09:21:46AM +0100, Christian König wrote:
The last user went away in the 5.11 cycle.
Signed-off-by: Christian König
Nice.
Reviewed-by: Daniel Vetter
I
The last user went away in the 5.11 cycle.
Signed-off-by: Christian König
---
include/linux/mutex.h | 25 -
kernel/locking/mutex.c | 10 --
scripts/checkpatch.pl | 6 --
3 files changed, 41 deletions(-)
diff --git a/include/linux/mutex.h b/include/linux
Am 15.02.21 um 15:41 schrieb David Laight:
From: Christian König
Sent: 15 February 2021 12:05
...
Snooping the CPU caches introduces some extra latency, so what can
happen is that the response to the PCIe read comes to late for the
scanout. The result is an underflow and flickering
-by: Christian
König to the series.
But looking at the use cases for this, wouldn't it make more sense to
teach kprintf some new format modifier for this?
Christian.
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c| 6 +-
drivers/gpu/drm/i915/i915_utils.h| 6
Am 15.02.21 um 13:16 schrieb Lucas Stach:
[SNIP]
Userspace components can then of course tell the exporter what the
importer needs, but validation if that stuff is correct and doesn't
crash the system must happen in the kernel.
What exactly do you mean by "scanout requires non-coherent
Am 15.02.21 um 13:00 schrieb Thomas Zimmermann:
Hi
Am 15.02.21 um 10:49 schrieb Thomas Zimmermann:
Hi
Am 15.02.21 um 09:58 schrieb Christian König:
Hi guys,
we are currently working an Freesync and direct scan out from system
memory on AMD APUs in A+A laptops.
On problem we stumbled
Am 15.02.21 um 12:53 schrieb Lucas Stach:
Am Montag, dem 15.02.2021 um 10:34 +0100 schrieb Christian König:
Am 15.02.21 um 10:06 schrieb Simon Ser:
On Monday, February 15th, 2021 at 9:58 AM, Christian König
wrote:
we are currently working an Freesync and direct scan out from system
memory
1 - 100 of 1497 matches
Mail list logo
