[AMD Official Use Only]
Reviewed-by: John Clements
From: Li, Candice
Sent: Monday, September 13, 2021 3:54 PM
To: amd-gfx@lists.freedesktop.org
Cc: Clements, John ; Li, Candice
Subject: [PATCH] drm/amdgpu: Conform ASD header/loading to generic TA systems
Upda
[AMD Official Use Only]
Reviewed-by: John Clements
From: Li, Candice
Sent: Monday, September 13, 2021 3:55 PM
To: amd-gfx@lists.freedesktop.org
Cc: Clements, John ; Li, Candice
Subject: [PATCH] drm/amdgpu: Update PSP TA unload function
Update PSP TA unload fu
On Wed, Sep 08, 2021 at 05:58:35PM -0500, Tom Lendacky wrote:
> Introduce a powerpc version of the cc_platform_has() function. This will
> be used to replace the powerpc mem_encrypt_active() implementation, so
> the implementation will initially only support the CC_ATTR_MEM_ENCRYPT
> attribute.
>
On Thu, Sep 09, 2021 at 09:10:39AM +0200, Christian König wrote:
> Am 08.09.21 um 20:27 schrieb Daniel Vetter:
> > On Tue, Sep 07, 2021 at 11:28:23AM +0200, Christian König wrote:
> > > Am 07.09.21 um 11:05 schrieb Daniel Vetter:
> > > > On Tue, Sep 07, 2021 at 08:22:20AM +0200, Christian König wro
On Sun, Sep 12, 2021 at 07:53:07PM +0300, Oded Gabbay wrote:
> Hi,
> Re-sending this patch-set following the release of our user-space TPC
> compiler and runtime library.
>
> I would appreciate a review on this.
I think the big open we have is the entire revoke discussions. Having the
option to l
Le 14/09/2021 à 13:58, Borislav Petkov a écrit :
On Wed, Sep 08, 2021 at 05:58:35PM -0500, Tom Lendacky wrote:
Introduce a powerpc version of the cc_platform_has() function. This will
be used to replace the powerpc mem_encrypt_active() implementation, so
the implementation will initially only
On Tue, Sep 14, 2021 at 5:18 PM Daniel Vetter wrote:
>
> On Sun, Sep 12, 2021 at 07:53:07PM +0300, Oded Gabbay wrote:
> > Hi,
> > Re-sending this patch-set following the release of our user-space TPC
> > compiler and runtime library.
> >
> > I would appreciate a review on this.
>
> I think the big
Was missing.
Signed-off-by: Alex Deucher
---
.../gpu/drm/amd/display/dc/core/dc_link_dp.c | 24 ++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
index 6663cfc4eb
Looks like this code block was missing parens.
Fixes: c0ffd1945147 ("drm/amd/display: Add DPCD writes at key points")
Cc: Leo (Hanghong) Ma
Cc: Mikita Lipski
Cc: Aric Cyr
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 5 ++---
1 file changed, 2 insertions(+
On Tue, Sep 14, 2021 at 04:47:41PM +0200, Christophe Leroy wrote:
> Yes, see
> https://lore.kernel.org/linuxppc-dev/20210914123919.58203...@canb.auug.org.au/T/#t
Aha, more compiler magic stuff ;-\
Oh well, I guess that fix will land upstream soon.
Thx.
--
Regards/Gruss,
Boris.
https://pe
On 2021-09-13 15:11, Nicholas Kazlauskas wrote:
> [Why]
> The "base_addr_is_mc_addr" field was added for dcn3.1 support but
> pa_config was never updated to set it to false.
>
> Uninitialized memory causes it to be set to true which results in
> address mistranslation and white screen.
>
> [How]
On 2021-09-14 10:59, Alex Deucher wrote:
> Was missing.
>
> Signed-off-by: Alex Deucher
Reviewed-by: Harry Wentland
Harry
> ---
> .../gpu/drm/amd/display/dc/core/dc_link_dp.c | 24 ++-
> 1 file changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/di
On 2021-09-14 10:59, Alex Deucher wrote:
> Looks like this code block was missing parens.
>
> Fixes: c0ffd1945147 ("drm/amd/display: Add DPCD writes at key points")
> Cc: Leo (Hanghong) Ma
> Cc: Mikita Lipski
> Cc: Aric Cyr
> Signed-off-by: Alex Deucher
Reviewed-by: Harry Wentland
Harry
>
Tested on nixeus 4k144hz DSC capable display on
RX5700XT (NAVI10 0x1002:0x731F 0x1DA2:0xE410 0xC1)
on ubuntu 20.04. Display lightsup at 4k144hz with DSC engine on.
Tested-by: Anson Jacob
On 2021-09-07 10:32 a.m., Qingqing Zhuo wrote:
As part of the FPU isolation work documented in
https://pa
On Tue, Sep 14, 2021 at 04:18:31PM +0200, Daniel Vetter wrote:
> On Sun, Sep 12, 2021 at 07:53:07PM +0300, Oded Gabbay wrote:
> > Hi,
> > Re-sending this patch-set following the release of our user-space TPC
> > compiler and runtime library.
> >
> > I would appreciate a review on this.
>
> I thin
On 2021-09-07 10:03, Simon Ser wrote:
> Hi all,
>
> Recently I've been discussing with various people [1] [2] about amdgpu's
> handling of KMS planes. AMD hardware is a bit special when it comes to
> the cursor plane, and it's not always 100% clear how that maps with the
> KMS API.
>
> Up until n
On Wed, 14 Apr 2021 at 11:48, Christian König <
ckoenig.leichtzumer...@gmail.com> wrote:
>
> That is expected behavior, the application is just buggy and causing a
> page fault on the GPU.
>
> The kernel should just not crash with a backtrace.
>
> Regards,
> Christian.
>
If after it GPU hangs wit
Was this fix independent of the other discussions? Should this be
applied to drm-misc?
Alex
On Wed, Sep 1, 2021 at 4:42 PM Alex Deucher wrote:
>
> On Wed, Sep 1, 2021 at 2:50 AM Christian König
> wrote:
> >
> > Am 01.09.21 um 02:46 schrieb Monk Liu:
> > > issue:
> > > in cleanup_job the cancle
[Why & How]
With Werror enabled in the kernel we were failing the clang build since
dml21_ModeSupportAndSystemConfigurationFull's stack frame is 1064 when
building with clang, and exceeding the default 1024 stack frame limit.
The culprit seems to be the Pipe struct, so pull the relevant block
out
On Tue, Sep 14, 2021 at 11:05 PM Harry Wentland wrote:
>
> [Why & How]
> With Werror enabled in the kernel we were failing the clang build since
> dml21_ModeSupportAndSystemConfigurationFull's stack frame is 1064 when
> building with clang, and exceeding the default 1024 stack frame limit.
>
> The
AFAIK this one is independent.
Christian, can you confirm ?
Andrey
From: amd-gfx on behalf of Alex Deucher
Sent: 14 September 2021 15:33
To: Christian König
Cc: Liu, Monk ; amd-gfx list ;
Maling list - DRI developers
Subject: Re: [PATCH 1/2] drm/sched: fix t
Adds the missing logic to set the correct value of dcc_ind_blk for this tiling
version.
Signed-off-by: Joshua Ashton
Reviewed-by: Bas Nieuwenhuizen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 20 +++
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers
We don't need to do this workaround if we start setting this value when we fill
the plane attributes.
Signed-off-by: Joshua Ashton
Reviewed-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 ++-
drivers/gpu/drm/amd/display/dc/core/dc.c | 2 +-
drivers
Some games, ie. Doom Eternal, present from compute following compute
post-fx and would benefit from having DCC image stores available.
DCN on gfx10_3 doesn't need INDEPENDENT_128B_BLOCKS = 0 so we can expose
these modifiers capable of DCC image stores.
Signed-off-by: Joshua Ashton
Reviewed-by: B
Borislav Petkov writes:
> On Wed, Sep 08, 2021 at 05:58:35PM -0500, Tom Lendacky wrote:
>> Introduce a powerpc version of the cc_platform_has() function. This will
>> be used to replace the powerpc mem_encrypt_active() implementation, so
>> the implementation will initially only support the CC_ATT
On Wed, Sep 08, 2021 at 05:58:36PM -0500, Tom Lendacky wrote:
> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index 18fe19916bc3..4b54a2377821 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
> @@ -144,7 +144,7 @@ void __init sme_unmap_bootdata(char
We hit soft hang while doing memory pressure test on one numa system.
After a qucik look, this is because kfd invalid/valid userptr memory
frequently with process_info lock hold.
perf top says below,
75.81% [kernel] [k] __srcu_read_unlock
6.19% [amdgpu] [k] amdgpu_gmc_set_pte_pde
3
On 2021-09-14 9:42 p.m., xinhui pan wrote:
We hit soft hang while doing memory pressure test on one numa system.
After a qucik look, this is because kfd invalid/valid userptr memory
frequently with process_info lock hold.
perf top says below,
75.81% [kernel] [k] __srcu_read_unlock
Do
I think you missed 'reply all' so bringing back to public
On 2021-09-14 11:40 p.m., Pan, Xinhui wrote:
[AMD Official Use Only]
perf says it is the lock addl $0x0,-0x4(%rsp)
details is below. the contention is huge maybe.
Yes - that makes sense to me too as long as the lock here is some
On 9/13/21 9:15 AM, Alex Sierra wrote:
From: Ralph Campbell
ZONE_DEVICE struct pages have an extra reference count that complicates the
code for put_page() and several places in the kernel that need to check the
reference count to see that a page is not being used (gup, compaction,
migration, e
We hit soft hang while doing memory pressure test on one numa system.
After a qucik look, this is because kfd invalid/valid userptr memory
frequently with process_info lock hold.
Looks like update page table mapping use too much cpu time.
perf top says below,
75.81% [kernel] [k] __srcu_read
[AMD Official Use Only]
Andrey
I hit panic with this plug/unplug test without this patch.
But as we add enter/exit in all its callers. maybe it would not impact
plug/unplug.
[ 1109.041095] BUG: unable to handle page fault for address: 10e1
[ 1109.086353] RIP: 0010:vega10_power_gate_v
32 matches
Mail list logo
