[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Kevin Wang
Best Regards,
Kevin
From: amd-gfx on behalf of Evan Quan
Sent: Wednesday, March 10, 2021 3:34 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Quan, Evan
Subject:
[AMD Public Use]
Reviewed-by: Evan Quan
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Wednesday, March 10, 2021 12:12 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH] drm/amdgpu/powerplay/smu10: add support for gpu busy query
Was added
For V1_0 and V1_1, they come with different size. Misuse may cause
out of memory access.
Change-Id: Icd06e673b9259d8d381301c145f0e9eff3408ee5
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
[AMD Official Use Only - Internal Distribution Only]
>>> But how this will help if TDR thread will start after you both took read
>>> lock and checked that adev->in_gpu_reset is false ? Since TDR now takes
>>> write lock only after suspending HW and waiting for all fences there is
>>> nothing
But how this will help if TDR thread will start after you both took read
lock and checked that adev->in_gpu_reset is false ? Since TDR now takes
write lock only after suspending HW and waiting for all fences there is
nothing that prevents both threads (e.g IOCTL and TDR) to access
registers
[AMD Official Use Only - Internal Distribution Only]
Hi Alex,
Hi Alex
We have a thread discussed the GOP driver with Xiong on headless SKUs. Just
forwarded that to you as well. He has confirmed this on that thread.
There's some NV ASICs which have VCN harvested. Those parts have the VGA class
[AMD Public Use]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Feifei Xu
Sent: Wednesday, March 10, 2021 12:38
To: amd-gfx@lists.freedesktop.org
Cc: Xu, Feifei ; Zhang, Hawking
Subject: [PATCH 2/2] drm/amdgpu: skip query VFCT table for headless ASICs
There
[AMD Public Use]
+ } else {
+ return -EOPNOTSUPP;
+ }
+ break;
The 'break' looks useless, as no chance arriving here.
Regards,
Guchun
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Wednesday, March 10,
On Tue, Mar 9, 2021 at 11:38 PM Feifei Xu wrote:
>
> There will be no GOP driver to copy vbios image to
> VFCT table for headless ASICs. Thus skip VFCT.
I'm not sure these patches are entirely correct.
>
> Signed-off-by: Feifei Xu
> Reviewed-by: Hawking Zhang
> ---
>
Add headless check function for NV and afterwards.
Signed-off-by: Feifei Xu
Reviewed-by: Hawking Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8
drivers/gpu/drm/amd/amdgpu/nv.c| 2 +-
There will be no GOP driver to copy vbios image to
VFCT table for headless ASICs. Thus skip VFCT.
Signed-off-by: Feifei Xu
Reviewed-by: Hawking Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Was added in newer versions of the firmware. Add support
for it.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/pm/inc/rv_ppsmc.h | 1 +
.../drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c | 30 ++-
2 files changed, 30 insertions(+), 1 deletion(-)
diff --git
Need to check the module variant as well.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
index
[AMD Official Use Only - Internal Distribution Only]
Hi, Christian,
Because register r/w functions are also used in ISR, we need add in_irq()
check. I updated this change in v3.
Best Regards
Dennis Li
-Original Message-
From: Christian König
Sent: Tuesday, March 9, 2021 8:57 PM
[AMD Official Use Only - Internal Distribution Only]
Hi, Andrey,
>>> Is the problem here that HW is suspended while some other threads that rely
>>> on the read side lock still access HW ? Mostly what I am thinking about are
>>> IOCTls - we can't 'wait for them to complete' but they might be
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Feifei Xu
-Original Message-
From: amd-gfx On Behalf Of shaoyunl
Sent: 2021年3月10日 上午 9:27
To: amd-gfx@lists.freedesktop.org
Cc: Liu, Shaoyun
Subject: [PATCH] drm/amdgpu: skip read eeprom for device that pending on
Read eeprom through SMU doesn't works stable on XGMI reset during test.
skip it for now
Signed-off-by: shaoyunl
Change-Id: Id864b96a9da5b0d4dd5ffef9858997dd9f52de25
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 6 ++
1 file changed, 6 insertions(+)
diff --git
On Tue, Mar 9, 2021 at 8:13 PM Andrey Grodzovsky
wrote:
>
> On 2021-03-09 1:51 p.m., Christian König wrote:
> > Am 09.03.21 um 19:26 schrieb Andrey Grodzovsky:
> >> On 2021-03-09 12:47 p.m., Christian König wrote:
> >>> No it won't. Accessing the hardware without the lock is ok as long as
> >>>
[AMD Official Use Only - Internal Distribution Only]
If you have a link to the userspace patches that use this, it would be good to
include in the patch description.
Alex
From: amd-gfx on behalf of Felix
Kuehling
Sent: Tuesday, March 9, 2021 3:06 PM
To:
[AMD Public Use]
Reviewed-by: Kent Russell
> -Original Message-
> From: amd-gfx On Behalf Of Felix
> Kuehling
> Sent: Tuesday, March 9, 2021 3:07 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Keely, Sean
> Subject: [PATCH 1/1] drm/amdkfd: Bump KFD API version
>
> Indicate the
Indicate the availability reliable SRAM EDC state in the new bit
in the device properties.
Signed-off-by: Felix Kuehling
---
include/uapi/linux/kfd_ioctl.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/kfd_ioctl.h b/include/uapi/linux/kfd_ioctl.h
index
On 2021-03-09 1:51 p.m., Christian König wrote:
Am 09.03.21 um 19:26 schrieb Andrey Grodzovsky:
On 2021-03-09 12:47 p.m., Christian König wrote:
No it won't. Accessing the hardware without the lock is ok as long as
the write side isn't taken.
Oh, forgot about the trylock part, sorry...
Am 09.03.21 um 19:26 schrieb Andrey Grodzovsky:
On 2021-03-09 12:47 p.m., Christian König wrote:
No it won't. Accessing the hardware without the lock is ok as long as
the write side isn't taken.
Oh, forgot about the trylock part, sorry...
But that approach is illegal anyway because we
Am 09.03.21 um 18:59 schrieb Alex Deucher:
On Tue, Mar 9, 2021 at 12:55 PM Jean-Philippe Brucker
wrote:
Hi Felix,
On Tue, Mar 09, 2021 at 11:30:19AM -0500, Felix Kuehling wrote:
I think the proper fix would be to not rely on custom hooks into a particular
IOMMU driver, but to instead ensure
On 2021-03-09 12:47 p.m., Christian König wrote:
No it won't. Accessing the hardware without the lock is ok as long as
the write side isn't taken.
Oh, forgot about the trylock part, sorry...
But that approach is illegal anyway because we suspend the hardware
without proper protection from
On Tue, Mar 9, 2021 at 12:55 PM Jean-Philippe Brucker
wrote:
>
> Hi Felix,
>
> On Tue, Mar 09, 2021 at 11:30:19AM -0500, Felix Kuehling wrote:
> > > I think the proper fix would be to not rely on custom hooks into a
> > > particular
> > > IOMMU driver, but to instead ensure that the amdgpu
Hi Felix,
On Tue, Mar 09, 2021 at 11:30:19AM -0500, Felix Kuehling wrote:
> > I think the proper fix would be to not rely on custom hooks into a
> > particular
> > IOMMU driver, but to instead ensure that the amdgpu driver can do everything
> > it needs through the regular linux/iommu.h
No it won't. Accessing the hardware without the lock is ok as long as
the write side isn't taken.
But that approach is illegal anyway because we suspend the hardware
without proper protection from concurrent access.
Christian.
Am 09.03.21 um 17:40 schrieb Andrey Grodzovsky:
Because he takes
On 3/9/21 6:43 PM, Christian König wrote:
Am 09.03.21 um 17:55 schrieb Nirmoy Das:
Implement amdgpu_bo_destroy_user() helper function to simplify
amdgpu_bo_user cleanup.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 19 +--
1 file changed, 13
Am 09.03.21 um 17:55 schrieb Nirmoy Das:
Implement amdgpu_bo_destroy_user() helper function to simplify
amdgpu_bo_user cleanup.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git
Yeah, sorry. I've seen your reply only after I wrote this mail.
I think we can go ahead if you don't have much other concern on this.
Christian.
Am 09.03.21 um 17:48 schrieb Andrey Grodzovsky:
I we are talking about 'PATCH v3] drm/amd/amdgpu implement tdr
advanced mode' which was sent
Am 09.03.21 um 17:19 schrieb Jonathan Kim:
Add IH function to allow caller to wait until ring entries are processed
until the checkpoint write pointer.
This will be primarily used by HMM to drain pending page fault interrupts
before memory unmap to prevent HMM from handling stale interrupts.
pm_message_t events seem to be the right thing to use here instead of
driver's privately managed power states. Please have a look
https://elixir.bootlin.com/linux/v4.7/source/drivers/gpu/drm/i915/i915_drv.c#L714
https://elixir.bootlin.com/linux/v4.7/source/drivers/gpu/drm/drm_sysfs.c#L43
Implement amdgpu_bo_destroy_user() helper function to simplify
amdgpu_bo_user cleanup.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
against the exported functions. If the GPU driver is built-in but the
IOMMU driver is a loadable module, the kfd_iommu.c file is indeed
built but does not work:
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in
I we are talking about 'PATCH v3] drm/amd/amdgpu implement tdr advanced
mode' which was sent yesterday then I already went over it and only had
2 cosmetical comments.
Andrey
On 2021-03-09 6:16 a.m., Christian König wrote:
Yeah, that are some really good points. I completely agree that we
This reverts commit 73bf5cad2696fe3a21f70101821405db839ea18e.
Fixed in newer firmware
Signed-off-by: Harish Kasiviswanathan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
Because he takes the write side lock post amdgpu_pre_asic_reset - where
HW suspend sequence happens (touching registers) - so i think it will
assert.
Andrey
On 2021-03-09 7:56 a.m., Christian König wrote:
Hi Dennis,
why do you think that this will always assert in reset thread?
In the
Am 2021-03-09 um 3:58 a.m. schrieb Arnd Bergmann:
> On Tue, Mar 9, 2021 at 4:23 AM Felix Kuehling wrote:
>> Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
>> against the exported functions. If the GPU driver is built-in but the
>> IOMMU driver is a loadable module, the
Add IH function to allow caller to wait until ring entries are processed
until the checkpoint write pointer.
This will be primarily used by HMM to drain pending page fault interrupts
before memory unmap to prevent HMM from handling stale interrupts.
v3: Scrap busy loop and change to wait_event.
[AMD Public Use]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: amd-gfx On Behalf Of shaoyunl
Sent: Tuesday, March 9, 2021 23:44
To: amd-gfx@lists.freedesktop.org
Cc: Liu, Shaoyun
Subject: [PATCH] drm/amdgpu : Fix asic reset regression issue introduce by
On Tue, Mar 9, 2021 at 1:19 AM Lazar, Lijo wrote:
>
> [AMD Public Use]
>
> This seems a duplicate of dev_pm_info states. Can't we reuse that?
Are you referring to the PM_EVENT_ messages in
dev_pm_info.power_state? Maybe. I was not able to find much
documentation on how those should be used.
This recent change introduce SDMA interrupt info printing with irq->process
function.
These functions do not require a set function to enable/disable the irq
Signed-off-by: shaoyunl
Change-Id: I595998b107f48865f47820ba2e7f758cc263dc64
---
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 2 +-
1 file
On Tue, Mar 9, 2021 at 8:17 AM Kenneth Feng wrote:
>
> Currently the pcie dpm has two problems.
> 1. Only the high dpm level speed/width can be overrided
> if the requested values are out of the pcie capability.
> 2. The high dpm level is always overrided though sometimes
> it's not necesarry.
>
Hi Christophe,
On Tue, Mar 9, 2021 at 10:58 AM Christophe Leroy
wrote:
> Le 09/03/2021 à 10:16, Geert Uytterhoeven a écrit :
> > On Tue, Mar 9, 2021 at 9:52 AM Christophe Leroy
> > wrote:
> >> Le 09/03/2021 à 09:45, Geert Uytterhoeven a écrit :
> >>> On Tue, Mar 9, 2021 at 9:39 AM Christophe
Hi Christophe,
On Tue, Mar 9, 2021 at 9:39 AM Christophe Leroy
wrote:
> Add stub instances of enable_kernel_vsx() and disable_kernel_vsx()
> when CONFIG_VSX is not set, to avoid following build failure.
>
> CC [M] drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.o
> In file included
Le 09/03/2021 à 10:16, Geert Uytterhoeven a écrit :
Hi Christophe,
On Tue, Mar 9, 2021 at 9:52 AM Christophe Leroy
wrote:
Le 09/03/2021 à 09:45, Geert Uytterhoeven a écrit :
On Tue, Mar 9, 2021 at 9:39 AM Christophe Leroy
wrote:
Add stub instances of enable_kernel_vsx() and
Add stub instances of enable_kernel_vsx() and disable_kernel_vsx()
when CONFIG_VSX is not set, to avoid following build failure.
CC [M] drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.o
In file included from
./drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services_types.h:29,
Le 09/03/2021 à 09:45, Geert Uytterhoeven a écrit :
Hi Christophe,
On Tue, Mar 9, 2021 at 9:39 AM Christophe Leroy
wrote:
Add stub instances of enable_kernel_vsx() and disable_kernel_vsx()
when CONFIG_VSX is not set, to avoid following build failure.
CC [M]
Hi Christophe,
On Tue, Mar 9, 2021 at 9:52 AM Christophe Leroy
wrote:
> Le 09/03/2021 à 09:45, Geert Uytterhoeven a écrit :
> > On Tue, Mar 9, 2021 at 9:39 AM Christophe Leroy
> > wrote:
> >> Add stub instances of enable_kernel_vsx() and disable_kernel_vsx()
> >> when CONFIG_VSX is not set, to
Am 09.03.21 um 15:33 schrieb Nirmoy:
On 3/9/21 1:39 PM, Christian König wrote:
Am 09.03.21 um 09:46 schrieb Nirmoy Das:
FB BO should not be ttm_bo_type_kernel type and
amdgpufb_create_pinned_object() pins the FB BO anyway.
Signed-off-by: Nirmoy Das
Acked-by: Christian König
---
On 3/9/21 1:39 PM, Christian König wrote:
Am 09.03.21 um 09:46 schrieb Nirmoy Das:
FB BO should not be ttm_bo_type_kernel type and
amdgpufb_create_pinned_object() pins the FB BO anyway.
Signed-off-by: Nirmoy Das
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 2 +-
Currently the pcie dpm has two problems.
1. Only the high dpm level speed/width can be overrided
if the requested values are out of the pcie capability.
2. The high dpm level is always overrided though sometimes
it's not necesarry.
Signed-off-by: Kenneth Feng
---
Hi Dennis,
why do you think that this will always assert in reset thread?
In the reset thread while we are holding the reset lock write side
lockdep_assert_held() should be satisfied and not cause any splat in the
system log.
Regards,
Christian.
Am 09.03.21 um 03:03 schrieb Li, Dennis:
Am 09.03.21 um 09:46 schrieb Nirmoy Das:
Tiling flag and metadata are only needed for BOs created by
amdgpu_gem_object_create(), so we can remove those from the
base class.
v2: * squash tiling_flags and metadata relared patches into one
* use BUG_ON for non ttm_bo_type_device type when
Am 09.03.21 um 09:46 schrieb Nirmoy Das:
Use amdgpu_bo_create_user() for all the BO allocations for
ttm_bo_type_device type.
v2: include amdgpu_amdkfd_alloc_gws() as well it calls amdgpu_bo_create()
for ttm_bo_type_device
CC: felix.kuehl...@amd.com
Signed-off-by: Nirmoy Das
Am 09.03.21 um 09:46 schrieb Nirmoy Das:
FB BO should not be ttm_bo_type_kernel type and
amdgpufb_create_pinned_object() pins the FB BO anyway.
Signed-off-by: Nirmoy Das
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 2 +-
1 file changed, 1 insertion(+), 1
Am 09.03.21 um 09:46 schrieb Nirmoy Das:
Implement a new struct amdgpu_bo_user as subclass of
struct amdgpu_bo and a function to created amdgpu_bo_user
bo with a flag to identify the owner.
v2: amdgpu_bo_to_amdgpu_bo_user -> to_amdgpu_bo_user()
Signed-off-by: Nirmoy Das
Reviewed-by:
Am 09.03.21 um 09:46 schrieb Nirmoy Das:
Allow allocating BO structures with different structure size
than struct amdgpu_bo.
v2: Check bo_ptr_size in all amdgpu_bo_create() caller.
CC: felix.kuehl...@amd.com
Signed-off-by: Nirmoy Das
Reviewed-by: Christian König
---
Yeah, that are some really good points. I completely agree that we
shouldn't do any larger cleanup right now.
But I think we still need some more review on this. I most likely won't
have enough time to look into this before the weekend.
Andrey can you take a look as well?
Thanks,
Christian.
[AMD Public Use]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Wang, Kevin(Yang)
Sent: Tuesday, March 9, 2021 18:32
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Wang, Kevin(Yang)
Subject: [PATCH] Revert "drm/amdgpu: add psp RAP L0 check support"
This reverts commit a77e3752c319e479c538a84c3b0f6d87f6fa4bc7.
Disable PSP RAP L0 self test until to RAP feature ready.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
Am 08.03.21 um 22:09 schrieb Kim, Jonathan:
[SNIP]
First of all rptr/wptr are not 32bit, their maximum is 20 or 19 bits IIRC (and
they are dw, so 4M or 2M bytes).
Thanks Christian. This makes sense now. I can see how rptrs advance by dword
sets in the iv decode helper.
My apologies, but
On 2021-03-08 9:38 p.m., Kazlauskas, Nicholas wrote:
> On 2021-03-08 3:18 p.m., Daniel Vetter wrote:
>> On Fri, Mar 5, 2021 at 10:24 AM Michel Dänzer wrote:
>>>
>>> On 2021-03-04 7:26 p.m., Kazlauskas, Nicholas wrote:
It's a little odd that a disable commit can fail, but I don't think
On Tue, Mar 9, 2021 at 4:23 AM Felix Kuehling wrote:
>
> Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
> against the exported functions. If the GPU driver is built-in but the
> IOMMU driver is a loadable module, the kfd_iommu.c file is indeed
> built but does not work:
>
Tiling flag and metadata are only needed for BOs created by
amdgpu_gem_object_create(), so we can remove those from the
base class.
v2: * squash tiling_flags and metadata relared patches into one
* use BUG_ON for non ttm_bo_type_device type when accessing
tiling_flags and metadata._
v3:
Use amdgpu_bo_create_user() for all the BO allocations for
ttm_bo_type_device type.
v2: include amdgpu_amdkfd_alloc_gws() as well it calls amdgpu_bo_create()
for ttm_bo_type_device
CC: felix.kuehl...@amd.com
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 4 +++-
Allow allocating BO structures with different structure size
than struct amdgpu_bo.
v2: Check bo_ptr_size in all amdgpu_bo_create() caller.
CC: felix.kuehl...@amd.com
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c| 2 ++
FB BO should not be ttm_bo_type_kernel type and
amdgpufb_create_pinned_object() pins the FB BO anyway.
Signed-off-by: Nirmoy Das
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Implement a new struct amdgpu_bo_user as subclass of
struct amdgpu_bo and a function to created amdgpu_bo_user
bo with a flag to identify the owner.
v2: amdgpu_bo_to_amdgpu_bo_user -> to_amdgpu_bo_user()
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 28
Fix the following coccicheck warnings:
./drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dpp_cm.c:896:68-73:
WARNING: conversion to bool not needed here.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dpp_cm.c | 2 +-
1 file changed, 1
71 matches
Mail list logo
