If set error query ready in amdgpu_ras_late_init, which will
cause some IP blocks aren't initialized, but their error query
is ready.
v2: change the prefix of title to "drm/amdgpu" and remove
the unnecessary "{}".
Change-Id: I5087527261cb1b462afd82ad7592cf1ef73b15bd
Signed-off-by: Dennis Li
[AMD Public Use]
if (adev->in_suspend || adev->in_gpu_reset) {
- amdgpu_ras_set_error_query_ready(adev, true);
return 0;
}
Please also remove the "{}". With that fixed, the patch is
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original
[AMD Public Use]
Need to modify prefix of commit tile to 'drm/amdgpu'.
With that fixed, the patch is: Reviewed-by: Guchun Chen
Regards,
Guchun
-Original Message-
From: Dennis Li
Sent: Wednesday, April 22, 2020 12:31 PM
To: amd-gfx@lists.freedesktop.org; Deucher, Alexander
; Zhou1,
According to the current kiq access register method,
there will be race condition when using KIQ to read
register if multiple clients want to read at same time
just like the expample below:
1. client-A start to read REG-0 throguh KIQ
2. client-A poll the seqno-0
3. client-B start to read REG-1
If set error query ready in amdgpu_ras_late_init, which will
cause some IP blocks aren't initialized, but their error query
is ready.
Change-Id: I5087527261cb1b462afd82ad7592cf1ef73b15bd
Signed-off-by: Dennis Li
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
Acked-by: Yintian Tao
-Original Message-
From: Christian König
Sent: 2020年4月21日 22:23
To: Liu, Monk ; He, Jacob ; Tao, Yintian
; amd-gfx@lists.freedesktop.org
Subject: [PATCH] drm/amdgpu: change how we update mmRLC_SPM_MC_CNTL
In pp_one_vf mode avoid the extra overhead and read/write
Mode1 reset is also affected as I confirmed on navi10 unfortunately.
That is why the original design(switch to mode1 reset on audio suspended
failure) over our previous discussions was not taken.
Anyway, I sent out a V2 patch to limit this for baco and mode1 reset only.
Regards,
Evan
At default, the autosuspend delay of audio controller is 3S. If the
gpu reset is triggered within 3S(after audio controller idle),
the audio controller may be unable into suspended state. Then
the sudden gpu reset will cause some audio errors. The change
here is targeted to resolve this.
However
On 2020-04-21 21:46, Bernard Zhao wrote:
Make the code a bit more readable by using a common
error handling pattern.
With that done the patch is Reviewed-by: Christian König
.
Signed-off-by: Bernard Zhao
Thanks. The patch is
Reviewed-by: Felix Kuehling
I removed the history from the
Thanks again for the patch. I'm going to apply this with some minor
fixes. The headline should start with "drm/amdgpu:". I'll also change
the wording of the headline and commit message:
drm/amdgpu: shrink critical section in
amdgpu_amdkfd_gpuvm_free_memory_of_gpu
Reduce the
Reviewed-by: Monk Liu
_
Monk Liu|GPU Virtualization Team |AMD
-Original Message-
From: Christian König
Sent: Tuesday, April 21, 2020 10:23 PM
To: Liu, Monk ; He, Jacob ; Tao, Yintian
; amd-gfx@lists.freedesktop.org
Subject: [PATCH] drm/amdgpu:
See comments inline.
Am 2020-04-19 um 9:58 p.m. schrieb Mukul Joshi:
> Track GPU memory usage on a per process basis and report it through
> sysfs.
>
> Signed-off-by: Mukul Joshi
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 12 ++
> drivers/gpu/drm/amd/amdkfd/kfd_priv.h| 7
>
Patch 1 Acked-by: Andrey Grodzovsky
Patches 2-4 Reviewed-by: Andrey Grodzovsky
Andrey
On 4/21/20 1:23 AM, Evan Quan wrote:
Patch 1 and 2 are the necessary fixes for XGMI setup. Since these
operations are needed for other devices from the same hive. That's
missing now.
Patch 3 are 4 are
On Tue, Apr 21, 2020 at 8:00 AM Evan Quan wrote:
>
> At default, the autosuspend delay of audio controller is 3S. If the
> gpu reset is triggered within 3S(after audio controller idle),
> the audio controller may be unable into suspended state. Then
> the sudden gpu reset will cause some audio
发件人："Christian König"
发送日期：2020-04-21 21:02:27
收件人："赵军奎"
抄送人：Alex Deucher ,"David (ChunMing) Zhou"
,David Airlie ,Daniel Vetter
,Tom St Denis ,Ori Messinger
,Sam Ravnborg
,amd-gfx@lists.freedesktop.org,dri-de...@lists.freedesktop.org,linux-ker...@vger.kernel.org,opensource.ker...@vivo.com
Am 21.04.20 um 15:39 schrieb 赵军奎:
发件人："Christian König"
发送日期：2020-04-21 21:02:27
收件人："赵军奎"
抄送人：Alex Deucher ,"David (ChunMing) Zhou" ,David Airlie
,Daniel Vetter ,Tom St Denis ,Ori Messinger
,Sam Ravnborg
Am 21.04.20 um 16:33 schrieb Christian König:
Am 20.04.20 um 03:50 schrieb Randy Dunlap:
Fix a kernel-doc warning of missing struct field desription:
../drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:92: warning: Function
parameter or member 'vm' not described in 'amdgpu_vm_eviction_lock'
Can't we
Am 20.04.20 um 03:50 schrieb Randy Dunlap:
Fix a kernel-doc warning of missing struct field desription:
../drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:92: warning: Function parameter or
member 'vm' not described in 'amdgpu_vm_eviction_lock'
Can't we just document the function parameter instead?
In pp_one_vf mode avoid the extra overhead and read/write the
registers without the KIQ.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 13 ++---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 10 --
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 13
On 2020-04-19 9:50 p.m., Randy Dunlap wrote:
> Fix a kernel-doc warning of missing struct field desription:
>
> ../drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:331: warning: Function
> parameter or member 'hdcp_workqueue' not described in 'amdgpu_display_manager'
>
> Fixes: 52704fcaf74b
On 2020-04-19 9:50 p.m., Randy Dunlap wrote:
> Fix a kernel-doc warning of missing struct field desription:
>
> ../drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:92: warning: Function parameter or
> member 'vm' not described in 'amdgpu_vm_eviction_lock'
>
> Fixes: a269e44989f3 ("drm/amdgpu: Avoid
> What are you talking about? The bits control what is used in the MC
> interface, there is no increment or anything here.
My bad , it is RLC_SPM_PERF_CNTR not RLC_SPM_PERF_COUNTER, I though it as
COUNTER
>>Agreed that sounds like a good idea to me as well no matter if we use RMW or
>>just
Hi Christian
Great. Then can you modify the patch according to Monk's suggestion?
We need this patch for one important project.
Best Regards
Yintian Tao
-Original Message-
From: Koenig, Christian
Sent: 2020年4月21日 21:38
To: Liu, Monk ; Tao, Yintian ; He, Jacob
;
The problem is some fields are increased by hardware
What are you talking about? The bits control what is used in the MC
interface, there is no increment or anything here.
I think at least we should apply one change: we use NO_KIQ for SRIOV
pp_one_vf_mode case to access this SPM register
The problem is some fields are increased by hardware, and RLC simply read its
value, we cannot set those field together with VMID
Christian, we should stop arguing on this small feature, there is no way to
have a worse solution compared with current logic
I think at least we should
From: "Christian König"
Date: 2020-04-21 16:06:03
To: 1587180037-113840-1-git-send-email-bern...@vivo.com,Felix Kuehling
,Alex Deucher ,"David
(ChunMing) Zhou" ,David Airlie ,Daniel
Vetter
,amd-gfx@lists.freedesktop.org,dri-de...@lists.freedesktop.org,linux-ker...@vger.kernel.org
Cc:
Maybe we could reduce the mutex_lock(>lock)`s protected code area,
and no need to protect pr_debug.
Signed-off-by: Bernard Zhao
Changes since V1:
*commit message improve
Changes since V2:
*move comment along with the mutex_unlock
Changes since V3:
*lock protect the if check, there is some
From: "Christian König"
Date: 2020-04-21 19:22:49
To: Bernard Zhao ,Alex Deucher
,"David (ChunMing) Zhou" ,David
Airlie ,Daniel Vetter ,Tom St Denis
,Ori Messinger ,Sam Ravnborg
,amd-gfx@lists.freedesktop.org,dri-de...@lists.freedesktop.org,linux-ker...@vger.kernel.org
Cc:
There is no need to if check again, maybe we could merge
into the above else branch.
Signed-off-by: Bernard Zhao
Changes since V1:
*commit message improve
*code style refactoring
Changes since V2:
*code style adjust
Changes since V3:
*find the best way to merge unnecessary if/else check
From: "Christian König"
Date: 2020-04-21 15:41:27
To: 1587181464-114215-1-git-send-email-bern...@vivo.com,Felix Kuehling
,Alex Deucher ,"David
(ChunMing) Zhou" ,David Airlie ,Daniel
Vetter
,amd-gfx@lists.freedesktop.org,dri-de...@lists.freedesktop.org,linux-ker...@vger.kernel.org
Cc:
>> But i have to say there are so many code not follow the kernel code-style in
>> amdgpu module.
>> And also the ./scripts/checkpatch.pl did not throw any warning or error.
>
> That is unfortunately true, yes. But we try to push new code through the
> usual code review and improve things as we
>>> There is no need to if check again, maybe we could merge
>>> into the above else branch.
I find also this commit message still improvable (besides the mentioned
implementation details around coding style concerns).
How will corresponding review comments be taken better into account?
Regards,
> The "if(!encoder)" branch return the same value 0 of the success
> branch, maybe return -EINVAL is more better.
I suggest to improve the commit message.
* Are you still unsure about the next changes?
> But i have to say there are so many code not follow the kernel code-style in
> amdgpu module.
> And also the ./scripts/checkpatch.pl did not throw any warning or error.
Will such information become more interesting for further evolution
in the affected software areas?
Regards,
Markus
There is no need to if check again, maybe we could merge
into the above else branch.
Signed-off-by: Bernard Zhao
Changes since V1:
*commit message improve
*code style refactoring
Changes since V2:
*code style adjust
Link for V1:
*https://lore.kernel.org/patchwork/patch/1226587/
---
VRAM manager and DRM MM when init failed, there is no operaction
to free kzalloc memory & remove device file.
This will lead to memleak & cause stability issue.
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 24
1 file changed, 19
From: Bernard Zhao
Date: 2020-04-21 10:07:50
To: Alex Deucher ,"Christian König"
,"David (ChunMing) Zhou" ,David
Airlie ,Daniel Vetter ,Lyude Paul
,Sam Ravnborg ,Bernard Zhao
,"José Roberto de Souza" ,Andrzej
Pietrasiewicz
> There is no need to if check again,
Thanks for this information.
* Should the function name be mentioned in this commit message?
* Would you like to adjust the patch subject another bit?
> maybe we could merge into the above else branch.
I suggest to reconsider this wording.
Are you still
Am 21.04.20 um 14:22 schrieb Bernard Zhao:
There is no need to if check again, maybe we could merge
into the above else branch.
Signed-off-by: Bernard Zhao
You could improve the subject line and commit message a bit, e.g.
something like:
[PATCH] drm/amdgpu: cleanup coding style in amdkfd
Am 21.04.20 um 14:09 schrieb 赵军奎:
From: "Christian König"
Date: 2020-04-21 19:22:49
To: Bernard Zhao ,Alex Deucher ,"David (ChunMing) Zhou"
,David Airlie ,Daniel Vetter ,Tom St Denis
,Ori Messinger ,Sam Ravnborg
At default, the autosuspend delay of audio controller is 3S. If the
gpu reset is triggered within 3S(after audio controller idle),
the audio controller may be unable into suspended state. Then
the sudden gpu reset will cause some audio errors. The change
here is targeted to resolve this.
However
Hi Monk,
at least on Vega that should be fine. If the RLC should use anything
else than 0 here we should update that together with the VMID.
Regards,
Christian.
Am 21.04.20 um 11:54 schrieb Liu, Monk:
Could only be that the firmware updates the bits to something non default, I'm
going to
Am 21.04.20 um 13:17 schrieb Bernard Zhao:
VRAM manager and DRM MM when init failed, there is no operaction
to free kzalloc memory & remove device file.
This will lead to memleak & cause stability issue.
NAK, failure to create sysfs nodes are not critical.
Christian.
Signed-off-by: Bernard
>>> Could only be that the firmware updates the bits to something non default,
>>> I'm going to double check that on a Vega10.
I think that will be a sure answer, otherwise why we need those field if we
always write 0 to them and reader always expect 0 reading back from them ??
Those fields
Am 21.04.20 um 11:45 schrieb Tao, Yintian:
-Original Message-
From: Christian König
Sent: 2020年4月21日 17:10
To: Liu, Monk ; Tao, Yintian ; He, Jacob
; amd-gfx@lists.freedesktop.org
Cc: Gu, Frans
Subject: [PATCH] drm/amdgpu: cleanup SPM VMID update
The RLC SPM configuration register
Christian
Many fields looks not like going to be still value at all, e.g.:
RLC_SPM_PERF_CNTR 5 0x0 PERF_CNTR that is used by RLC for
memory transactions
By your change you always set above filed to 0, is it right ? I really doubt
it
Beside: to make SRIOV VF less painful
Am 21.04.20 um 10:44 schrieb 赵军奎:
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 9dff792c9290..5424bd921a7b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++
-Original Message-
From: Christian König
Sent: 2020年4月21日 17:10
To: Liu, Monk ; Tao, Yintian ; He, Jacob
; amd-gfx@lists.freedesktop.org
Cc: Gu, Frans
Subject: [PATCH] drm/amdgpu: cleanup SPM VMID update
The RLC SPM configuration register contains the information how the memory
The RLC SPM configuration register contains the information how the memory
access is made (VMID, MTYPE, etc) which should always be consistent.
So instead of a read modify write cycle of the VMID always update
the whole register.
Signed-off-by: Christian König
---
Original idea is from Monk which only update spm vmid
at first time which can release the frequent r/w register
burden under virtualization.
v2: set spm_vmid_updated to false when job timedout
Signed-off-by: Yintian Tao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 3 +++
Am 21.04.20 um 10:03 schrieb Bernard Zhao:
There is no need to if check again, maybe we could merge
into the above else branch.
Signed-off-by: Bernard Zhao
Changes since V1:
*commit message improve
*code style refactoring
Changes since V2:
*code style adjust
Link for V1:
Am 21.04.20 um 09:36 schrieb Bernard Zhao:
Maybe we could reduce the mutex_lock(>lock)`s protected code area,
and no need to protect pr_debug.
Well that change looks rather superfluous to me.
This is for freeing memory which by definition can only be done once and
so the should be exactly
Am 21.04.20 um 04:41 schrieb Bernard Zhao:
There is no need to if check again, maybe we could merge
into the above else branch.
Signed-off-by: Bernard Zhao
---
Changes since V1:
*commit message improve
*code style refactoring
Link for V1:
*
Am 21.04.20 um 04:41 schrieb YueHaibing:
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c: In function amdgpu_job_submit:
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c:148:26: warning: variable priority set
but not used [-Wunused-but-set-variable]
commit 33abcb1f5a17 ("drm/amdgpu: set compute queue priority
Maybe we could reduce the mutex_lock(>lock)`s protected code area,
and noneed to protect pr_debug.
Signed-off-by: Bernard Zhao
Changes since V1:
*commit message improve
Link for V1:
*https://lore.kernel.org/patchwork/patch/1226588/
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 7
The "if(!encoder)" branch return the same value 0 of the success
branch, maybe return -EINVAL is more better.
Signed-off-by: Bernard Zhao
---
Changes since V1:
* commit message improve
---
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 14 +++---
1 file changed, 7 insertions(+), 7
There is no need to if check again, maybe we could merge
into the above else branch.
Signed-off-by: Bernard Zhao
---
Changes since V1:
*commit message improve
*code style refactoring
Link for V1:
* https://lore.kernel.org/patchwork/patch/1226587/
---
Maybe we could reduce the mutex_lock(>lock)`s protected code area,
and no need to protect pr_debug.
Signed-off-by: Bernard Zhao
Changes since V1:
*commit message improve
Changes since V2:
*move comment along with the mutex_unlock
Link for V1:
*https://lore.kernel.org/patchwork/patch/1226588/
From: Felix Kuehling
Date: 2020-04-21 12:24:19
To: 1587180037-113840-1-git-send-email-bern...@vivo.com,Alex Deucher
,"Christian König" ,"David
(ChunMing) Zhou" ,David Airlie ,Daniel
Vetter
,amd-gfx@lists.freedesktop.org,dri-de...@lists.freedesktop.org,linux-ker...@vger.kernel.org
Cc:
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c: In function amdgpu_job_submit:
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c:148:26: warning: variable priority set
but not used [-Wunused-but-set-variable]
commit 33abcb1f5a17 ("drm/amdgpu: set compute queue priority at mqd_init")
left behind this, remove it.
[AMD Public Use]
The series is: Reviewed-by: John Clements
-Original Message-
From: Chen, Guchun
Sent: Monday, April 20, 2020 8:56 PM
To: Zhang, Hawking ; amd-gfx@lists.freedesktop.org;
Deucher, Alexander ; Clements, John
Subject: RE: [PATCH 0/8] psp code clean up
[AMD Public Use]
61 matches
Mail list logo
