On Fri, Apr 16, 2021 at 12:48 AM David Niklas wrote:
>
> Hey,
>
> I forgot to give you a bug tracker in case you want one.
> Here: https://bugzilla.kernel.org/show_bug.cgi?id=212691
I've followed up on the bug report. Please take a look there.
Alex
>
> Thanks,
> David
>
Tracking devices, process info and fence info using
/proc/pid/fdinfo
Signed-off-by: David M Nieto
Signed-off-by: Roy Sun
---
drivers/gpu/drm/amd/amdgpu/Makefile| 2 +
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c| 61 ++
Update the timestamp of scheduled fence on HW
completion of the previous fences
This allow more accurate tracking of the fence
execution in HW
Signed-off-by: David M Nieto
Signed-off-by: Roy Sun
---
drivers/gpu/drm/scheduler/sched_main.c | 11 +--
1 file changed, 9 insertions(+), 2
Hey,
I forgot to give you a bug tracker in case you want one.
Here: https://bugzilla.kernel.org/show_bug.cgi?id=212691
Thanks,
David
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Hello,
I have tested and found this bug to occur on the specified bisected
commit through Linux Kernel version 5.11.12.
I am running Devuan (Debian) Linux with a hand created kernel config. I'm
attaching it.
I've bisected the kernel and found the broken commit. Here's how I got
there in case
[AMD Public Use]
Add debugfs interface to read region allocated for FW private buffer
Signed-off-by: Lijo Lazar
Suggested-by: Alex Deucher
Reviewed-by: Christian König
Reviewed-by: Kevin Wang
---
drivers/gpu/drm/amd/pm/amdgpu_pm.c | 44 ++
1 file changed, 44
[AMD Public Use]
v1: Add new interface to get FW private buffer details
v2: Drop domain check
v3: Use amdgpu_bo_kmap to get cpu address
Signed-off-by: Lijo Lazar
Suggested-by: Alex Deucher
Reviewed-by: Christian König
Reviewed-by: Kevin Wang
---
.../gpu/drm/amd/include/kgd_pp_interface.h
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Alex Deucher
From: Huang, Ray
Sent: Thursday, April 15, 2021 11:22 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Koenig, Christian
; Yu, Lang ; Huang, Ray
Subject: [PATCH]
The tmz function are verified on renoir chips as well. So enable it by
default.
Signed-off-by: Huang Rui
Tested-by: Lang Yu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
[AMD Official Use Only - Internal Distribution Only]
Hi Felix
As we discussed in the meeting, do you have any other questions?
--
BW
Pengju Zhou
-Original Message-
From: Kuehling, Felix
Sent: Thursday, April 15,
In poison progogate mode, when driver receive the edc error interrupt
from SQ, driver should kill the process by pasid which is using the
poison data, and then trigger GPU reset.
Signed-off-by: Dennis Li
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c
Am 2021-04-15 um 5:43 p.m. schrieb Philip Yang:
> HMM migration alloc sizeof(struct page) on system memory for each VRAM
> page, it is 1GB system memory reserved for 64GB VRAM. To avoid
> application OOM, increase system memory used size based on VRAM size of
> all GPUs, then application alloc
On 2021-04-14 10:40 p.m., Felix
Kuehling wrote:
amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu needs the drm_priv to allow mmap
to access the BO through the corresponding file descriptor. The VM can
also be extracted from drm_priv, so drm_priv can replace the vm
HMM migration alloc sizeof(struct page) on system memory for each VRAM
page, it is 1GB system memory reserved for 64GB VRAM. To avoid
application OOM, increase system memory used size based on VRAM size of
all GPUs, then application alloc memory will fail if system memory usage
reach the limit.
Reviewed-by: Bas Nieuwenhuizen
Tested-by: Bas Nieuwenhuizen
(Checked that Weston on SIENNA_CICHLID now gets DCC)
Thanks!
On Thu, Apr 15, 2021 at 7:35 PM Qingqing Zhuo wrote:
> [Why]
> Current list supports modifiers that have DCC_MAX_COMPRESSED_BLOCK
> set to AMD_FMT_MOD_DCC_BLOCK_128B,
On 2021-04-15 1:55 p.m., Shashank Sharma wrote:
This patch checks the return value of the function
dc_link_add_remote_sink before using it. This was causing
a crash during consecutive hotplugs of DP MST displays.
Cc: Harry Wentland
Signed-off-by: Shashank Sharma
Reviewed-by: Harry Wentland
This patch checks the return value of the function
dc_link_add_remote_sink before using it. This was causing
a crash during consecutive hotplugs of DP MST displays.
Cc: Harry Wentland
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 5 +
1
[AMD Public Use]
Updated and sent. Your review would be appreciated!
Thanks,
Lillian
From: Bas Nieuwenhuizen
Sent: Thursday, April 15, 2021 12:27 PM
To: Zhuo, Qingqing
Cc: amd-gfx mailing list ; Mark Yacoub
; Deucher, Alexander ;
Wheeler, Daniel ; Siqueira, Rodrigo
; Kazlauskas, Nicholas
[Why]
Current list supports modifiers that have DCC_MAX_COMPRESSED_BLOCK
set to AMD_FMT_MOD_DCC_BLOCK_128B, while AMD_FMT_MOD_DCC_BLOCK_64B
is used instead by userspace.
[How]
Replace AMD_FMT_MOD_DCC_BLOCK_128B with AMD_FMT_MOD_DCC_BLOCK_64B
for modifiers with DCC supported.
Fixes: 91e54fd70c6a
Applied. Thanks!
Alex
On Thu, Apr 15, 2021 at 5:30 AM Yang Li wrote:
>
> Kernel test robot throws below warning ->
>
> smatch warnings:
> drivers/gpu/drm/radeon/si.c:4514 si_vm_packet3_cp_dma_check() warn:
> inconsistent indenting
>
> Fixed the inconsistent indenting.
>
> Reported-by: Abaci
Btw please add a fixes tag so it gets directed to stable releases.
Thanks!
On Thu, Apr 15, 2021, 6:06 PM Zhuo, Qingqing wrote:
> [AMD Public Use]
>
>
>
> Inline.
>
>
>
> *From:* Bas Nieuwenhuizen
> *Sent:* Thursday, April 15, 2021 7:26 AM
> *To:* Zhuo, Qingqing
> *Cc:* amd-gfx mailing list ;
Applied. Thanks!
Alex
On Wed, Apr 14, 2021 at 1:59 AM Dan Carpenter wrote:
>
> We should return -EINVAL instead of success if the "limit" is too high.
>
> Fixes: e098bc9612c2 ("drm/amd/pm: optimize the power related source code
> layout")
> Signed-off-by: Dan Carpenter
> ---
>
On Wed, Apr 14, 2021 at 1:59 AM Dan Carpenter wrote:
>
> If the kmemdup() fails then this should return a negative error code
> but it currently returns success
>
> Fixes: b4a7db71ea06 ("drm/amdgpu: add per device user friendly xgmi events
> for vega20")
> Signed-off-by: Dan Carpenter
Applied.
On Mon, Apr 12, 2021 at 11:26 PM Tian Tao wrote:
>
> The value of pipe_id and queue_id are not used under certain
> circumstances, so just delete.
>
> Signed-off-by: Tian Tao
Applied. Thanks!
Alex
> ---
> drivers/gpu/drm/radeon/cik.c | 4
> 1 file changed, 4 deletions(-)
>
> diff
[AMD Public Use]
Inline.
From: Bas Nieuwenhuizen
Sent: Thursday, April 15, 2021 7:26 AM
To: Zhuo, Qingqing
Cc: amd-gfx mailing list ; Mark Yacoub
; Deucher, Alexander ;
Wheeler, Daniel ; Siqueira, Rodrigo
; Kazlauskas, Nicholas
Subject: Re: [PATCH 1/2] drm/amd/display: Update modifier list
Am 2021-04-15 um 3:25 a.m. schrieb Zhou, Peng Ju:
> [AMD Official Use Only - Internal Distribution Only]
>
> Hi Felix
> Thanks for your proposal about " Given the number of call-sites being
> modified in this patch series"
> We discussed internally, and have following concern:
> 1. expose
[AMD Public Use]
Acked-by: Kent Russell
> -Original Message-
> From: amd-gfx On Behalf Of Feifei Xu
> Sent: Thursday, April 15, 2021 2:11 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Xu, Feifei
> Subject: [PATCH] drm/amdgpu: use ratelimited print in sdma4 interrupt
>
>
Applied. Thanks!
Alex
On Sun, Apr 11, 2021 at 6:21 PM Bas Nieuwenhuizen
wrote:
>
> Reviewed-by: Bas Nieuwenhuizen
>
> On Fri, Apr 9, 2021 at 3:19 PM Simon Ser wrote:
>>
>> Hi,
>>
>> Can you have a look at this patch?
>>
>> Thanks,
>>
>> Simon
>>
>> On Friday, March 26th, 2021 at 5:59 PM,
[SNIP]
Maybe just empirically - let's try it and see under different
test scenarios what actually happens ?
Not a good idea in general, we have that approach way to often at
AMD and are then surprised that everything works in QA but fails
in production.
But Daniel already noted in
Am 2021-04-15 um 3:41 a.m. schrieb Christian König:
>
>
> Am 14.04.21 um 17:15 schrieb Felix Kuehling:
>> Am 2021-04-14 um 3:33 a.m. schrieb Christian König:
>>> Am 14.04.21 um 08:46 schrieb Felix Kuehling:
amdgpu_ttm_tt_unpopulate can be called during bo_destroy. The
dmabuf->resv
looks like a safe reland to me. lgtm.
On Wed, Apr 14, 2021 at 7:35 PM Qingqing Zhuo wrote:
>
> This reverts commit bc3e72b3c3f20ab1583a8464e64f1a68169a28c5.
>
> The regression caused by the original patch has been
> cleared, thus introduce back the change.
>
> Signed-off-by: Qingqing Zhuo
> ---
Kernel test robot throws below warning ->
smatch warnings:
drivers/gpu/drm/radeon/si.c:4514 si_vm_packet3_cp_dma_check() warn:
inconsistent indenting
Fixed the inconsistent indenting.
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
drivers/gpu/drm/radeon/si.c | 2 +-
1 file changed, 1
On 2021-04-15 3:02 a.m., Christian König wrote:
Am 15.04.21 um 08:27 schrieb Andrey Grodzovsky:
On 2021-04-14 10:58 a.m., Christian König wrote:
Am 14.04.21 um 16:36 schrieb Andrey Grodzovsky:
[SNIP]
We are racing here once more and need to handle that.
But why, I wrote above that we
On Thu, Apr 15, 2021 at 12:17:34PM +0200, Thomas Zimmermann wrote:
> Drivers may want to set their own callbacks for a VM area. Only set
> TTM's callbacks if the vm_ops field is clear.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/ttm/ttm_bo_vm.c | 7
Am 15.04.21 um 14:11 schrieb Thomas Zimmermann:
Hi
Am 15.04.21 um 13:38 schrieb Christian König:
Am 15.04.21 um 12:17 schrieb Thomas Zimmermann:
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
This change resolves
Hi
Am 15.04.21 um 13:38 schrieb Christian König:
Am 15.04.21 um 12:17 schrieb Thomas Zimmermann:
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
This change resolves several inconsistencies between regular mmap and
Am 15.04.21 um 12:17 schrieb Thomas Zimmermann:
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
This change resolves several inconsistencies between regular mmap and
prime-based mmap. The vm_ops field in vma is now set for
On Thu, Apr 15, 2021 at 1:35 AM Qingqing Zhuo wrote:
> [Why]
> Current list only includes modifiers where DCC_MAX_COMPRESSED_BLOCK
> is set to AMD_FMT_MOD_DCC_BLOCK_128B, while AMD_FMT_MOD_DCC_BLOCK_64B
> is also supported and used by userspace.
>
> [How]
> Add AMD_FMT_MOD_DCC_BLOCK_64B to
Vmwgfx is the only user of the TTM's verify_access callback. Inline
the call and avoid the indirection through the function pointer.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Zack Rusin
---
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 9 -
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
The GEM object function is provided by GEM TTM helpers. Nouveau's
implementation of verify_access is unused and has been removed. Access
permissions are validated by the DRM
The function ttm_bo_mmap is unused. Remove it and it's helpers; including
the verify_access callback in struct ttm_device_funcs.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 53 -
The vmwgfx driver is the only remaining user of ttm_bo_mmap(). Inline
the code. The internal helper ttm_bo_vm_lookup() is now also part of
vmwgfx as vmw_bo_vm_lookup().
v2:
* replace pr_err() with drm_err() (Zack)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Zack Rusin
---
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
This change also allows to support prime-based mmap via DRM's helper
drm_gem_prime_mmap().
Permission checks are implemented by drm_gem_mmap(), with an additional
check for
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
This change resolves several inconsistencies between regular mmap and
prime-based mmap. The vm_ops field in vma is now set for all mmap'ed
areas. Previously it way only set for
Drivers may want to set their own callbacks for a VM area. Only set
TTM's callbacks if the vm_ops field is clear.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c
Implement mmap via struct drm_gem_object_functions.mmap in amdgpu,
radeon and nouveau. This allows for using common DRM helpers for
the mmap-related callbacks in struct file_operations and struct
drm_driver. The drivers have their own vm_ops, which are now set
automatically by the DRM core
[AMD Official Use Only - Internal Distribution Only]
This looks good to me, I apologize for introducing this issue.
I see the patch has already been submitted to amd-staging-drm-next.
My only concern would be is that MEC2 FW version might still fail to report in
the firmware_info debugfs.
I
So far we only warned when the BOs where pinned and not idle.
Also warn if we see a pinned BO in general.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
We want to drop support in TTM for this.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 36 ++
1 file changed, 10 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
Releasing pinned BOs is illegal now.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c
b/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c
index 7cd67cb2ac5f..1a2bf2ca1be5 100644
---
On Wed, Apr 14, 2021 at 03:25:55PM +0800, Du, Xiaojian wrote:
> This patch is to revise two names of sensor values for vangogh.
> New smu metrics table is supported by new pmfw
> (from version 4.63.36.00 ), it includes two parts, one part is
> the current smu metrics table data and the other part
Am 14.04.21 um 17:15 schrieb Felix Kuehling:
Am 2021-04-14 um 3:33 a.m. schrieb Christian König:
Am 14.04.21 um 08:46 schrieb Felix Kuehling:
amdgpu_ttm_tt_unpopulate can be called during bo_destroy. The
dmabuf->resv
must not be held by the caller or dma_buf_detach will deadlock. This is
[AMD Official Use Only - Internal Distribution Only]
Hi Felix
Thanks for your proposal about " Given the number of call-sites being modified
in this patch series"
We discussed internally, and have following concern:
1. expose our ranges to opensource.
2. lost the orthogonality in
Am 15.04.21 um 08:27 schrieb Andrey Grodzovsky:
On 2021-04-14 10:58 a.m., Christian König wrote:
Am 14.04.21 um 16:36 schrieb Andrey Grodzovsky:
[SNIP]
We are racing here once more and need to handle that.
But why, I wrote above that we first stop the all schedulers, then
only call
On 2021-04-14 10:58 a.m., Christian König wrote:
Am 14.04.21 um 16:36 schrieb Andrey Grodzovsky:
[SNIP]
We are racing here once more and need to handle that.
But why, I wrote above that we first stop the all schedulers, then
only call drm_sched_entity_kill_jobs.
The schedulers
dev_*_ratelimited printing will avoid dmesg flush.
Signed-off-by: Feifei Xu
---
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
index
56 matches
Mail list logo
