[AMD Official Use Only - Internal Distribution Only]
Any updates on this patch?
Best Regards,
Li, Xin (Justin)
From: Li, Xin (Justin)
Date: Tuesday, October 27, 2020 at 14:36
To: amd-gfx@lists.freedesktop.org , Li, Xin
(Justin) , Zhou, Tiecheng
Subject: [PATCH] drm/amd/amdgpu: Add checksun
[Why]
Incorrect values were resulting in flash lines
when MPO was enabled and system was left idle.
[How]
Increase min clk values only when MPO is enabled
and display is active to not affect S3 power.
Signed-off-by: Pratik Vishwakarma
---
.../display/dc/clk_mgr/dcn10/rv1_clk_mgr.c| 35
This way the modifier path gets exercised all the time, improving
testing. Furthermore, for modifiers this is required as getfb2
will always return the modifier if the driver sets allow_fb_modifiers.
This only triggers once allow_fb_modifiers is set.
Signed-off-by: Bas Nieuwenhuizen
Silently accepting it could result in corruption.
Signed-off-by: Bas Nieuwenhuizen
Reviewed-by: Alex Deucher
Reviewed-by: Nicholas Kazlauskas
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Otherwise the field ends up being used uninitialized when
enabling modifiers, failing validation with high likelyhood.
v4: Use memset
Signed-off-by: Bas Nieuwenhuizen
Reviewed-by: Alex Deucher
(for v1)
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 1 +
1 file changed, 1 insertion(+)
diff
Prepare for inserting modifiers based configuration, while sharing
a bunch of DCC validation & initializing the device-based configuration.
Signed-off-by: Bas Nieuwenhuizen
Reviewed-by: Alex Deucher
Reviewed-by: Nicholas Kazlauskas
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 222
This sets the DC tiling options from the modifier, if modifiers
are used for the FB. This patch by itself does not expose the
support yet though.
There is not much validation yet to limit the scope of this
patch, but the current validation is at the same level as
the BO metadata path.
v2: Add
With modifiers I'd like to support non-dedicated buffers for
images.
Signed-off-by: Bas Nieuwenhuizen
Reviewed-by: Alex Deucher
Reviewed-by: Nicholas Kazlauskas
Cc: sta...@vger.kernel.org # 5.1.0
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 +-
1 file changed, 9
This adds modifier support to the amdgpu kernel drivers for GFX9 and
later GPUs. It has been tested on
- VEGA10, RAVEN, NAVI14
- weston, sway, X with xf86-video-amdgpu (i.e. legacy path still works)
and includes some basic testing of the layout code.
The main goal is to keep it somewhat simple
This expose modifier support on GFX9+.
Only modifiers that can be rendered on the current GPU are
added. This is to reduce the number of modifiers exposed.
The HW could expose more, but the best mechanism to decide
what to expose without an explosion in modifiers is still
to be decided, and in
For DCC we will use 2/3 planes to avoid X rendering to the frontbuffer
with DCC compressed images. To make this work with the core KMS
validation we need to add extra formats with the extra planes.
However, due to flexibility we set bpp = 0 for the extra planes and
do the validation ourselves.
This moves the tiling_flags to the framebuffer creation.
This way the time of the "tiling" decision is the same as it
would be with modifiers.
Signed-off-by: Bas Nieuwenhuizen
Reviewed-by: Alex Deucher
Reviewed-by: Nicholas Kazlauskas
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 48
Reviewed-by: Nikola Cornij
-Original Message-
From: Siqueira, Rodrigo
Sent: Wednesday, October 28, 2020 6:08 PM
To: amd-gfx@lists.freedesktop.org
Cc: Cornij, Nikola ; Liu, Zhan ;
Lakha, Bhawanpreet ; Wentland, Harry
; Laktyushkin, Dmytro ;
Park, Chris
Subject: [PATCH]
From: Dmytro Laktyushkin
We need this to pass dp compliance.
Signed-off-by: Dmytro Laktyushkin
Reviewed-by: Chris Park
Acked-by: Rodrigo Siqueira
---
.../gpu/drm/amd/display/dc/dcn30/dcn30_resource.c | 14 --
.../amd/display/dc/dml/dcn30/display_mode_vba_30.c | 2 +-
2 files
DRM's fbdev console uses regular load and store operations to update
framebuffer memory. The bochs driver on sparc64 requires the use of
I/O-specific load and store operations. We have a workaround, but need
a long-term solution to the problem.
This patchset changes GEM's vmap/vunmap interfaces
The functions exynos_drm_gem_prime_{vmap,vunmap}() are empty. Remove
them before changing the interface to use struct drm_buf_map. As a side
effect of removing drm_gem_prime_vmap(), the error code changes from
ENOMEM to EOPNOTSUPP.
Signed-off-by: Thomas Zimmermann
Acked-by: Christian König
Kernel DRM clients now store their framebuffer address in an instance
of struct dma_buf_map. Depending on the buffer's location, the address
refers to system or I/O memory.
Callers of drm_client_buffer_vmap() receive a copy of the value in
the call's supplied arguments. It can be accessed and
At least sparc64 requires I/O-specific access to framebuffers. This
patch updates the fbdev console accordingly.
For drivers with direct access to the framebuffer memory, the callback
functions in struct fb_ops test for the type of memory and call the rsp
fb_sys_ of fb_cfb_ functions. Read and
To do framebuffer updates, one needs memcpy from system memory and a
pointer-increment function. Add both interfaces with documentation.
v5:
* include to build on sparc64 (Sam)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
Tested-by: Sam Ravnborg
---
The parameters map and is_iomem are always of the same value. Removed them
to prepares the function for conversion to struct dma_buf_map.
v4:
* don't check for !kmap->virtual; will always be false
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Reviewed-by: Christian König
The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel
address space. The mapping's address is returned as struct dma_buf_map.
Each function is a simplified version of TTM's existing kmap code. Both
functions respect the memory's location ani/or writecombine flags.
On top TTM's
This patch replaces the vmap/vunmap's use of raw pointers in GEM object
functions with instances of struct dma_buf_map. GEM backends are
converted as well. For most of them, this simply changes the returned type.
TTM-based drivers now return information about the location of the memory,
either
The function etnaviv_gem_prime_vunmap() is empty. Remove it before
changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann
Acked-by: Christian König
Tested-by: Sam Ravnborg
---
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 -
drivers/gpu/drm/etnaviv/etnaviv_gem.c
GEM's vmap and vunmap interfaces now wrap memory pointers in struct
dma_buf_map.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Tested-by: Sam Ravnborg
---
drivers/gpu/drm/drm_client.c | 18 +++---
drivers/gpu/drm/drm_gem.c | 26 +-
The function drm_gem_cma_prime_vunmap() is empty. Remove it before
changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Christian König
Tested-by: Sam Ravnborg
---
drivers/gpu/drm/drm_gem_cma_helper.c | 17 -
[AMD Public Use]
Please ignore this patch, it should be in a different branch. As PCIe p2p is
not supported in upstream.
Regards,
Alex Sierra
> -Original Message-
> From: amd-gfx On Behalf Of
> Sierra Guiza, Alejandro (Alex)
> Sent: Wednesday, October 28, 2020 1:09 PM
> To: Koenig,
From: Colin Ian King
A recent change added two uint16_t elements to PPTable_t and reduced the
uint32_t array down to 8 elements. This results in the dev_info printing
of pptable->SkuReserved[8] accessing a value that is out-of-range on
array SkuReserved. The array has been shrunk by 1 element,
Fix the following coccinelle report:
./drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c:1367:3-5:
WARNING: possible condition with no effect (if == else)
Both branches are the same, so remove the if/else altogether.
Fixes: 81875979f0b2 ("drm/amd/display: Remove extra pairs of parentheses in
While looking at the following commit, I noticed what might be an
arithmetic issue potentially stemming from some merge/patch conflict
resolution.
commit ad339f69114a6a145fc94d44376851c53dee3475
Author: Jaehyun Chung
Date: Thu Jun 18 15:27:35 2020 -0400
drm/amd/display: Fix incorrect
On 10/28/2020 9:58 AM, Christian König wrote:
Am 28.10.20 um 15:55 schrieb Alex Sierra:
By enabling this parameter, the system will be forced to use pcie
interface only for p2p transactions.
Better name that amdgpu_xgmi with a default value of enabled.
Or maybe add another bit value for
Am 2020-10-28 um 1:11 p.m. schrieb Kent Russell:
> Since the unique_id is now obtained in amdgpu in smu_late_init,
> topology misses getting the value during KFD device initialization.
> To work around this, we use amdgpu_amdkfd_get_unique_id to get
> the unique_id at read time. Due to this, we
Reviewed-by: Luben Tuikov
I assume that the default ("else") case is what is wanted
by this patch and has been vetted-i.e. it what fixes it.
Regards,
Luben
On 2020-10-28 11:08, Alex Deucher wrote:
> Leads to improper dpm on older parts.
>
> Bug:
>
Since the unique_id is now obtained in amdgpu in smu_late_init,
topology misses getting the value during KFD device initialization.
To work around this, we use amdgpu_amdkfd_get_unique_id to get
the unique_id at read time. Due to this, we can remove unique_id from
the kfd_dev structure, since we
[AMD Public Use]
amdgpu actually prints it as hex:
return snprintf(buf, PAGE_SIZE, "%016llx\n", adev->unique_id);
But either way, we can address it in rocminfo if anyone complains. Thanks for
the review!
Kent
> -Original Message-
> From: Kuehling, Felix
> Sent: Wednesday, October
[AMD Public Use]
Right, will do!
Kent
> -Original Message-
> From: Kuehling, Felix
> Sent: Wednesday, October 28, 2020 12:16 PM
> To: Russell, Kent ; amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH 1/2] drm/amdkfd: Fix getting unique_id in topology
>
> Please also remove the
Please also remove the broken code that initializes gpu->unique_id and
remove the unique_id field from the structure.
Regards,
Felix
Am 2020-10-28 um 11:22 a.m. schrieb Kent Russell:
> Since the unique_id is now obtained in amdgpu in smu_late_init,
> topology's device addition is now happening
So rocm-smi reads the decimal and converts it to hex? Then changing KFD
will break rocm-smi. If you want to fix rocminfo, you'll need to fix it
in the rocminfo code to do the conversion to hex.
Regards,
Felix
Am 2020-10-28 um 12:02 p.m. schrieb Russell, Kent:
> [AMD Public Use]
>
> rocminfo
[AMD Public Use]
rocminfo uses it, but that's all that I am aware of. I can drop this though and
stick with patch1, I just didn't know if we'd end up getting complaints of:
"Well, rocm-smi (amdgpu) says that the unique_id is F, while rocminfo (amdkfd)
says that the unique_id is 16" . Probably
This is an ABI-breaking change. Is any user mode code using this already?
Regards,
Felix
Am 2020-10-28 um 11:22 a.m. schrieb Kent Russell:
> amdgpu's unique_id prints in hex format, so change topology's printout
> to hex by adding a new sysfs_print macro specifically for hex output,
> and use
[AMD Official Use Only - Internal Distribution Only]
> -Original Message-
> From: amd-gfx On Behalf Of
> Luben Tuikov
> Sent: Wednesday, October 28, 2020 11:12 AM
> To: Sierra Guiza, Alejandro (Alex) ; amd-
> g...@lists.freedesktop.org
> Subject: Re: [PATCH] drm/amdgpu: Add kernel
Since the unique_id is now obtained in amdgpu in smu_late_init,
topology's device addition is now happening before the unique_id is
saved, thus topology misses it. To work around this, we use the
amdgpu_amdkfd_get_unique_id to get the unique_id at read time.
Signed-off-by: Kent Russell
---
amdgpu's unique_id prints in hex format, so change topology's printout
to hex by adding a new sysfs_print macro specifically for hex output,
and use it for unique_id
Signed-off-by: Kent Russell
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 4 +++-
1 file changed, 3 insertions(+), 1
On 2020-10-28 10:55, Alex Sierra wrote:
> By enabling this parameter, the system will be forced to use pcie
> interface only for p2p transactions.
>
> Signed-off-by: Alex Sierra
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
>
Leads to improper dpm on older parts.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1353
Fixes: 8d89b96fe797 ("drm/amd/powerplay: optimize the mclk dpm policy settings")
Signed-off-by: Alex Deucher
---
.../drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c | 30 +++
1 file
On Wed, 28 Oct 2020 at 14:03, Quan, Evan wrote:
>
> [AMD Official Use Only - Internal Distribution Only]
>
> If it turns out "PCI CONFIG reset" is used, please try the new patch series I
> just sent.
> https://lists.freedesktop.org/archives/amd-gfx/2020-October/055327.html
>
Am 28.10.20 um 15:55 schrieb Alex Sierra:
By enabling this parameter, the system will be forced to use pcie
interface only for p2p transactions.
Better name that amdgpu_xgmi with a default value of enabled.
Or maybe add another bit value for amdgpu_vm_debug instead.
Signed-off-by: Alex
By enabling this parameter, the system will be forced to use pcie
interface only for p2p transactions.
Signed-off-by: Alex Sierra
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 9 +
3
On 2020-10-28 10:44, Luben Tuikov wrote:
> On 2020-10-27 11:19, Alex Deucher wrote:
>> On Mon, Oct 26, 2020 at 7:06 PM Luben Tuikov wrote:
>>>
>>> Consolidating DCN seems like a good idea.
>>>
>>> Reviewed-by: Luben Tuikov
>>
>> Is this for the whole series or just this patch?
>
> Sorry, whose
On 2020-10-27 11:19, Alex Deucher wrote:
> On Mon, Oct 26, 2020 at 7:06 PM Luben Tuikov wrote:
>>
>> Consolidating DCN seems like a good idea.
>>
>> Reviewed-by: Luben Tuikov
>
> Is this for the whole series or just this patch?
Sorry, whose series!
Regards,
Luben
>
> Thanks!
>
> Alex
>
>>
On Wed, 28 Oct 2020 at 07:01, Quan, Evan wrote:
>
> [AMD Official Use Only - Internal Distribution Only]
>
> Hi Sandeep,
>
> Did you run the tests on Hawaii?
> And can you help to confirm which method is used for gpu reset? "BACO reset"
> or " PCI CONFIG reset" (you can grep these keywords in
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Christian
König
Sent: Wednesday, October 28, 2020 9:49 AM
To: amd-gfx@lists.freedesktop.org
Subject: [PATCH] drm/amdgpu: cleanup
First of all don't snprintf into a char buffer allocated on the stack with
a constant hubname.
Then cleanup to exit the function early in case of a ratelimit or SRIOV.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 183 +-
1 file changed, 91
[AMD Public Use]
Series is:
Reviewed-by: Alex Deucher
From: Quan, Evan
Sent: Wednesday, October 28, 2020 4:30 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; sandy.8...@gmail.com
; Quan, Evan
Subject: [PATCH 5/5] drm/amd/pm: do not use
On Wed, Oct 28, 2020 at 06:12:36PM +0800, Su, Jinzhou (Joe) wrote:
> Add RLC_CGTT_MGCG_OVERRIDE__RLC_CGTT_SCLK_OVERRIDE_MASK
>
> Change-Id: I4c1cc30bec81953d29c86d0fd9b5d7cff15a8cb0
> Signed-off-by: Jinzhou.Su
Reviewed-by: Huang Rui
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 1 +
> 1
On Wed, Oct 28, 2020 at 05:59:45PM +0800, Su, Jinzhou (Joe) wrote:
> add GFX Medium Grain Light Sleep support for vangogh
>
> add AMD_CG_SUPPORT_GFX_CP_LS and AMD_CG_SUPPORT_GFX_RLC_LS
>
> v2:
> add GFX Medium Grain Clock Gating
>
> Signed-off-by: Jinzhou.Su
> Change-Id:
[AMD Public Use]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Chengming Gui
Sent: Wednesday, October 28, 2020 17:48
To: amd-gfx@lists.freedesktop.org
Cc: Gui, Jack ; Zhou1, Tao ; Xiong, Yang
(Felix) ; Zhang, Hawking
Subject: [PATCH] drm/amd/amdgpu: simplify
Add RLC_CGTT_MGCG_OVERRIDE__RLC_CGTT_SCLK_OVERRIDE_MASK
Change-Id: I4c1cc30bec81953d29c86d0fd9b5d7cff15a8cb0
Signed-off-by: Jinzhou.Su
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
add GFX Medium Grain Light Sleep support for vangogh
add AMD_CG_SUPPORT_GFX_CP_LS and AMD_CG_SUPPORT_GFX_RLC_LS
v2:
add GFX Medium Grain Clock Gating
Signed-off-by: Jinzhou.Su
Change-Id: I38f4e36a896915f39fd7c2673e0041244006d1b8
---
drivers/gpu/drm/amd/amdgpu/nv.c | 6 +-
1 file
[AMD Official Use Only - Internal Distribution Only]
If it turns out "PCI CONFIG reset" is used, please try the new patch series I
just sent.
https://lists.freedesktop.org/archives/amd-gfx/2020-October/055327.html
https://lists.freedesktop.org/archives/amd-gfx/2020-October/055328.html
Correct some registers bitmasks and add mmBIOS_SCRATCH_7
reset.
Change-Id: I416d7bee7e7ddd7b726dd921d0bb442da6ff4b93
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/pm/powerplay/hwmgr/ci_baco.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git
So that the succeeding resume can be performed based on
a clean state.
Change-Id: I82f16eb2d1a6e389f171784e6e56e41892e1725e
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/pm/inc/hwmgr.h| 1 +
drivers/gpu/drm/amd/pm/inc/smumgr.h | 2 ++
This can address the random SDMA hang after pci config reset
seen on Hawaii.
Change-Id: I2d6147600636cbc90d1be7f3d9a011f050708fbd
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/amdgpu/cik_sdma.c | 27 ---
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git
This reverts commit f87812284172a9809820d10143b573d833cd3f75 "drm/amdgpu:
Fix bug where DPM is not enabled after hibernate and resume".
It was intended to fix Hawaii S4(hibernation) issue but break S3. As
ixFEATURE_STATUS is filled with garbage data on resume which can be
only cleared by reloading
Which can be used for S4(hibernation) support.
Change-Id: I9c90c916bdd6e128b7cf7f5c6c2c6ca5b7cfc0ef
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/amdgpu/cik.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/cik.c
On Tue, 27 Oct 2020, t...@redhat.com wrote:
> This rfc will describe
> An upcoming treewide cleanup.
> How clang tooling was used to programatically do the clean up.
> Solicit opinions on how to generally use clang tooling.
>
This tooling is very impressive. It makes possible an idea that I
On Tue, Oct 27, 2020 at 05:41:24PM +0800, Du, Xiaojian wrote:
> This patch is to update the smu v11.5 smc header for vangogh.
>
> Signed-off-by: Xiaojian Du
> Reviewed-by: Huang Rui
> Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/pm/inc/smu_v11_5_ppsmc.h | 114 +++
> 1
[AMD Public Use]
Series is: Reviewed-by: Guchun Chen
Regards,
Guchun
-Original Message-
From: Cui, Flora
Sent: Wednesday, October 28, 2020 2:07 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Xu, Feifei ;
Chen, Guchun ; Cui, Flora ; Teng, Rui
; Long, Gang ; Yin, Tianci
Navi14 0x7340/C9 SKU has no display and video support, remove them.
Signed-off-by: Flora Cui
---
drivers/gpu/drm/amd/amdgpu/nv.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c
index
for headless NAVI ASICs
Signed-off-by: Flora Cui
---
drivers/gpu/drm/amd/amdgpu/nv.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c
index 23446aceea1d..c65b4462bf5e 100644
---
69 matches
Mail list logo
