[ 584.110304]
[ 584.110590] WARNING: possible recursive locking detected
[ 584.110876] 5.6.0-deli-v5.6-2848-g3f3109b0e75f #1 Tainted: G OE
[ 584.64]
[ 584.111456] kworker/38:1/553 is trying
Am 06.08.20 um 09:02 schrieb Dennis Li:
[ 584.110304]
[ 584.110590] WARNING: possible recursive locking detected
[ 584.110876] 5.6.0-deli-v5.6-2848-g3f3109b0e75f #1 Tainted: G OE
[ 584.64]
On Thu, Aug 06, 2020 at 09:36:41AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> On Wed, 05 Aug 2020 15:19:38 -0700 Joe Perches wrote:
> >
> > On Wed, 2020-08-05 at 17:27 -0400, Alex Deucher wrote:
> > > On Wed, Aug 5, 2020 at 4:53 PM Joe Perches wrote:
> > > > On Wed, 2020-08-05 at 16:01 -0400
For VF, registers L2_CNTL, L2_CONTEXT1_IDENTITY_APERTURE
L2_PROTECTION_FAULT_CNTL are not accesible, skip the
configuration for them in SRIOV mode.
Signed-off-by: Liu ChengZhe
---
drivers/gpu/drm/amd/amdgpu/gfxhub_v2_1.c | 12 ++--
drivers/gpu/drm/amd/amdgpu/mmhub_v2_0.c | 12 ++
Hi all,
On Wed, 05 Aug 2020 15:19:38 -0700 Joe Perches wrote:
>
> On Wed, 2020-08-05 at 17:27 -0400, Alex Deucher wrote:
> > On Wed, Aug 5, 2020 at 4:53 PM Joe Perches wrote:
> > > On Wed, 2020-08-05 at 16:01 -0400, Alex Deucher wrote:
> > > > On Wed, Aug 5, 2020 at 7:35 AM Colin King
> >
[AMD Official Use Only - Internal Distribution Only]
Hi, Christian,
I agree with your concern. However we shouldn't rely on system to detect
dead-lock, and should consider this when doing code implementation. In fact,
dead-lock detection isn't enabled by default.
For your proposal t
Preventing locking problems during implementation is obviously a good
approach, but lockdep has proven to be massively useful for finding and
fixing problems.
Disabling lockdep splat by annotating lock with separate classes is
usually a no-go and only allowed if there is no other potential app
[AMD Public Use]
> -Original Message-
> From: Siqueira, Rodrigo
> Sent: Wednesday, August 5, 2020 10:55 PM
> To: Lin, Wayne
> Cc: amd-gfx@lists.freedesktop.org; Lakha, Bhawanpreet
> ; Wu, Hersen ;
> Kazlauskas, Nicholas ; Zuo, Jerry
>
> Subject: Re: [PATCH] drm/amd/mst: clean DP ma
Access the exported P2P dmabuf over XGMI, if available.
Otherwise, fall back to the existing PCIe method.
Signed-off-by: Arunpravin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 34 +
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h | 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_v
Am 06.08.20 um 11:04 schrieb Arunpravin:
Access the exported P2P dmabuf over XGMI, if available.
Otherwise, fall back to the existing PCIe method.
Signed-off-by: Arunpravin
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 34 +
drivers/g
[AMD Official Use Only - Internal Distribution Only]
Hi, Christian,
For this case, it is safe to use separated lock key. Please see the
definition of init_rwsem as the below. Every init_rwsem calling will use a new
static key, but devices of the hive share the same code to do initializatio
I think it is a limitation of init_rwsem.
And exactly that's wrong, this is intentional and perfectly correct.
As far as I know it is perfectly possible that the locks in the hive are
not always grabbed in the same order. And that's why lockdep is
complaining about this.
What we should do i
From: Likun Gao
Update drive if file for sienna_cichlid.
Signed-off-by: Likun Gao
Change-Id: If405461cfbe0133ceb61fa123272b2e53db99755
---
.../drm/amd/powerplay/inc/smu11_driver_if_sienna_cichlid.h | 6 +++---
drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h | 2 +-
2 files changed
From: Likun Gao
Swith default gpu reset method for sienna_cichlid to MODE1 reset.
Signed-off-by: Likun Gao
Change-Id: I775e5a66bbac474f65ca8c999136ccaf9c1dc14e
---
drivers/gpu/drm/amd/amdgpu/nv.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/am
[AMD Official Use Only - Internal Distribution Only]
Hi, Christian,
See my below comments.
Best Regards
Dennis Li
-Original Message-
From: Koenig, Christian
Sent: Thursday, August 6, 2020 5:19 PM
To: Li, Dennis ; amd-gfx@lists.freedesktop.org; Deucher,
Alexander ; Kuehling, Feli
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Kenneth Feng
在 2020/8/6 下午5:42，“Gao, Likun” 写入:
From: Likun Gao
Update drive if file for sienna_cichlid.
Signed-off-by: Likun Gao
Change-Id: If405461cfbe0133ceb61fa123272b2e53db99755
---
.../drm/amd
[SNIP]
I think it is a limitation of init_rwsem.
And exactly that's wrong, this is intentional and perfectly correct.
[Dennis Li] I couldn't understand. Why is it a perfectly correct?
For example, we define two rw_sem: a and b. If we don't check init_rwsem
definition, we may think case#1 and
[AMD Official Use Only - Internal Distribution Only]
[SNIP]
>> I think it is a limitation of init_rwsem.
> And exactly that's wrong, this is intentional and perfectly correct.
>
> [Dennis Li] I couldn't understand. Why is it a perfectly correct?
> For example, we define two rw_sem: a and b. If we
We need to allocate that manually now.
Signed-off-by: Christian König
Fixes: 2ddef17678bc (HEAD) drm/ttm: make TT creation purely optional v3
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_tt
Am 06.08.20 um 13:38 schrieb Li, Dennis:
[AMD Official Use Only - Internal Distribution Only]
[SNIP]
I think it is a limitation of init_rwsem.
And exactly that's wrong, this is intentional and perfectly correct.
[Dennis Li] I couldn't understand. Why is it a perfectly correct?
For example, we
On 2020-08-06 2:56 p.m., Christian König wrote:
> We need to allocate that manually now.
>
> Signed-off-by: Christian König
> Fixes: 2ddef17678bc (HEAD) drm/ttm: make TT creation purely optional v3
Reviewed-by: Michel Dänzer
Tested-by: Michel Dänzer
Thanks!
--
Earthling Michel Dänzer
This is a separate object we work within TTM.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 8 +-
drivers/gpu/drm/nouveau/nouveau_bo.c | 4 +-
drivers/gpu/drm/radeon/radeon_ttm.c| 4 +-
dri
The object flags created in radeon_ttm_placement_from_domain take care that
we use the correct caching for AGP, this is just superflous.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_ttm.c | 21 ++---
1 file changed, 2 insertions(+), 19 deletions(-)
diff --git
The names get/put are associated with reference counting
in the Linux kernel, use alloc/free instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 6 +++---
drivers/gpu/drm/nouveau/nouveau_ttm.c
[AMD Public Use]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Gao, Likun
Sent: Thursday, August 6, 2020 17:43
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Feng, Kenneth
; Sheng, Wenhui ; Gao, Likun
Subject: [PATCH] drm/amdgpu: use mode1 reset by def
On 2020-08-05 4:37 p.m., Rodrigo Siqueira wrote:
Hi,
I have some minor inline comments, but everything looks fine when I
tested it on Raven; feel free to add
Tested-by: Rodrigo Siqueira
in the whole series.
Thanks for the reviews!
I can clean up the nitpicks for this patch and make a v2.
when function arcturus_get_smu_metrics_data() call failed,
it will cause the variable "throttler_status" isn't initialized before use.
warning:
powerplay/arcturus_ppt.c:2268:24: warning: ‘throttler_status’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
2268 | if (throttler_
the entity isn't needed when vm use cpu to update page table.
Signed-off-by: Kevin Wang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 45 ++
1 file changed, 25 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu
On Thu, Aug 6, 2020 at 11:59 AM Kevin Wang wrote:
>
> when function arcturus_get_smu_metrics_data() call failed,
> it will cause the variable "throttler_status" isn't initialized before use.
>
> warning:
> powerplay/arcturus_ppt.c:2268:24: warning: ‘throttler_status’ may be used
> uninitialized i
NAK, we also use the entity context number for debugging.
Additional to this the entities should not need any additional resources. So
the functions are only initializing fields.
Regards,
Christian.
Am 06.08.2020 18:06 schrieb "Wang, Kevin(Yang)" :
the entity isn't needed when vm use cpu to up
On 2020-08-05 5:11 p.m., Rodrigo Siqueira wrote:
On 07/30, Nicholas Kazlauskas wrote:
[Why]
Enabling or disable DCC or switching between tiled and linear formats
can require bandwidth updates.
They're currently skipping all DC validation by being treated as purely
surface updates.
[How]
Treat
On 2020-08-05 4:45 p.m., Rodrigo Siqueira wrote:
On 07/30, Nicholas Kazlauskas wrote:
[Why]
MEDIUM or FULL updates can require global validation or affect
bandwidth. By treating these all simply as surface updates we aren't
actually passing this through DC global validation.
[How]
There's curre
Yes, that's fine. Thanks for fix.
Reviewed-by: Luben Tuikov
On 2020-08-05 9:31 p.m., Dennis Li wrote:
> Make sure to unlock the mutex when error happen
>
> v2:
> 1. correct syntax error in the commit comment
> 2. remove change-Id
>
> Acked-by: Nirmoy Das
> Signed-off-by: Dennis Li
>
> diff
On 2020-08-06 3:40 a.m., Liu ChengZhe wrote:
> For VF, registers L2_CNTL, L2_CONTEXT1_IDENTITY_APERTURE
> L2_PROTECTION_FAULT_CNTL are not accesible, skip the
Spelling: "accessible".
I'd rather move the "For VF" to the end, after "accessible",
like this. I also believe it should be "to VF" as opp
On Thu, 6 Aug 2020 at 23:51, Christian König
wrote:
>
> The names get/put are associated with reference counting
> in the Linux kernel, use alloc/free instead.
>
Sounds good,
Reviewed-by: Dave Airlie
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 4
On Thu, 6 Aug 2020 at 23:51, Christian König
wrote:
>
> This is a separate object we work within TTM.
Reviewed-by: Dave Airlie
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 8 +-
> drivers/gpu/dr
On Thu, 6 Aug 2020 at 23:51, Christian König
wrote:
>
> The object flags created in radeon_ttm_placement_from_domain take care that
> we use the correct caching for AGP, this is just superflous.
>
> Signed-off-by: Christian König
Reviewed-by: Dave Airlie
> ---
> drivers/gpu/drm/radeon/radeon_
[AMD Public Use]
> [SNIP]
>>> I think it is a limitation of init_rwsem.
>> And exactly that's wrong, this is intentional and perfectly correct.
>>
>> [Dennis Li] I couldn't understand. Why is it a perfectly correct?
>> For example, we define two rw_sem: a and b. If we don't check init_rwsem
>> de
From: "Tianci.Yin"
On Navi1x, the SPM golden settings are lost after GFXOFF
enter/exit, so reconfiguration is needed. Make the
configuration code as an interface for future use.
Change-Id: I172f3dc7f59da69b0364052dcad75a9c9aab019e
Reviewed-by: Luben Tuikov
Reviewed-by: Feifei Xu
Signed-off-by:
From: "Tianci.Yin"
On Navi1x, the SPM golden settings are lost after GFXOFF
enter/exit, so reconfigure the golden settings after GFXOFF
exit.
Change-Id: I9358ba9c65f241c36f8a35916170b19535148ee9
Signed-off-by: Tianci.Yin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 8 +++-
1 file changed,
[AMD Public Use]
Series is
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Tianci Yin
Sent: Friday, August 7, 2020 10:37
To: amd-gfx@lists.freedesktop.org
Cc: Tuikov, Luben ; Deucher, Alexander
; Zhang, Hawking ; Xu, Feifei
; Hesik, Christopher ; Swamy,
Manjuna
[AMD Public Use]
Please check one comment inline.
Regards,
Guchun
-Original Message-
From: Tianci Yin
Sent: Friday, August 7, 2020 10:37 AM
To: amd-gfx@lists.freedesktop.org
Cc: Tuikov, Luben ; Deucher, Alexander
; Zhang, Hawking ; Xu, Feifei
; Hesik, Christopher ; Swamy,
Manjunatha
Am 07.08.20 um 04:22 schrieb Li, Dennis:
[AMD Public Use]
[SNIP]
I think it is a limitation of init_rwsem.
And exactly that's wrong, this is intentional and perfectly correct.
[Dennis Li] I couldn't understand. Why is it a perfectly correct?
For example, we define two rw_sem: a and b. If we
43 matches
Mail list logo
