On 11/10/2017 10:48 AM, Christian König wrote:
Am 10.11.2017 um 16:36 schrieb Andrey Grodzovsky:
On 11/10/2017 07:17 AM, Christian König wrote:
Series is Acked-by: Christian König .
Please note that I think your OOM killer test shows quite a bug we
currently have in the kernel driver.
A
The bottom two bits of the simd value were being put into
the upper bits of the wave value which was likely working due
to the bits being ignored (or aliased).
Eitherway, now we mask it correctly.
Signed-off-by: Tom St Denis
(v2) Touch up using GENMASK_ULL to a couple of other functions too
---
On 11/09/2017 03:05 PM, Harry Wentland wrote:
From: "Leo (Sunpeng) Li"
When disabling pipe splitting, we need to make sure we disable both
planes used.
This should be done for Linux as well.
Change-Id: I79f5416a55bd26c19ca3cfb346a943d69872a8ce
Signed-off-by: Leo (Sunpeng) Li
Reviewed-by: T
On Fri, Nov 10, 2017 at 03:50:51PM +0100, Piotr Redlewski wrote:
> On Fri, Nov 10, 2017 at 12:55:09PM +0100, Christian König wrote:
> > Am 10.11.2017 um 12:34 schrieb Piotr Redlewski:
> > > When UVD bo is created, its size is based on the information from firmware
> > > header (ucode_size_bytes). T
On 11/10/2017 01:38 PM, Andrey Grodzovsky wrote:
On 11/09/2017 03:05 PM, Harry Wentland wrote:
From: "Leo (Sunpeng) Li"
This is a followup to the following revert:
Rex ZhuRevert "drm/amd/display: Match actual state during S3
resume."
Three things needed to be addressed:
On 11/09/2017 03:05 PM, Harry Wentland wrote:
From: "Leo (Sunpeng) Li"
This is a followup to the following revert:
Rex ZhuRevert "drm/amd/display: Match actual state during S3
resume."
Three things needed to be addressed:
1. Potential memory leak on dc_state creation in ato
On 10/11/17 01:20 PM, Christian König wrote:
Am 10.11.2017 um 19:03 schrieb Tom St Denis:
The bottom two bits of the simd value were being put into
the upper bits of the wave value which was likely working due
to the bits being ignored (or aliased).
Eitherway, now we mask it correctly.
Signed-
When UVD bo is created, its size is based on the information from firmware
header (ucode_size_bytes). The same value should be be used when programming
UVD mc controller offsets, otherwise it can happen that
(mmUVD_VCPU_CACHE_OFFSET2 + mmUVD_VCPU_CACHE_SIZE2) will point
AMDGPU_GPU_PAGE_SIZE bytes a
Am 10.11.2017 um 19:03 schrieb Tom St Denis:
The bottom two bits of the simd value were being put into
the upper bits of the wave value which was likely working due
to the bits being ignored (or aliased).
Eitherway, now we mask it correctly.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/am
Apperently I didn't test this patch enough - UVD boots, vdpauinfo reports
correctly, but actual video playback performance is severly impacted. Version 3
of this patch is on the way.
Regards,
Piotr
On Fri, Nov 10, 2017 at 03:26:49PM +0100, Piotr Redlewski wrote:
> When UVD bo is created, its size
The bottom two bits of the simd value were being put into
the upper bits of the wave value which was likely working due
to the bits being ignored (or aliased).
Eitherway, now we mask it correctly.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
1 file changed,
On 11/09/2017 03:05 PM, Harry Wentland wrote:
From: Andrew Jiang
dc_link is at a higher level than link_encoder, and we only want
higher-level components to be able to access lower-level ones,
not the other way around.
Change-Id: I634b117b386938fb7ddba50c50484fadd54ad485
Signed-off-by: Andre
On 09/11/17 06:13 PM, Christian König wrote:
> Am 09.11.2017 um 17:50 schrieb Michel Dänzer:
>> On 09/11/17 09:59 AM, Christian König wrote:
>>> Consistently use the reservation object wrappers instead of accessing
>>> the ww_mutex directly.
>>>
>>> Additional to that use the reservation object wra
Am 10.11.2017 um 16:36 schrieb Andrey Grodzovsky:
On 11/10/2017 07:17 AM, Christian König wrote:
Series is Acked-by: Christian König .
Please note that I think your OOM killer test shows quite a bug we
currently have in the kernel driver.
A single allocation of 1TB shouldn't trigger the OO
From: Bhawanpreet Lakha
This struct is not updated on page flip and causes vblank_mode
to not work as expected
Change-Id: I0e8684c5b67ec5670054f4bb849fa26bc60ed4b1
Signed-off-by: Bhawanpreet Lakha
Reviewed-by: Tony Cheng
Acked-by: Harry Wentland
Tested-by: Michel Dänzer
---
drivers/gpu/drm/
On 11/10/2017 07:17 AM, Christian König wrote:
Series is Acked-by: Christian König .
Please note that I think your OOM killer test shows quite a bug we
currently have in the kernel driver.
A single allocation of 1TB shouldn't trigger the OOM killer, but
rather be reacted immediately.
May
On Fri, Nov 10, 2017 at 12:55:09PM +0100, Christian König wrote:
> Am 10.11.2017 um 12:34 schrieb Piotr Redlewski:
> > When UVD bo is created, its size is based on the information from firmware
> > header (ucode_size_bytes). The same value should be be used when programming
> > UVD mc controller of
When UVD bo is created, its size is based on the information from firmware
header (ucode_size_bytes). The same value should be be used when programming
UVD mc controller offsets, otherwise it can happen that
(mmUVD_VCPU_CACHE_OFFSET2 + mmUVD_VCPU_CACHE_SIZE2) will point
AMDGPU_GPU_PAGE_SIZE bytes a
-Original Message-
From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com]
Sent: Friday, November 10, 2017 8:02 PM
To: He, Roger ; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amd/amdgpu: not allow gtt size exceed system memory
size
Am 10.11.2017 um 12:33 schrieb Roge
Am 10.11.2017 um 13:17 schrieb Christian König:
Series is Acked-by: Christian König .
Please note that I think your OOM killer test shows quite a bug we
currently have in the kernel driver.
A single allocation of 1TB shouldn't trigger the OOM killer, but
rather be reacted immediately.
Typo
Am 10.11.2017 um 13:23 schrieb He, Roger:
-Original Message-
From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com]
Sent: Friday, November 10, 2017 8:02 PM
To: He, Roger ; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amd/amdgpu: not allow gtt size exceed system memory
Am 10.11.2017 um 13:17 schrieb Roger He:
Change-Id: Ib30efa5f007fce12a85a66722a8c9f76496f2dec
Signed-off-by: Roger He
Yep, exactly what I had in mind during our discussion as well.
Patch is Reviewed-by: Christian König .
Thanks for taking care of this,
Christian.
---
drivers/gpu/drm/amd/
Change-Id: Ib30efa5f007fce12a85a66722a8c9f76496f2dec
Signed-off-by: Roger He
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index fb72edc..a1eaabb 100644
--- a/
Series is Acked-by: Christian König .
Please note that I think your OOM killer test shows quite a bug we
currently have in the kernel driver.
A single allocation of 1TB shouldn't trigger the OOM killer, but rather
be reacted immediately.
Instead I expected that we need to do multiple 1GB al
Am 10.11.2017 um 12:33 schrieb Roger He:
since sometimes VRAM size is bigger than system memory
Change-Id: I5b14d18ed7a9f79810cc50c023ac9e240bddf101
Signed-off-by: Roger He
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --g
Am 10.11.2017 um 12:34 schrieb Piotr Redlewski:
When UVD bo is created, its size is based on the information from firmware
header (ucode_size_bytes). The same value should be be used when programming
UVD mc controller offsets, otherwise it can happen that
(mmUVD_VCPU_CACHE_OFFSET2 + mmUVD_VCPU_CA
since sometimes VRAM size is bigger than system memory
Change-Id: I5b14d18ed7a9f79810cc50c023ac9e240bddf101
Signed-off-by: Roger He
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
When UVD bo is created, its size is based on the information from firmware
header (ucode_size_bytes). The same value should be be used when programming
UVD mc controller offsets, otherwise it can happen that
(mmUVD_VCPU_CACHE_OFFSET2 + mmUVD_VCPU_CACHE_SIZE2) will point
AMDGPU_GPU_PAGE_SIZE bytes a
Please see comments inline
-Original Message-
From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com]
Sent: Wednesday, November 08, 2017 11:00 PM
To: He, Roger ; amd-gfx@lists.freedesktop.org;
dri-de...@lists.freedesktop.org
Subject: [PATCH 3/4] drm/ttm: make unlocking in ttm_bo_
static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo,
bool interruptible, bool no_wait_gpu,
bool unlock_resv)
{
..
ttm_bo_del_from_lru(bo);
list_del_init(&bo->ddestroy);
kref_put(&bo->list_kref,
He, Roger would like to recall the message, "[PATCH 3/4] drm/ttm: make
unlocking in ttm_bo_cleanup_refs optional".
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
He, Roger would like to recall the message, "[PATCH 3/4] drm/ttm: make
unlocking in ttm_bo_cleanup_refs optional".
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
He, Roger would like to recall the message, "[PATCH 3/4] drm/ttm: make
unlocking in ttm_bo_cleanup_refs optional".
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
On 09/11/17 09:05 PM, Harry Wentland wrote:
> From: Bhawanpreet Lakha
>
> This struct is not updated on page flip and causes vblank_mode
> to not work as expected
>
> Change-Id: I0e8684c5b67ec5670054f4bb849fa26bc60ed4b1
> Signed-off-by: Bhawanpreet Lakha
> Reviewed-by: Tony Cheng
> Acked-by: H
On 10/11/17 10:14 AM, S, Shirish wrote:
> From: Shirish S
>
> This patch fixes static checker warning of
> "warn: cast after binop" introduced by
> 56087b31 drm/amd/display: fix high part address in
> dm_plane_helper_prepare_fb()
>
> Signed-off-by: Shirish S
> ---
> drivers/gpu/drm/amd/displa
From: Shirish S
This patch fixes static checker warning of
"warn: cast after binop" introduced by
56087b31 drm/amd/display: fix high part address in dm_plane_helper_prepare_fb()
Signed-off-by: Shirish S
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
1 file changed, 1 insertion(+
On 10/11/17 06:10 AM, S, Shirish wrote:
> On 11/7/2017 2:06 PM, Michel Dänzer wrote:
>> On 07/11/17 04:29 AM, S, Shirish wrote:
>>> From: Shirish S
>>>
>>> This patch fixes static checker warning of
>>> "warn: cast after binop" introduced by
>>> 4d3e00dad80a: "drm/amd/display : add high part addre
That way please add comments like "w/a for ring test fail after GPU reset, root
cause unknown"
Ack-by: Monk
-Original Message-
From: Yu, Xiangliang
Sent: 2017年11月10日 16:58
To: Liu, Monk ; amd-gfx@lists.freedesktop.org
Subject: RE: [PATCH] drm/amdgpu/gfx8: Fix compute ring failure after
> The ring clear is already before "ring test", you patch just postpone the ring
> clear to an even later point, Do you know the root cause of your fix ?
Yes, just postpone it. Still can't find the root cause and the issue only
happen on gfx8.
I'm ok if you can find better solution.
> -Orig
The ring clear is already before "ring test", you patch just postpone the ring
clear to an even later point,
Do you know the root cause of your fix ?
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
Xiangliang.Yu
Sent: 2017年11月10日 14:52
To: amd
Do ring clear before ring test, otherwise compute ring test will
fail after gpu resetting.
Signed-off-by: Xiangliang.Yu
---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
b/drivers/gpu/drm/a
41 matches
Mail list logo
