Whole patch serials reviewed by Monk
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
Chunming Zhou
Sent: 2018年2月8日 13:14
To: amd-gfx@lists.freedesktop.org
Cc: Zhou, David(ChunMing) ; Koenig, Christian
Subject: [PATCH 3/3] drm/radeon: only ena
swiotlb expands our card accessing range, but its path always is slower
than ttm pool allocation.
So add condition to use it.
Change-Id: I1802645833155a9cd808913f863981173a82145f
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/radeon/radeon.h| 1 +
drivers/gpu/drm/radeon/radeon_device.c
it will be used to check if the driver needs swiotlb
Change-Id: Idbe47af8f12032d4803bb3d47273e807f19169c3
Signed-off-by: Chunming Zhou
---
include/drm/drm_cache.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h
index beab0f0d0c
get the max io mapping address of system memory to see if it is over
our card accessing range.
Change-Id: Ibc38dbd34a20af5b4a4b1ed154c14e1c58aa4c55
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +++---
drivers/gpu/drm/
Apart from the allocation failure, reserving 1024M cma is also not realistic
Regards,
Hawking
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
Chunming Zhou
Sent: Thursday, February 08, 2018 12:35
To: Koenig, Christian ; Xu, Feifei
; amd-g
On 2018年02月08日 02:48, Christian König wrote:
Hi Feifei,
ok the correct approach of doing this:
1. Compile the kernel with CONFIG_DMA_CMA.
2. Specify cma=1025M on the kernel command line.
3. Call dma_alloc_coherent() to allocate up to 1GB of memory for ZFB.
Have you tried CMA? In early time, I
Use subdir-ccflags instead of specifying the same flags for every source
file.
Signed-off-by: Matthias Kaehlcke
Reviewed-by: Guenter Roeck
---
Changes in v2:
- added 'Reviewed-by: Guenter Roeck ' tag
drivers/gpu/drm/amd/display/dc/dml/Makefile | 10 +-
1 file changed, 1 insertion(+), 9
Use subdir-ccflags instead of specifying the same flags for every source
file.
Signed-off-by: Matthias Kaehlcke
---
drivers/gpu/drm/amd/display/dc/dml/Makefile | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile
b/drivers/gpu
On Wed, Feb 7, 2018 at 5:51 PM, Matthias Kaehlcke wrote:
> DML uses the compiler option -mpreferred-stack-boundary=4 to configure
> a stack alignment of 16 bytes. Clang uses the option -mstack-alignment
> instead, which expects as parameter the alignment in bytes, and not a
> power of two like -mp
DML uses the compiler option -mpreferred-stack-boundary=4 to configure
a stack alignment of 16 bytes. Clang uses the option -mstack-alignment
instead, which expects as parameter the alignment in bytes, and not a
power of two like -mpreferred-stack-boundary.
Probe for both compiler options and use
El Wed, Feb 07, 2018 at 05:34:44PM -0800 Guenter Roeck ha dit:
> On Wed, Feb 7, 2018 at 5:21 PM, Matthias Kaehlcke wrote:
> > DML uses the compiler option -mpreferred-stack-boundary=4 to configure
> > a stack alignment of 16 bytes. Clang uses the option -mstack-alignment
> > instead, which expect
On Wed, Feb 7, 2018 at 5:21 PM, Matthias Kaehlcke wrote:
> Use subdir-ccflags instead of specifying the same flags for every source
> file.
>
> Signed-off-by: Matthias Kaehlcke
Reviewed-by: Guenter Roeck
> ---
> drivers/gpu/drm/amd/display/dc/dml/Makefile | 10 +-
> 1 file changed, 1
DML uses the compiler option -mpreferred-stack-boundary=4 to configure
a stack alignment of 16 bytes. Clang uses the option -mstack-alignment
instead, which expects as parameter the alignment in bytes, and not a
power of two like -mpreferred-stack-boundary.
Probe for both compiler options and use
On Wed, Feb 7, 2018 at 5:21 PM, Matthias Kaehlcke wrote:
> DML uses the compiler option -mpreferred-stack-boundary=4 to configure
> a stack alignment of 16 bytes. Clang uses the option -mstack-alignment
> instead, which expects as parameter the alignment in bytes, and not a
> power of two like -mp
The driver passes GRAPHICS_CSC_ADJUST_TYPE_SW of type enum
graphics_csc_adjust_type to program_color_matrix(), however the function
expects a parameter of type enum grph_color_adjust_option. Supposedly
the intention was to pass GRPH_COLOR_MATRIX_SW, which has the same value
as GRAPHICS_CSC_ADJUST_T
On 2018-02-07 04:43 PM, Matthias Kaehlcke wrote:
> The driver passes GRAPHICS_CSC_ADJUST_TYPE_SW of type enum
> graphics_csc_adjust_type to program_color_matrix(), however the function
> expects a parameter of type enum grph_color_adjust_option. Supposedly
> the intention was to pass GRPH_COLOR_MAT
On 2018-02-07 06:20 AM, Christian König wrote:
> Am 07.02.2018 um 02:32 schrieb Felix Kuehling:
>> dGPUs work without IOMMUv2. Make IOMMUv2 initialization dependent on
>> ASIC information. Also allow building KFD without IOMMUv2 support.
>> This is still useful for dGPUs and prepares for enabling K
On 2018-02-07 02:49 PM, Matthias Kaehlcke wrote:
> The double parentheses are not needed. Removing them fixes multiple
> warnings like this when building with clang:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:617:42:
> error: equality comparison with extraneous parentheses
>
On Wed, Feb 7, 2018 at 2:19 PM, Guenter Roeck wrote:
> On Wed, Feb 7, 2018 at 11:10 AM, Matthias Kaehlcke wrote:
>> The double parentheses are not needed. Removing them fixes the following
>> warning when building with clang:
>>
>> drivers/gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c:419:29:
>>
On Wed, Feb 7, 2018 at 11:49 AM, Matthias Kaehlcke wrote:
> The double parentheses are not needed. Removing them fixes multiple
> warnings like this when building with clang:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:617:42:
> error: equality comparison with extraneous paren
On Wed, Feb 7, 2018 at 2:53 PM, Shaoyun Liu wrote:
> Change-Id: If73d9e5f1f2f998d927f506ca4b7a961db368716
> Signed-off-by: Shaoyun Liu
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/a
On Wed, Feb 7, 2018 at 11:10 AM, Matthias Kaehlcke wrote:
> The double parentheses are not needed. Removing them fixes the following
> warning when building with clang:
>
> drivers/gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c:419:29:
> error: equality comparison with extraneous parentheses
>
The double parentheses are not needed. Removing them fixes the following
warning when building with clang:
drivers/gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c:419:29:
error: equality comparison with extraneous parentheses
[-Werror,-Wparentheses-equality]
if ((data->vdd_gfx_control == SMU7_
The double parentheses are not needed. Removing them fixes multiple
warnings like this when building with clang:
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:617:42:
error: equality comparison with extraneous parentheses
[-Werror,-Wparentheses-equality]
if ((data->graphics_mi
Change-Id: If73d9e5f1f2f998d927f506ca4b7a961db368716
Signed-off-by: Shaoyun Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index f6ec36f..7968944 1006
Start to use amdgpu_bo_create_reserved.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 91 -
1 file changed, 21 insertions(+), 70 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_
We didn't synced the BO after validating it. Also sart to use
amdgpu_bo_create_reserved to simplify things.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 106
1 file changed, 38 insertions(+), 68 deletions(-)
diff --git a/drivers/g
Hi Dave,
Just one fix this week for 4.16. This is on top of the pull request I
sent last week. One of the fixes from last week got applied to the wrong
asic by accident. The patch this week fixes that.
The following changes since commit 7e24a3ea825e546487c3fc47f8cbf6512f6c9e8c:
drm/amdgpu:
On Wed, Feb 7, 2018 at 2:01 PM, Guenter Roeck wrote:
> On Wed, Feb 7, 2018 at 10:58 AM, Matthias Kaehlcke wrote:
>> In several locations the driver uses AMD_CG_STATE_UNGATE (type enum
>> amd_clockgating_state) instead of AMD_PG_STATE_UNGATE (type enum
>> amd_powergating_stat) and vice versa. Both
On Wed, Feb 7, 2018 at 10:58 AM, Matthias Kaehlcke wrote:
> In several locations the driver uses AMD_CG_STATE_UNGATE (type enum
> amd_clockgating_state) instead of AMD_PG_STATE_UNGATE (type enum
> amd_powergating_stat) and vice versa. Both constants have the same
> value, so this doesn't cause any
In several locations the driver uses AMD_CG_STATE_UNGATE (type enum
amd_clockgating_state) instead of AMD_PG_STATE_UNGATE (type enum
amd_powergating_stat) and vice versa. Both constants have the same
value, so this doesn't cause any problems, but we still want to pass
the correct type.
Fixing the
Hi Feifei,
ok the correct approach of doing this:
1. Compile the kernel with CONFIG_DMA_CMA.
2. Specify cma=1025M on the kernel command line.
3. Call dma_alloc_coherent() to allocate up to 1GB of memory for ZFB.
Couldn't figure out of hand what alignment is necessary here, but that
should just
Hi,
On 02/07/2018 02:22 PM, Christian König wrote:
Understood, but why is that?
Well because customers requested it :)
What we try to do here is having a parameter which says when less than
x megabytes of memory are left then fail the allocation.
This is basically to prevent buggy applicati
We haven't had a chance to look yet.
Alex
From: Luís Mendes
Sent: Wednesday, February 7, 2018 10:50:48 AM
To: Koenig, Christian
Cc: Alex Deucher; Deucher, Alexander; Zhou, David(ChunMing); Michel Dänzer;
amd-gfx@lists.freedesktop.org
Subject: Re: Deadlocks with
Hi Christian, Alexander,
Kmemleak reported leaked data structures and the GPU hung a bit after.
Could this be caused from DC?
Info in attachments.
I'm not sure if my previous email got overlooked, or if simply, there
are no suggestions at this moment. Sorry for kind of re-sending the
email.
Re
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Shaoyun Liu
Sent: Tuesday, February 6, 2018 6:25:57 PM
To: amd-gfx@lists.freedesktop.org
Cc: Liu, Shaoyun
Subject: [PATCH] drm/amdgpu: Add place holder for soc15 asic init on emulation
Add common smu_soc_asi
Am 07.02.2018 um 13:34 schrieb Feifei Xu:
Change-Id: Icfb8c1df201d3f22f1d8cdbaee55de6bebac8df6
Signed-off-by: Hawking Zhang
Acked-by: John Bridgman
---
drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.c | 2 ++
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c| 6 ++
drivers/gpu/drm/amd/amdgpu/mmhub_v1_0
Am 07.02.2018 um 13:34 schrieb Feifei Xu:
From: Hawking Zhang
Change-Id: I89b9ff36b62eb685a9e2d87e2058d200b92f5034
Signed-off-by: Hawking Zhang
Acked-by: John Bridgman
Reviewed-by: Alex Deucher
NAK, please do that in gmc_v9_0_vram_gtt_location() instead. The
function you modify here shoul
Am 07.02.2018 um 13:34 schrieb Feifei Xu:
Change-Id: I3beb3ca3f958fdd63b3ce7068b59ebf957b49a5a
Signed-off-by: Hawking Zhang
Signed-off-by: Feifei Xu
---
drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.c | 5 -
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c| 18 +-
2 files changed, 17
Understood, but why is that?
Well because customers requested it :)
What we try to do here is having a parameter which says when less than x
megabytes of memory are left then fail the allocation.
This is basically to prevent buggy applications which try to allocate as
much memory as possible
Hi Feifei,
mhm, so you're approach is to limit the memory the Linux kernel grab
using the mem= parameter and then give that memory to amdgpu, correct?
If that's the case then this is most likely a NAK. Cause this sounds
like a perfect example for the CMA.
Never worked with that subsystem be
Hi, Roger.
On 02/07/2018 09:25 AM, He, Roger wrote:
Why should TTM be different in that aspect? It would be good to know
your reasoning WRT this?
Now, in TTM struct ttm_bo_device it already has member no_retry to indicate
your option.
If you prefer no OOM triggered by TTM, set it as t
Am 07.02.2018 um 13:34 schrieb Feifei Xu:
Change-Id: I43ab31a68e93ef264fb8d8dd8a3dba59e2962fad
Signed-off-by: Hawking Zhang
Acked-by: John Bridgman
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h
b/
Am 07.02.2018 um 13:34 schrieb Feifei Xu:
In gmc_v9_0_vram_gtt_location(),the vram_base_offset is hardcoded
to 0 in dGPU. Fix it by reading mmMC_VM_FB_OFFSET or return
zfb_phys_addr if ZFB is enabled.
Change-Id: I585b7d4d96ebab2a5d7178fe8d1d6a746ef0c72a
Signed-off-by: Feifei Xu
Signed-off-by: H
From: Hawking Zhang
Change-Id: I89b9ff36b62eb685a9e2d87e2058d200b92f5034
Signed-off-by: Hawking Zhang
Acked-by: John Bridgman
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/
Change-Id: Icfb8c1df201d3f22f1d8cdbaee55de6bebac8df6
Signed-off-by: Hawking Zhang
Acked-by: John Bridgman
---
drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.c | 2 ++
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c| 6 ++
drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c | 2 ++
3 files changed, 10 insertions(+)
From: Hawking Zhang
Change-Id: I32e6321da74a1bd87f13adbe8e7738023738e6d5
Signed-off-by: Hawking Zhang
Acked-by: John Bridgman
Reviewed-by: Alex Deucher
Signed-off-by: Feifei Xu
---
drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.c | 19 +++
drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c | 1
From: Hawking Zhang
Change-Id: I298b78b160f3894bdd56d9a14a20fbb7fb2ac645
Signed-off-by: Hawking Zhang
Acked-by: John Bridgman
---
drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.c | 9 +++--
drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c | 9 +++--
2 files changed, 14 insertions(+), 4 deletions(-)
d
Change-Id: I3beb3ca3f958fdd63b3ce7068b59ebf957b49a5a
Signed-off-by: Hawking Zhang
Signed-off-by: Feifei Xu
---
drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.c | 5 -
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c| 18 +-
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/dr
Users can pass in an array to decide enable/disable Zero Frame Buffer.
zfb[0] = zfb_size(MB), zfb[1] = zfb_phys_addr(MB).
If zbf_size > 0, zfb is enabled. Otherwise disabled.
Usage for example:
modprobe amdgpu zfb={256,4096}
Change-Id: I340fcb36b5655f24551056e685b74559d7599680
Signed-off-by: F
In gmc_v9_0_vram_gtt_location(),the vram_base_offset is hardcoded
to 0 in dGPU. Fix it by reading mmMC_VM_FB_OFFSET or return
zfb_phys_addr if ZFB is enabled.
Change-Id: I585b7d4d96ebab2a5d7178fe8d1d6a746ef0c72a
Signed-off-by: Feifei Xu
Signed-off-by: Hawking Zhang
---
drivers/gpu/drm/amd/amdgp
Use module parameter passed from user to initialize zfb start
address and size.
Change-Id: Idd0ae02ef8010ec36baa4b03b01981e97b3e748a
Signed-off-by: Feifei Xu
Signed-off-by: Hawking Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 12
1 file changed, 12 insertions(+)
diff --g
Change-Id: I43ab31a68e93ef264fb8d8dd8a3dba59e2962fad
Signed-off-by: Hawking Zhang
Acked-by: John Bridgman
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h
index
This patch-set enabled Full Zero Frame Buffer.
And fixed hardcoded base offset of vram pages issue.
Enable the ZFB by: modprobe amdgpu zfb={zfb_size,zfb_phy_offset}
Feifei Xu (6):
drm/amdgpu: Fix hardcoded base offset of vram pages
drm/amdgpu: add new member in amdgpu_mc for zfb support
drm
Am 07.02.2018 um 12:04 schrieb Chunming Zhou:
get the max io mapping address of system memory to see if it is over
our card accessing range.
Change-Id: Ibc38dbd34a20af5b4a4b1ed154c14e1c58aa4c55
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +++
drivers/gpu/
Am 07.02.2018 um 02:32 schrieb Felix Kuehling:
dGPUs work without IOMMUv2. Make IOMMUv2 initialization dependent on
ASIC information. Also allow building KFD without IOMMUv2 support.
This is still useful for dGPUs and prepares for enabling KFD on
architectures that don't support AMD IOMMUv2.
v2:
get the max io mapping address of system memory to see if it is over
our card accessing range.
Change-Id: Ibc38dbd34a20af5b4a4b1ed154c14e1c58aa4c55
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 14 ++
Sure, will make it turn off as default and make the limit configurable.
Thanks
Roger(Hongbo.He)
-Original Message-
From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com]
Sent: Wednesday, February 07, 2018 4:41 PM
To: He, Roger ; Thomas Hellstrom ;
amd-gfx@lists.freedesktop.org;
AMD prefers return value of no memory rather than OOM for now.
Yeah, but Thomas is right that the default for this feature should be
that it is turned off.
That's why I said that we should make the limit configurable.
Regards,
Christian.
Am 07.02.2018 um 09:25 schrieb He, Roger:
Why
Why should TTM be different in that aspect? It would be good to know
your reasoning WRT this?
Now, in TTM struct ttm_bo_device it already has member no_retry to indicate
your option.
If you prefer no OOM triggered by TTM, set it as true. The default is false to
keep original behavior.
60 matches
Mail list logo
