[AMD Official Use Only]
Hi @Liu, Leo
Can you help to review this patch?
Monk and Alex have reviewed it.
--
BW
Pengju Zhou
> -Original Message-
> From: Liu, Monk
> Sent: Thursday, July 15, 2021 7:54 AM
> To: Alex De
The printing message "PSP loading VCN firmware" is mis-leading because
people might think driver is loading VCN firmware. Actually when this
message is printed, driver is just preparing some VCN ucode, not loading
VCN firmware yet. The actual VCN firmware loading will be in the PSP block
hw_init. F
This variable will be used to determine whether packet
manager is initialized or not, in a future patch.
Signed-off-by: Oak Zeng
---
drivers/gpu/drm/amd/amdkfd/kfd_packet_manager.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_packet_manager.c
b/drivers/gpu/
Oak Zeng (5):
drm/amdgpu: Fix a printing message
drm/amdgpu: Change a few function names
drm/amdkfd: Renaming dqm->packets to dqm->dpm
drm/amdkfd: Set priv_queue to NULL after it is freed
drm/amdkfd: Fix a concurrency issue during kfd recovery
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
Renaming packets to dpm (device packet manager) to
reflect the real meaning of this variable.
Signed-off-by: Oak Zeng
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c| 2 +-
.../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 26 +++---
.../gpu/drm/amd/amdkfd/kfd_device_
Function name "psp_np_fw_load" is not proper as people don't
know _np_fw_ means "non psp firmware". Change the function
name to psp_load_non_psp_fw for better understanding. Same
thing for function psp_execute_np_fw_load.
Signed-off-by: Oak Zeng
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd
start_cpsch and stop_cpsch can be called during kfd device
initialization or during gpu reset/recovery. So they can
run concurrently. Currently in start_cpsch and stop_cpsch,
pm_init and pm_uninit is not protected by the dpm lock.
Imagine such a case that user use packet manager's function
to submi
This variable will be used to determine whether packet
manager is initialized or not, in a future patch.
Signed-off-by: Oak Zeng
---
drivers/gpu/drm/amd/amdkfd/kfd_packet_manager.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_packet_manager.c
b/drivers/gpu/
Function name "psp_np_fw_load" is not proper as people don't
know _np_fw_ means "non psp firmware". Change the function
name to psp_load_non_psp_fw for better understanding. Same
thing for function psp_execute_np_fw_load.
Signed-off-by: Oak Zeng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 16 +
Renaming packets to dpm (device packet manager) to
reflect the real meaning of this variable.
Signed-off-by: Oak Zeng
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c| 2 +-
.../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 26 +++---
.../gpu/drm/amd/amdkfd/kfd_device_
start_cpsch and stop_cpsch can be called during kfd device
initialization or during gpu reset/recovery. So they can
run concurrently. Currently in start_cpsch and stop_cpsch,
pm_init and pm_uninit is not protected by the dpm lock.
Imagine such a case that user use packet manager's function
to submi
The printing message "PSP loading VCN firmware" is mis-leading because
people might think driver is loading VCN firmware. Actually when this
message is printed, driver is just preparing some VCN ucode, not loading
VCN firmware yet. The actual VCN firmware loading will be in the PSP block
hw_init. F
Oak Zeng (5):
drm/amdgpu: Fix a printing message
drm/amdgpu: Change a few function names
drm/amdkfd: Renaming dqm->packets to dqm->dpm
drm/amdkfd: Set priv_queue to NULL after it is freed
drm/amdkfd: Fix a concurrency issue during kfd recovery
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
From: Harry Wentland
commit c6c6a712199ab355ce333fa5764a59506bb107c1 upstream.
[Why]
This hasn't been well tested and leads to complete system hangs on DCN1
based systems, possibly others.
The system hang can be reproduced by gesturing the video on the YouTube
Android app on ChromeOS into full
From: Harry Wentland
commit c6c6a712199ab355ce333fa5764a59506bb107c1 upstream.
[Why]
This hasn't been well tested and leads to complete system hangs on DCN1
based systems, possibly others.
The system hang can be reproduced by gesturing the video on the YouTube
Android app on ChromeOS into full
From: Harry Wentland
commit c6c6a712199ab355ce333fa5764a59506bb107c1 upstream.
[Why]
This hasn't been well tested and leads to complete system hangs on DCN1
based systems, possibly others.
The system hang can be reproduced by gesturing the video on the YouTube
Android app on ChromeOS into full
From: Harry Wentland
commit c6c6a712199ab355ce333fa5764a59506bb107c1 upstream.
[Why]
This hasn't been well tested and leads to complete system hangs on DCN1
based systems, possibly others.
The system hang can be reproduced by gesturing the video on the YouTube
Android app on ChromeOS into full
On 2021-07-15 3:59 p.m., Alex Sierra wrote:
[Why]
Avoid conflict with address ranges mapped by SVM
mechanism that try to be allocated again through
ioctl_alloc in the same process. And viceversa.
[How]
For ioctl_alloc_memory_of_gpu allocations
Check if the address range passed into ioctl memory
[Why]
Avoid conflict with address ranges mapped by SVM
mechanism that try to be allocated again through
ioctl_alloc in the same process. And viceversa.
[How]
For ioctl_alloc_memory_of_gpu allocations
Check if the address range passed into ioctl memory
alloc does not exist already in the kfd_proces
On 2021-07-15 3:19 p.m., Mario Kleiner wrote:
> On Thu, Jul 15, 2021 at 6:10 PM Alex Deucher wrote:
>>
>> On Wed, Jul 14, 2021 at 4:15 AM Liviu Dudau wrote:
>>>
>>> Commit 72a7cf0aec0c ("drm/amd/display: Keep linebuffer pixel depth at
>>> 30bpp for DCE-11.0.") doesn't seems to have fixed 10bit
KFD Thunk maps invisible VRAM BOs with PROT_NONE, MAP_PRIVATE.
is_cow_mapping returns true for these mappings, which causes mmap to fail
in ttm_bo_mmap_obj.
As a workaround, clear VM_MAYWRITE for PROT_NONE-COW mappings. This
should prevent the mapping from ever becoming writable and makes
is_cow_m
On Thu, Jul 15, 2021 at 6:10 PM Alex Deucher wrote:
>
> On Wed, Jul 14, 2021 at 4:15 AM Liviu Dudau wrote:
> >
> > Commit 72a7cf0aec0c ("drm/amd/display: Keep linebuffer pixel depth at
> > 30bpp for DCE-11.0.") doesn't seems to have fixed 10bit 4K rendering over
> > DisplayPort for CIK GPUs. On m
[Public]
As far as I know, umr is the only user of this and it shouldn't cause any
problems there.
Acked-by: Alex Deucher
From: amd-gfx on behalf of Joseph
Greathouse
Sent: Tuesday, June 29, 2021 11:47 PM
To: amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom ;
Looking at the ticket, it's getting a segfault in user mode. The only
possible mechanism I can see where this change causes that segfault, is
a badly handled memory allocation failure. But I don't have an
explanation for how this patch introduces a memory allocation failure
that wasn't there before
Hi Christian,
I have pushed it into amd-staging-dkms-5.11, but it causes a regression
with test TransferBench on MI200. Jira is here:
https://ontrack-internal.amd.com/browse/SWDEV-295245
Can you please take a look? Thanks!
Regards,
Eric
On 2021-07-14 4:33 a.m., Christian König wrote:
Hi Eri
Am 2021-07-15 um 5:14 a.m. schrieb Yifan Zhang:
> fix kfd svm test failure in renoir/cezane
This is not a fix, it's a workaround. With that fixed, the patch is
Acked-by: Felix Kuehling
>
> Signed-off-by: Yifan Zhang
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 1 +
> 1 file changed, 1 i
On 2021-07-08 6:13 p.m., Michel Dänzer wrote:
> On 2021-06-29 12:36 p.m., Michel Dänzer wrote:
>> On 2021-06-28 7:16 p.m., Deucher, Alexander wrote:
>>>
>>> Thanks for narrowing this down. There is new PCO SDMA firmware available
>>> (attached). Can you try it?
>>
>> Sure, I'll try it, thanks.
>
Signed-off-by: Roy Sun
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index bc4347a72301..3ac0d27e8ad1 100644
--- a/drivers/gp
On Wed, Jul 14, 2021 at 4:15 AM Liviu Dudau wrote:
>
> Commit 72a7cf0aec0c ("drm/amd/display: Keep linebuffer pixel depth at
> 30bpp for DCE-11.0.") doesn't seems to have fixed 10bit 4K rendering over
> DisplayPort for CIK GPUs. On my machine with a HAWAII GPU I get a broken
> image that looks lik
On Thu, Jul 15, 2021 at 10:37 AM Colin King wrote:
>
> From: Colin Ian King
>
> Don't populate the const array common_rates on the stack but instead it
> static. Makes the object code smaller by 80 bytes:
>
> Before:
>textdata bss dec hex filename
> 268019 98322 256 36
On 2021-07-15 4:07 p.m., Alex Deucher wrote:
> On Thu, Jul 15, 2021 at 12:52 AM Sam Ravnborg wrote:
>> On Wed, Jul 14, 2021 at 06:08:58PM -0400, Alex Deucher wrote:
>>> Hi Dave, Daniel,
>>>
>>> Fixes for 5.14. The big change here is unifying the SMU13 code. This was
>>> new code added in 5.14 to
From: Colin Ian King
Don't populate the const array common_rates on the stack but instead it
static. Makes the object code smaller by 80 bytes:
Before:
textdata bss dec hex filename
268019 98322 256 366597 59805 ../display/amdgpu_dm/amdgpu_dm.o
After:
textdat
On Thu, Jul 15, 2021 at 12:52 AM Sam Ravnborg wrote:
>
> Hi Alex,
>
> On Wed, Jul 14, 2021 at 06:08:58PM -0400, Alex Deucher wrote:
> > Hi Dave, Daniel,
> >
> > Fixes for 5.14. The big change here is unifying the SMU13 code. This was
> > new code added in 5.14 to support Yellow Carp, but we've s
Am 15.07.21 um 11:29 schrieb Lazar, Lijo:
On 7/15/2021 2:56 PM, Christian König wrote:
Am 15.07.21 um 10:24 schrieb Kevin Wang:
using exiting function to replace duplicate code blocks in
amdgpu_ttm_vram_write().
NAK, this should intentionally only use the MM path and not the aper
path.
On 7/15/2021 2:56 PM, Christian König wrote:
Am 15.07.21 um 10:24 schrieb Kevin Wang:
using exiting function to replace duplicate code blocks in
amdgpu_ttm_vram_write().
NAK, this should intentionally only use the MM path and not the aper path.
What about platform configs which don't supp
Am 15.07.21 um 10:24 schrieb Kevin Wang:
using exiting function to replace duplicate code blocks in
amdgpu_ttm_vram_write().
NAK, this should intentionally only use the MM path and not the aper path.
But you could use amdgpu_device_mm_access() here now.
Christian.
Signed-off-by: Kevin Wang
Am 15.07.21 um 10:24 schrieb Kevin Wang:
split amdgpu_device_access_vram()
1. amdgpu_device_mm_access(): using MM_INDEX/MM_DATA to access vram
2. amdgpu_device_aper_access(): using vram aperature to access vram (option)
Still not the approach I had in mind, but let's move forward we need to
ge
fix kfd svm test failure in renoir/cezane
Signed-off-by: Yifan Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
index d4e9704dec62..00dc2824dcc3 100644
--- a/dr
This is a note to let you know that I've just added the patch titled
drm/amd/display: Reject non-zero src_y and src_x for video planes
to the 5.12-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patc
This is a note to let you know that I've just added the patch titled
drm/amd/display: Reject non-zero src_y and src_x for video planes
to the 5.13-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patc
This is a note to let you know that I've just added the patch titled
drm/amd/display: Reject non-zero src_y and src_x for video planes
to the 5.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patc
This is a note to let you know that I've just added the patch titled
drm/amd/display: Reject non-zero src_y and src_x for video planes
to the 5.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch
1. using vram aper to access vram if possible
2. avoid MM_INDEX/MM_DATA is not working when mmio protect feature is
enabled.
Signed-off-by: Kevin Wang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 95 +++--
1 file changed, 58 insertions(+), 37 deletions(-)
diff --git a/drive
split amdgpu_device_access_vram()
1. amdgpu_device_mm_access(): using MM_INDEX/MM_DATA to access vram
2. amdgpu_device_aper_access(): using vram aperature to access vram (option)
Signed-off-by: Kevin Wang
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 7 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_
using exiting function to replace duplicate code blocks in
amdgpu_ttm_vram_write().
Signed-off-by: Kevin Wang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgp
[AMD Official Use Only]
From: Lazar, Lijo
Sent: Thursday, July 15, 2021 3:47 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Wang, Kevin(Yang)
; Feng, Kenneth ; Quan, Evan
Subject: [PATCH] drm/amd/pm: Support board calibration on aldebaran
Add supp
[AMD Official Use Only]
Reviewed-by: Jack Gui
-Original Message-
From: Zhou1, Tao
Sent: Thursday, July 15, 2021 3:51 PM
To: amd-gfx@lists.freedesktop.org; Chen, Jiansong (Simon)
; Gui, Jack ; Zhang, Hawking
Cc: Zhou1, Tao
Subject: [PATCH] drm/amd/pm: update DRIVE_IF_VERSION for bei
Update the version to 0xD for beige_goby.
Signed-off-by: Tao Zhou
---
drivers/gpu/drm/amd/pm/inc/smu_v11_0.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/inc/smu_v11_0.h
b/drivers/gpu/drm/amd/pm/inc/smu_v11_0.h
index b89e7dca8906..385b2ea5379c 10064
Add support for board power calibration on Aldebaran.
Board calibration is done after DC offset calibration.
Signed-off-by: Lijo Lazar
---
drivers/gpu/drm/amd/pm/inc/aldebaran_ppsmc.h | 3 +-
drivers/gpu/drm/amd/pm/inc/smu_types.h| 3 +-
.../drm/amd/pm/swsmu/smu13/aldebaran_ppt.c|
[Public]
Reviewed-by: Guchun Chen
Regards,
Guchun
-Original Message-
From: amd-gfx On Behalf Of Tao Zhou
Sent: Thursday, July 15, 2021 3:13 PM
To: amd-gfx@lists.freedesktop.org; Chen, Jiansong (Simon)
; Gui, Jack ; Zhang, Hawking
Cc: Zhou1, Tao
Subject: [PATCH] drm/amdgpu: update g
Update gc_10_3_4 golden setting.
Signed-off-by: Tao Zhou
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 80e7069e12ac..454293ea5b02 100644
--- a/drivers/gpu/drm/a
On Wed, 14 Jul 2021 20:18:57 +0200
Werner Sembach wrote:
> Am 01.07.21 um 13:30 schrieb Werner Sembach:
> > Am 01.07.21 um 09:42 schrieb Pekka Paalanen:
> >> On Wed, 30 Jun 2021 11:42:10 +0200
> >> Werner Sembach wrote:
> >>
> >>> Am 30.06.21 um 10:21 schrieb Pekka Paalanen:
> On Tue,
[AMD Official Use Only]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Gao, Likun
Sent: Thursday, July 15, 2021 12:11
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Chen, Guchun ;
Gao, Likun
Subject: [PATCH] drm/amdgpu: update golden setting for sienna_c
From: Likun Gao
Update GFX golden setting for sienna_cichlid.
Signed-off-by: Likun Gao
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index cd8dcec7fdbb..7c08818fc14
On Wed, Jul 14, 2021 at 05:32:03PM +0800, Du, Xiaojian wrote:
> This patch is to update the golden setting for vangogh.
>
> Signed-off-by: Xiaojian Du
> ---
Reviewed-by: Huang Rui
> drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/dr
55 matches
Mail list logo
