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,
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 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
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
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
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
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:
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 +-
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
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
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.
>
>
[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
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
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
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
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
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
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
>
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
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 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.
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
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
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
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
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
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
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.
>
[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
[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
30 matches
Mail list logo
