[AMD Official Use Only]
>-Original Message-
>From: Lazar, Lijo
>Sent: Wednesday, December 1, 2021 3:28 PM
>To: Yu, Lang ; amd-gfx@lists.freedesktop.org
>Cc: Deucher, Alexander ; Huang, Ray
>; Koenig, Christian
>Subject: Re: [PATCH] drm/amdgpu: add SMU debug option support
>
>
>
>On
On 12/1/2021 12:37 PM, Yu, Lang wrote:
[AMD Official Use Only]
-Original Message-
From: Lazar, Lijo
Sent: Wednesday, December 1, 2021 2:56 PM
To: Yu, Lang ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Huang, Ray
; Koenig, Christian
Subject: Re: [PATCH] drm/amdgpu: add
[AMD Official Use Only]
> -Original Message-
> From: Lazar, Lijo
> Sent: Wednesday, December 1, 2021 2:39 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Koenig, Christian
> ; Feng, Kenneth
> Subject: Re: [PATCH V2 13/17] drm/amd/pm: do not expose the
>
Am 01.12.21 um 04:22 schrieb Zhou Qingyang:
In radeon_driver_open_kms(), radeon_vm_bo_add() is assigned to
vm->ib_bo_va and passes and used in radeon_vm_bo_set_addr(). In
radeon_vm_bo_set_addr(), there is a dereference of vm->ib_bo_va,
which could lead to a NULL pointer dereference on failure of
[AMD Official Use Only]
>-Original Message-
>From: Lazar, Lijo
>Sent: Wednesday, December 1, 2021 2:56 PM
>To: Yu, Lang ; amd-gfx@lists.freedesktop.org
>Cc: Deucher, Alexander ; Huang, Ray
>; Koenig, Christian
>Subject: Re: [PATCH] drm/amdgpu: add SMU debug option support
>
>
>
>On
[AMD Official Use Only]
> -Original Message-
> From: Lazar, Lijo
> Sent: Wednesday, December 1, 2021 11:33 AM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Feng, Kenneth
> ; Koenig, Christian
> Subject: Re: [PATCH V2 01/17] drm/amd/pm: do not expose
Am 30.11.21 um 16:57 schrieb Zhou Qingyang:
In radeon_driver_open_kms(), radeon_vm_bo_add() is assigned to
vm->ib_bo_va and passes and used in radeon_vm_bo_set_addr(). In
radeon_vm_bo_set_addr(), there is a dereference of vm->ib_bo_va,
which could lead to a NULL pointer dereference on failure of
On 12/1/2021 11:57 AM, Yu, Lang wrote:
[AMD Official Use Only]
Hi Lijo,
Thanks for your comments.
From my understanding, that just increases the timeout threshold and
could hide some potential issues which should be exposed and solved.
If current timeout threshold is not enough for
On 12/1/2021 11:09 AM, Quan, Evan wrote:
[AMD Official Use Only]
-Original Message-
From: Lazar, Lijo
Sent: Tuesday, November 30, 2021 9:58 PM
To: Quan, Evan ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Koenig, Christian
; Feng, Kenneth
Subject: Re: [PATCH V2 13/17]
[AMD Official Use Only]
Hi Lijo,
Thanks for your comments.
From my understanding, that just increases the timeout threshold and
could hide some potential issues which should be exposed and solved.
If current timeout threshold is not enough for some corner cases,
(1) Do we consider to increase
[AMD Official Use Only]
> -Original Message-
> From: Lazar, Lijo
> Sent: Tuesday, November 30, 2021 10:07 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Koenig, Christian
> ; Feng, Kenneth
> Subject: Re: [PATCH V2 14/17] drm/amd/pm: relocate the power
Just realized that the patch I pasted won't work. Outer loop exit needs to be
like this.
(reg & MP1_C2PMSG_90__CONTENT_MASK) != 0 && extended_wait-- >= 0
Anyway, that patch is only there to communicate what I really meant in the
earlier comment.
Thanks,
Lijo
-Original
[AMD Official Use Only]
> -Original Message-
> From: Lazar, Lijo
> Sent: Tuesday, November 30, 2021 9:58 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Koenig, Christian
> ; Feng, Kenneth
> Subject: Re: [PATCH V2 13/17] drm/amd/pm: do not expose the
>
On 11/30/2021 10:47 AM, Lang Yu wrote:
To maintain system error state when SMU errors occurred,
which will aid in debugging SMU firmware issues,
add SMU debug option support.
It can be enabled or disabled via amdgpu_smu_debug
debugfs file. When enabled, it makes SMU errors fatal.
It is
On 12/1/2021 8:43 AM, Quan, Evan wrote:
[AMD Official Use Only]
-Original Message-
From: Lazar, Lijo
Sent: Tuesday, November 30, 2021 9:21 PM
To: Quan, Evan ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Koenig, Christian
; Feng, Kenneth
Subject: Re: [PATCH V2 07/17]
[AMD Official Use Only]
> -Original Message-
> From: Lazar, Lijo
> Sent: Tuesday, November 30, 2021 9:48 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Koenig, Christian
> ; Feng, Kenneth
> Subject: Re: [PATCH V2 11/17] drm/amd/pm: correct the usage for
On 11/30/2021 1:39 PM, Lazar, Lijo wrote:
On 11/30/2021 1:12 PM, Evan Quan wrote:
Those implementation details(whether swsmu supported, some ppt_funcs
supported,
accessing internal statistics ...)should be kept internally. It's not
a good
practice and even error prone to expose
On 12/1/2021 7:29 AM, Quan, Evan wrote:
[AMD Official Use Only]
-Original Message-
From: amd-gfx On Behalf Of
Lazar, Lijo
Sent: Tuesday, November 30, 2021 4:10 PM
To: Quan, Evan ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Feng, Kenneth
; Koenig, Christian
Subject:
[AMD Official Use Only]
> -Original Message-
> From: amd-gfx On Behalf Of
> Lazar, Lijo
> Sent: Tuesday, November 30, 2021 8:28 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Feng, Kenneth
> ; Koenig, Christian
> Subject: Re: [PATCH V2 06/17]
On 11/30/ , Christian KKKnig wrote:
> Am 30.11.21 um 06:17 schrieb Lang Yu:
> > To maintain system error state when SMU errors occurred,
> > which will aid in debugging SMU firmware issues,
> > add SMU debug option support.
> >
> > It can be enabled or disabled via amdgpu_smu_debug
> > debugfs
[AMD Official Use Only]
> -Original Message-
> From: Lazar, Lijo
> Sent: Tuesday, November 30, 2021 8:22 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Koenig, Christian
> ; Feng, Kenneth
> Subject: Re: [PATCH V2 05/17] drm/amd/pm: do not expose those
[Public]
> -Original Message-
> From: Chen, Guchun
> Sent: Tuesday, November 30, 2021 9:05 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Lazar, Lijo
> ; Feng, Kenneth ; Koenig,
> Christian ; Quan, Evan
> Subject: RE: [PATCH V2 02/17] drm/amd/pm: do not
[AMD Official Use Only]
> -Original Message-
> From: amd-gfx On Behalf Of
> Lazar, Lijo
> Sent: Tuesday, November 30, 2021 4:10 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Feng, Kenneth
> ; Koenig, Christian
> Subject: Re: [PATCH V2 01/17]
Am 2021-11-30 um 3:13 p.m. schrieb Philip Yang:
> svm_range_bo_release could be called from __do_munmap put_page
> atomic context if process release work has finished to free pranges of
> the svm_bo. Schedule release_work to wait for svm_bo eviction work done
> and then free svm_bo.
>
>
> On 2021-11-30 10:48 a.m., Harry Wentland wrote:
> > On 2021-11-30 10:46, Rodrigo Siqueira Jordao wrote:
> >>
> >>
> >> On 2021-11-29 7:06 a.m., Jani Nikula wrote:
> >>> On Fri, 26 Nov 2021, Daniel Vetter wrote:
> On Thu, Nov 25, 2021 at 10:38:25AM -0500, Rodrigo Siqueira
> wrote:
>
svm_range_bo_release could be called from __do_munmap put_page
atomic context if process release work has finished to free pranges of
the svm_bo. Schedule release_work to wait for svm_bo eviction work done
and then free svm_bo.
Signed-off-by: Philip Yang
---
drivers/gpu/drm/amd/amdkfd/kfd_svm.c
Under SRIOV, there will be dynamic VCN assignment controlled by the host
driver. The VCN assignment information is passed using IP discovery data
and VCN revision. The revision ID can be 64, 128 and 192.
The swIP code (vcn_v3_0.c) will handle the initialization according to the
revision ID of
- Mail original -
> De: "Rodrigo Siqueira Jordao"
> À: ydir...@free.fr, "Rodrigo Siqueira" , "Christian
> König" ,
> "Alex Deucher"
> Cc: "Harry Wentland" , "Linux Doc Mailing List"
> , "Mark Yacoub"
> , "Michel Dänzer" , "Bas
> Nieuwenhuizen" ,
> "Roman Li" , "amd-gfx list"
> ,
Am 2021-11-30 um 11:51 a.m. schrieb philip yang:
>
>
> On 2021-11-30 6:26 a.m., Zhou Qingyang wrote:
>> In svm_range_add(), the return value of svm_range_new() is assigned
>> to prange and >insert_list is used in list_add(). There is a
>> a dereference of >insert_list in list_add(), which could
On 2021-11-30 6:26 a.m., Zhou Qingyang
wrote:
In svm_range_add(), the return value of svm_range_new() is assigned
to prange and >insert_list is used in list_add(). There is a
a dereference of >insert_list in list_add(), which could lead
to a wild pointer
On 2021-11-30 10:59, Rodrigo Siqueira Jordao wrote:
>
>
> On 2021-11-30 10:48 a.m., Harry Wentland wrote:
>> On 2021-11-30 10:46, Rodrigo Siqueira Jordao wrote:
>>>
>>>
>>> On 2021-11-29 7:06 a.m., Jani Nikula wrote:
On Fri, 26 Nov 2021, Daniel Vetter wrote:
> On Thu, Nov 25, 2021
On 2021-11-30 10:48 a.m., Harry Wentland wrote:
On 2021-11-30 10:46, Rodrigo Siqueira Jordao wrote:
On 2021-11-29 7:06 a.m., Jani Nikula wrote:
On Fri, 26 Nov 2021, Daniel Vetter wrote:
On Thu, Nov 25, 2021 at 10:38:25AM -0500, Rodrigo Siqueira wrote:
Display core documentation is not
On 2021-11-29 3:48 p.m., ydir...@free.fr wrote:
Hi Rodrigo,
That will really be helpful!
I know drawing the line is a difficult problem (and can even make things
harder when searching), but maybe it would make sense to keep generic
acronyms not specific to amdgpu in a separate list. I bet
On 2021-11-30 10:46, Rodrigo Siqueira Jordao wrote:
>
>
> On 2021-11-29 7:06 a.m., Jani Nikula wrote:
>> On Fri, 26 Nov 2021, Daniel Vetter wrote:
>>> On Thu, Nov 25, 2021 at 10:38:25AM -0500, Rodrigo Siqueira wrote:
Display core documentation is not well organized, and it is hard to find
On 2021-11-29 7:06 a.m., Jani Nikula wrote:
On Fri, 26 Nov 2021, Daniel Vetter wrote:
On Thu, Nov 25, 2021 at 10:38:25AM -0500, Rodrigo Siqueira wrote:
Display core documentation is not well organized, and it is hard to find
information due to the lack of sections. This commit reorganizes
Am 30.11.21 um 16:33 schrieb Zhou Qingyang:
In radeon_driver_open_kms(), radeon_vm_bo_add() is assigned to
vm->ib_bo_va and passes and used in radeon_vm_bo_set_addr(). In
radeon_vm_bo_set_addr(), there is a dereference of vm->ib_bo_va,
which could lead to a NULL pointer dereference on failure
Thanks for the review , change the description as suggested and submitted.
Shaoyun.liu
-Original Message-
From: Kuehling, Felix
Sent: Tuesday, November 30, 2021 1:19 AM
To: amd-gfx@lists.freedesktop.org; Liu, Shaoyun
Subject: Re: [PATCH] drm/amdgpu: adjust the kfd reset sequence in
On 2021-11-30 09:53, Nicholas Kazlauskas wrote:
> [Why]
> PSR currently relies on the kernel's delayed vblank on/off mechanism
> as an implicit bufferring mechanism to prevent excessive entry/exit.
>
> Without this delay the user experience is impacted since it can take
> a few frames to
Am 30.11.21 um 16:04 schrieb Zhou Qingyang:
In radeon_driver_open_kms(), radeon_vm_bo_add() is assigned to
vm->ib_bo_va and passes and used in radeon_vm_bo_set_addr(). In
radeon_vm_bo_set_addr(), there is a dereference of vm->ib_bo_va,
which could lead to a NULL pointer dereference on failure of
[Public]
Acked-by: Alex Deucher
From: Nicholas Kazlauskas
Sent: Tuesday, November 30, 2021 9:53 AM
To: amd-gfx@lists.freedesktop.org
Cc: Kazlauskas, Nicholas ; Wentland, Harry
; Deucher, Alexander
Subject: [PATCH] drm/amdgpu/display: Only set
From: Yang Wang
[ Upstream commit fd08953b2de911f32c06aedbc8ad111c2fd0168b ]
fix some byteorder issues about amdgpu discovery.
This will result in running errors on the big end system. (e.g:MIPS)
Signed-off-by: Yang Wang
Reviewed-by: Guchun Chen
Reviewed-by: Lijo Lazar
Signed-off-by: Alex
From: Philip Yang
[ Upstream commit 0cc53cb450669cf1def4ff89e8cbcd8ec3c62380 ]
VMA may be removed before unmap notifier callback, and deferred list
work remove range, return success for this special case as we are
handling stale retry fault.
Signed-off-by: Philip Yang
Reviewed-by: Felix
From: Alex Deucher
[ Upstream commit 692cd92e66ee10597676530573a495dc1d3bec6a ]
Update the bios scratch register when updating the backlight
level. Some platforms apparently read this scratch register
and do additional operations in their hotkey handlers.
Bug:
From: Felix Kuehling
[ Upstream commit d3a21f7e353dc8d6939383578f3bd45b4ae3a946 ]
Disable HDP register remapping on SRIOV and set rmmio_remap.reg_offset
to the fixed address of the VF register for hdp_v*_flush_hdp.
Signed-off-by: Felix Kuehling
Tested-by: Bokun Zhang
Reviewed-by: Lijo Lazar
From: xinhui pan
[ Upstream commit 4eb6bb649fe041472ddd00f94870c0b86ef49d34 ]
amdgpu_amdkfd_gpuvm_free_memory_of_gpu drop dmabuf reference increased in
amdgpu_gem_prime_export.
amdgpu_bo_destroy drop dmabuf reference increased in
amdgpu_gem_prime_import.
So remove this extra dma_buf_put to
From: Yi-Ling Chen
[ Upstream commit 2da8f0beece08a5c3c2e20c0e38e1a4bbc153f9e ]
[WHY]
Due to pass the wrong parameter down to the enable_stream_gating(),
it would cause the DSC of the removing stream would not be PG.
[HOW]
To pass the correct parameter down th the enable_stream_gating().
[Why]
PSR currently relies on the kernel's delayed vblank on/off mechanism
as an implicit bufferring mechanism to prevent excessive entry/exit.
Without this delay the user experience is impacted since it can take
a few frames to enter/exit.
[How]
Only allow vblank disable immediate for DC when
On Mon, Nov 29, 2021 at 3:48 PM wrote:
>
> Hi Rodrigo,
>
> That will really be helpful!
>
> I know drawing the line is a difficult problem (and can even make things
> harder when searching), but maybe it would make sense to keep generic
> acronyms not specific to amdgpu in a separate list. I bet
On 11/30/2021 1:12 PM, Evan Quan wrote:
Instead of centralizing all headers in the same folder. Separate them into
different folders and place them among those source files those who really
need them.
Signed-off-by: Evan Quan
Change-Id: Id74cb4c7006327ca7ecd22daf17321e417c4aa71
---
On 11/30/2021 1:12 PM, Evan Quan wrote:
This can cover the power implementation details. And as what did for
powerplay framework, we hook the smu_context to adev->powerplay.pp_handle.
Signed-off-by: Evan Quan
Change-Id: I3969c9f62a8b63dc6e4321a488d8f15022ffeb3d
---
On 11/30/2021 1:12 PM, Evan Quan wrote:
We should avoid having multi-function APIs. It should be up to the caller
to determine when or whether to call amdgpu_dpm_dispatch_task().
Signed-off-by: Evan Quan
Change-Id: I78ec4eb8ceb6e526a4734113d213d15a5fbaa8a4
---
On 11/30/2021 1:12 PM, Evan Quan wrote:
Those APIs are used only by legacy ASICs(si/kv). They cannot be
shared by other ASICs. So, we create a new holder for them.
Signed-off-by: Evan Quan
Change-Id: I555dfa37e783a267b1d3b3a7db5c87fcc3f1556f
--
v1->v2:
- move other APIs used by si/kv in
[Public]
Two nit-picks.
1. It's better to drop "return" in amdgpu_dpm_get_current_power_state.
2. In some functions, when function pointer is NULL, sometimes it returns 0,
while in other cases, it returns -EOPNOTSUPP. Is there any cause for this?
Regards,
Guchun
-Original Message-
On 11/30/2021 1:12 PM, Evan Quan wrote:
Move it to kv_dpm.c instead.
Signed-off-by: Evan Quan
Change-Id: I554332b386491a79b7913f72786f1e2cb1f8165b
--
v1->v2:
- rename the API with "kv_" prefix(Alex)
---
drivers/gpu/drm/amd/pm/amdgpu_dpm.c | 23 -
On 11/30/2021 1:12 PM, Evan Quan wrote:
Move them to si_dpm.c instead.
Signed-off-by: Evan Quan
Change-Id: I288205cfd7c6ba09cfb22626ff70360d61ff0c67
--
v1->v2:
- rename the API with "si_" prefix(Alex)
---
drivers/gpu/drm/amd/pm/amdgpu_dpm.c | 25 ---
Am 30.11.21 um 06:17 schrieb Lang Yu:
To maintain system error state when SMU errors occurred,
which will aid in debugging SMU firmware issues,
add SMU debug option support.
It can be enabled or disabled via amdgpu_smu_debug
debugfs file. When enabled, it makes SMU errors fatal.
It is disabled
Am 29.11.21 um 21:48 schrieb ydir...@free.fr:
Hi Rodrigo,
That will really be helpful!
I know drawing the line is a difficult problem (and can even make things
harder when searching), but maybe it would make sense to keep generic
acronyms not specific to amdgpu in a separate list. I bet a
Am 30.11.21 um 08:42 schrieb Evan Quan:
There are several problems with current power implementations:
1. Too many internal details are exposed to other blocks. Thus to interact with
power, they need to know which power framework is used(powerplay vs swsmu)
or even whether some API is
On 11/30/2021 1:12 PM, Evan Quan wrote:
Those implementation details(whether swsmu supported, some ppt_funcs supported,
accessing internal statistics ...)should be kept internally. It's not a good
practice and even error prone to expose implementation details.
Signed-off-by: Evan Quan
59 matches
Mail list logo
