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/
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gp
Maybe we could reduce the mutex_lock(&mem->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/12265
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: openso
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]
This is basically just some code cosmetic. The current design
for XGMI setup gput reset is to operate on current device(adev)
first and then on other devices from the hive(by another 'for' loop).
But actually we can do some sort to the device list(to put current
device 1st position) and handle all
Make code more readable.
Change-Id: I28444f285b23aac16be421e3447d0de6c3a57ee8
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/
As for XGMI setup, it should be performed on other devices
from the hive also.
Change-Id: I08554c27216efa21c2c46c0b3379d856b5264c9e
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_devi
As for XGMI setup, it needs to be performed on
all the devices from the same hive.
Change-Id: I25e6364d31f0b34938cf424a410628aa54dd2edd
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/
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 basically code cosmetic.
Evan Quan (4):
drm/amdgpu: correct fbdev suspend on gpu reset
drm/amdgpu: correct cancel_delayed_work_syn
[AMD Official Use Only - Internal Distribution Only]
From: Christian König
Sent: Monday, April 20, 2020 11:45 PM
To: Wang, Kevin(Yang) ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Koenig, Christian
Subject: Re: [PATCH] drm/amdgpu: clean up unused
Hi Bernard,
Please see comments inline.
Am 2020-04-20 um 10:41 p.m. 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
>
> L
Hi Bernard,
Thank you for the patch. Please see some comments inline.
Am 2020-04-20 um 10:25 p.m. schrieb Bernard Zhao:
> Maybe we could reduce the mutex_lock(&mem->lock)`s protected code area,
> and noneed to protect pr_debug.
Typo: noneed -> no need
>
> Signed-off-by: Bernard Zhao
>
> Chang
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Emily Deng
>-Original Message-
>From: amd-gfx On Behalf Of Gu,
>JiaWei (Will)
>Sent: Tuesday, April 21, 2020 11:56 AM
>To: Gu, JiaWei (Will) ; amd-gfx@lists.freedesktop.org
>Subject: RE: [PATCH] SWDEV-231280 CentOS-AWS Gu
[AMD Official Use Only - Internal Distribution Only]
Ping..
-Original Message-
From: Jiawei
Sent: Monday, April 20, 2020 7:34 PM
To: amd-gfx@lists.freedesktop.org
Cc: Gu, JiaWei (Will)
Subject: [PATCH] SWDEV-231280 CentOS-AWS Guest driver reload 3 failed with call
trace in guest
Am 2020-04-18 um 8:28 a.m. schrieb Amber Lin:
> When the compute is malfunctioning or performance drops, the system admin
> will use SMI (System Management Interface) tool to monitor/diagnostic what
> went wrong. This patch provides an event watch interface for the user
> space to register devices
On Mon, Apr 20, 2020 at 9:45 PM Michel Dänzer wrote:
> On 2020-04-20 6:04 p.m., uday kiran pichika wrote:
> >
> > Even in amdgpu_present_flip(), there is a check
> > for amdgpu_window_has_variable_refresh() which actually checks whether
> > window has a variable_refresh property set from the MESA
Thanks for the information Michel.
Even in amdgpu_present_flip(), there is a check
for amdgpu_window_has_variable_refresh() which actually checks whether
window has a variable_refresh property set from the MESA or not ? this
check is failing in my case and never calls amdgpu_present_set_screen_vrr
On Mon, Apr 20, 2020 at 10:45 AM Luben Tuikov wrote:
>
> On 2020-04-20 6:16 a.m., Hawking Zhang wrote:
> > It is not allowed to read out engine sram via registers
> > to check the fw loading status.
> >
>
> Who or what is "It"--do you mean "The driver"?
>
The driver can't access these registers o
On 2020-04-20 6:45 p.m., uday kiran pichika wrote:
> On Mon, Apr 20, 2020 at 9:45 PM Michel Dänzer wrote:
>> On 2020-04-20 6:04 p.m., uday kiran pichika wrote:
>>>
>>> Even in amdgpu_present_flip(), there is a check
>>> for amdgpu_window_has_variable_refresh() which actually checks whether
>>> win
Am 2020-04-20 um 3:42 a.m. schrieb Tao, Yintian:
> Hi Felix
>
> I have one question about function kgd_gfx_v9_hiq_mqd_load(). I see it
> directly write contents into kiq ring and not wait for the fence. Do you know
> how KFD know the hiq_mqd_load complete? Thanks in advance.
That's probably a b
On 2020-04-20 6:04 p.m., uday kiran pichika wrote:
>
> Even in amdgpu_present_flip(), there is a check
> for amdgpu_window_has_variable_refresh() which actually checks whether
> window has a variable_refresh property set from the MESA or not ? this
> check is failing in my case and never calls amd
Am 20.04.20 um 17:27 schrieb Kevin Wang:
clean up unused variable:
1. ring_lru_list
2. ring_lru_list_lock
related-commit:
drm/amdgpu: remove ring lru handling
Signed-off-by: Kevin Wang
Reviewed-by: Christian König
Found by accident or used some tool? I'm asking because I'm pretty sure
we
On 2020-04-20 6:16 a.m., Hawking Zhang wrote:
> driver already had psp_firmware_header struture to
> deal with different layout of sos ucode. the sos
> micorcode initialization could be common one.
>
> Signed-off-by: Hawking Zhang
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 70
> +
On 2020-04-20 11:29 a.m., Luben Tuikov wrote:
> On 2020-04-20 6:16 a.m., Hawking Zhang wrote:
>> asd is unified ucode across asic. it is not necessary
>> to keep its software structure to be ip specific one
>
> Sentences usually start with a capital letter.
> "ASD is unified uCode across ASICs."
>
On Sat, Apr 18, 2020 at 7:13 AM Mikhail Gavrilov
wrote:
>
> On Sat, 11 Apr 2020 at 14:56, Christian König
> wrote:
> >
> > Yeah, that is a known issue.
> >
> > You could try the attached patch, but please be aware that it is not
> > even compile tested because of the Easter holidays here.
> >
>
>
On 2020-04-20 6:16 a.m., Hawking Zhang wrote:
> asd is unified ucode across asic. it is not necessary
> to keep its software structure to be ip specific one
Sentences usually start with a capital letter.
"ASD is unified uCode across ASICs."
The second sentence uses "it" twice and it is not clear
w
clean up unused variable:
1. ring_lru_list
2. ring_lru_list_lock
related-commit:
drm/amdgpu: remove ring lru handling
Signed-off-by: Kevin Wang
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 ---
2 files changed, 6 deletions(-)
diff --git
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Joseph Gravenor
From: Liu, Zhan
Sent: Friday, April 17, 2020 1:17 PM
To: Liu, Zhan ; amd-gfx@lists.freedesktop.org
; Gravenor, Joseph
Subject: RE: [PATCH] drm/amd/display: Remove aconnector condi
[AMD Official Use Only - Internal Distribution Only]
I didn't calculate the exact required DW used for on e kiq read ( currently
use 32 DW) , That's assume it's right , Can we just alloc 2 more here ? Since
each kiq_read will do the allocation , it won't conflict with other read
operation.
On 04/19, Christian König wrote:
> Am 17.04.20 um 23:43 schrieb Rodrigo Siqueira:
> > Hi,
> >
> > Wyatt made the below patch for fixing this issue. I can apply it on top
> > of this patchset if you all agree.
> >
> > [Why]
> > Current code does not guarantee the correct endianness of memory being
From: Colin Ian King
Currently pointer hive is being dereferenced before it is being null
checked and hence can lead to null pointer dereference issues. Fix this
by only dereferencing pointer hive after it has been null checked.
Addresses-Coverity: ("Dereference before null check")
Fixes: 25d427
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c: In function gfx_v10_rlcg_wreg:
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c:1291:18: warning: variable grbm_idx set
but not used [-Wunused-but-set-variable]
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c:1290:18: warning: variable grbm_cntl set
but not used [-Wunused-but
On 2020-04-20 6:16 a.m., Hawking Zhang wrote:
> It is not allowed to read out engine sram via registers
> to check the fw loading status.
>
Who or what is "It"--do you mean "The driver"?
Abbreviations should be capitalized: SRAM, ASIC, etc.
Regards,
Luben
> Signed-off-by: Hawking Zhang
> ---
On 2020-04-20 6:12 a.m., uday kiran pichika wrote:
> Hello Team,
>
> I'm working on adding Adaptive Sync feature in Xserver/modesetting. When
> understanding the existing AMD's implementation, I've few doubts regarding
> the vrr property being set on the Window from MESA.
>
> I have made the modi
kvfree ensure that the null pointer will do nothing.
If addr is NULL, first is_vmalloc_addr will not enter,
and kfree function just return when addr is NULL. There
will be no risk here.
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 3 +--
1 file changed, 1 insertion(+)
Hi, all:
When reviewing function radeon_user_framebuffer_create, what if
obj->import_attach is not NULL, it return directly without release obj
reference holded in function drm_gem_object_lookup.
it is a memleak of obj.
static struct drm_framebuffer *
radeon_user_framebuffer_create(struct drm_
[AMD Public Use]
Acked-by: Alex Deucher
From: amd-gfx on behalf of Marek Olšák
Sent: Friday, April 17, 2020 9:06 PM
To: amd-gfx mailing list
Subject: drm/amdgpu: add tiling flags from Mesa
Hi,
This is needed for displayable DCC on gfx10. Mesa will add the fi
[AMD Public Use]
The series is: Reviewed-by: Guchun Chen
Regards,
Guchun
-Original Message-
From: Zhang, Hawking
Sent: Monday, April 20, 2020 6:17 PM
To: amd-gfx@lists.freedesktop.org; Deucher, Alexander
; Clements, John ; Chen,
Guchun
Cc: Zhang, Hawking
Subject: [PATCH 0/8] psp c
Hi Christian
Yes, because only pp_one_vf mode can run RGP. And according to Jacob’s comments,
only when running RGP benchmark then UMD will enable this feature, Otherwise
UMD will not enable this feature.
Therefore, Multi-VF will never enter into this case.
Best Regards
Yintian Tao
From: Ko
Monk needs to answer this, but I don't think that this will work.
This explanation even sounds like only one VF can use the feature at the
same time, is that correct?
Regards,
Christian.
Am 20.04.20 um 14:08 schrieb Tao, Yintian:
Hi Monk, Christian
According to the discussion with Jacob o
Add Monk
-Original Message-
From: Yintian Tao
Sent: 2020年4月20日 20:37
To: Koenig, Christian ; monk@amd.co
Cc: amd-gfx@lists.freedesktop.org; Tao, Yintian
Subject: [PATCH] drm/amdgpu: update spm register through mmio
According to UMD design, only running performance analysis benchmar
According to UMD design, only running performance analysis
benchmark just like RGP, GPA and so on need to update spm
register and others will not support this feature.
Therefore, we can directly access spm register through mmio.
Signed-off-by: Yintian Tao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm
Hi Monk, Christian
According to the discussion with Jacob offline, UMD will only enable SPM
feature when testing RGP.
And under virtualization , only pp_one_vf mode can test RGP.
Therefore, whether we can directly use MMIO to READ/WRITE register for
RLC_SPM_MC_CNTL?
Best Regards
Yintian Tao
That's what we did initially, but we need to use the KIQ in atomic
context and that doesn't work with the scheduler.
Additional to that the scheduler has the same problem as the direct
submit, you need to know how what the maximum dw is a job could take.
Christian.
Am 20.04.20 um 11:28 schri
call common helper function to initialize asd ucode
Signed-off-by: Hawking Zhang
---
drivers/gpu/drm/amd/amdgpu/psp_v10_0.c | 17 +
drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 20 ++--
drivers/gpu/drm/amd/amdgpu/psp_v12_0.c | 27 +--
drivers/g
It is not allowed to read out engine sram via registers
to check the fw loading status.
Signed-off-by: Hawking Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 34
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h | 7 --
drivers/gpu/drm/amd/amdgpu/psp_v10_0.c | 124 ---
asd is unified ucode across asic. it is not necessary
to keep its software structure to be ip specific one
Signed-off-by: Hawking Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 36 +
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h | 2 ++
2 files changed, 38 inserti
tOS version is available through debugfs interface
Signed-off-by: Hawking Zhang
---
drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 10 ++
drivers/gpu/drm/amd/amdgpu/psp_v12_0.c | 5 +
drivers/gpu/drm/amd/amdgpu/psp_v3_1.c | 5 +
3 files changed, 4 insertions(+), 16 deletions(-)
dif
retired those early sos version used in vega10 bring up
phase
Signed-off-by: Hawking Zhang
---
drivers/gpu/drm/amd/amdgpu/psp_v3_1.c | 28 +---
1 file changed, 1 insertion(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v3_1.c
b/drivers/gpu/drm/amd/amdgp
driver already had psp_firmware_header struture to
deal with different layout of sos ucode. the sos
micorcode initialization could be common one.
Signed-off-by: Hawking Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 70 +
drivers/gpu/drm/amd/amdgpu/amdgpu_psp
call common helper function to init sos ucode, instead
of duplicate codes per ip version
Signed-off-by: Hawking Zhang
---
drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 56 ++
drivers/gpu/drm/amd/amdgpu/psp_v3_1.c | 34 ++---
2 files changed, 6 insertio
the seires make cleanup in current software psp
support, including:
1). retire unnecessary ip callback function like
support_vmr_ring, check_fw_loading.
2). remove unnecessary tOS version check
3). create common helper functions to avoid duplicate
code per IP generation
Hawking Zhang (8):
drm/am
vmr ring is dedicated for sriov vf (i.e.guest driver
in sriov), which is general communication interface
between driver and psp fw accross all ip version.
it is not correct to make it as ip specific callback.
it is even worse to check specific tOS version per IP
version (like psp_v11/v12).
Signed-
So why don't we let gpu scheduler to manage KIQ, and all client of KIQ need to
submit jobs within an IB ?
_
Monk Liu|GPU Virtualization Team |AMD
-Original Message-
From: Christian König
Sent: Monday, April 20, 2020 4:48 PM
To: Liu, Monk ; Koenig,
Hi Monk,
yeah, that is certainly problematic. But we have some maximum size for
the KIQ submission, don't we?
The only alternative would be to double check the rptr before we
allocate space on the ring buffer, but this means quite some additional
overhead.
Regards,
Christian.
Am 20.04.20
No, that's not true
The problem is not we submit commands on KIQ ring before the emiited ones are
signaled , instead it is because we don't have a unified command submit size on
KIQ
e.g.:
---JOB1---JOB2---JOB3---JOB4--->>
If job1 signaled and job 2/3/4 are running, by (your) design driver is a
Christian
What we want to do is like:
Read reg value from RLC_SPM_MC_CNTL to tmp
Set bits:3:0 to VMID to tmp
Write tmp to RLC_SPM_MC_CNTL
I didn't find any PM4 packet on GFX9/10 can achieve above goal
_
Monk Liu|GPU Virtualization Team |AMD
[sig-cloud-g
Good catch, yes that error handling seems to leak the buffer handle in
this case.
Feel free to provide a patch to fix this and CC me.
Regards,
Christian.
Am 20.04.20 um 09:37 schrieb 亿一:
Hi, all:
When reviewing function radeon_user_framebuffer_create, what if
obj->import_attach is not N
That is actually only a problem because the KIQ uses polling waits.
See amdgpu_fence_emit() waits for the oldest possible fence to be
signaled before emitting a new one.
I suggest that we do the same in amdgpu_fence_emit_polling(). A one
liner like the following should be enough:
amdgpu_fen
Sure, that's fine
Do you have particular suggestion for problem 2 ? how we avoid commands being
overwritten before it's finished
_
Monk Liu|GPU Virtualization Team |AMD
-Original Message-
From: Christian König
Sent: Monday, April 20, 2020 4:17 P
Yintian's patch has nothing to do with the result you mentioned the
command being overwritten by new initiated commands is a inherent bug, why you
put those two stuff together ?
Yintian patch made the situation absolutely worse. Instead of a whole
ring buffer wrap around to overwrite thi
Reviewed-by: Evan Quan
-Original Message-
From: Jiansong Chen
Sent: Monday, April 20, 2020 4:05 PM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan ; Zhang, Jack (Jian) ;
Chen, Jiansong (Simon)
Subject: [PATCH] drm/amd/powerplay: limit smu support to Arcturus for onevf
Under onevf mod
Under onevf mode the smu support to other chips is not well
verified yet.
Change-Id: Idbc166bea203cabba7615a255541eb283f18e1a0
Signed-off-by: Jiansong Chen
---
drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/p
I would also prefer to update the SPM VMID register using PM4 packets
instead of the current handling.
Regards,
Christian.
Am 20.04.20 um 09:50 schrieb Liu, Monk:
I just try to explain what I want to do here, no real patch formalized
yet
_
Monk Liu|GPU
I just try to explain what I want to do here, no real patch formalized yet
_
Monk Liu|GPU Virtualization Team |AMD
[sig-cloud-gpu]
From: He, Jacob
Sent: Monday, April 20, 2020 3:45 PM
To: Liu, Monk ; Koenig, Christian
Cc: amd-gfx@lists.freedesktop.org
Subject
[AMD Official Use Only - Internal Distribution Only]
Do you miss a file which adds spm_updated to vm structure?
From: Liu, Monk
Sent: Monday, April 20, 2020 3:32 PM
To: He, Jacob ; Koenig, Christian
Cc: amd-gfx@lists.freedesktop.org
Subject: why we need to do in
Hi Christian
This patch has not been merged because it is still under discussion among you,
Monk and Felix.
Instead of this crude hack please let us just allocate a fixed number of write
back slots and use them round robin. Then we can make sure that we don't have
more than a fixed number of
>>> Instead of this crude hack please let us just allocate a fixed number of
>>> write back slots and use them round robin
It looks doable but really ugly compared with current patch ... and more over
there we are going to fix the second problem eventually
What about let Yintian to provide one
>>> Previously we ended up with an invalid value in a concurrent register read,
>>> now the KIQs overwrites its own commands and most likely causes a hang or
>>> the hardware to execute something random.
Yintian's patch has nothing to do with the result you mentioned the
command being over
Hi Jaco & Christian
As titled , check below patch:
commit 10790a09ea584cc832353a5c2a481012e5e31a13
Author: Jacob He
Date: Fri Feb 28 20:24:41 2020 +0800
drm/amdgpu: Update SPM_VMID with the job's vmid when application reserves
the vmid
SPM access the video memory according to SPM_VM
Hi Monk,
Can we first get the first problem done ?
Please absolutely not! See the problem introduced here is quite worse
than the actual fix.
Previously we ended up with an invalid value in a concurrent register
read, now the KIQs overwrites its own commands and most likely causes a
hang
72 matches
Mail list logo
