[PATCH 2/2] drm/amdgpu: use amdgpu_bo_param for amdgpu_bo_create v2

After that, we can easily add new parameter when need. v2: a) rebase. b) Initialize struct amdgpu_bo_param, future new member could only be used in some one case, but all member should have its own initial value. Change-Id: I6e80039c3801f163129ecc605d931483fdbc91db Signed-off-by: Chunming Zhou

[PATCH 1/2] drm/amdgpu: add amdgpu_bo_param

amdgpu_bo_create has too many parameters, and used in too many places. Collect them to one structure. Change-Id: Ib2aa98ee37a70f3cb0d61eef1d336e89187554d5 Signed-off-by: Chunming Zhou Reviewed-by: Huang Rui Reviewed-by: Christian König

Re: [PATCH 2/2] drm/amdgpu: use amdgpu_bo_parm for amdgpu_bo_create

On Mon, Apr 16, 2018 at 08:20:59PM +0800, Koenig, Christian wrote: > Am 16.04.2018 um 13:43 schrieb Huang Rui: > > On Mon, Apr 16, 2018 at 07:13:05PM +0800, Chunming Zhou wrote: > >> after that, we can easily add new parameter when need. > >> > >> Change-Id:

Re: Gamma problem after 4096 LUT entries change

On 04/16/2018 04:07 PM, Harry Wentland wrote: On 2018-04-15 05:37 AM, Môshe van der Sterre wrote: Hello Leo Li, The current mainline has a gamma regression for me, running wayland on a Ryzen 5 2400G (integrated gpu). Colors are much too dark after the following commit: 086247a4b2fb

Re: [PATCH] drm/amd/display: Don't program bypass on linear regamma LUT

On 2018-04-16 03:39 PM, Harry Wentland wrote: Even though this is required for degamma since DCE HW only supports a couple predefined LUTs we can just program the LUT directly for regamma. This fixes dark screens which occurs when we program regamma to bypass while degamma is using srgb LUT.

[PATCH] drm/amd/display: Don't program bypass on linear regamma LUT

Even though this is required for degamma since DCE HW only supports a couple predefined LUTs we can just program the LUT directly for regamma. This fixes dark screens which occurs when we program regamma to bypass while degamma is using srgb LUT. Signed-off-by: Harry Wentland

Re: [PATCH 1/2] drm/amd/pp: Adding set_watermarks_for_clocks_ranges for SMU10

Series is: Acked-by: Alex Deucher From: amd-gfx on behalf of mikita.lip...@amd.com Sent: Monday, April 16, 2018 11:22:46 AM To: amd-gfx@lists.freedesktop.org; Wentland,

[PATCH 1/2] drm/amd/pp: Adding set_watermarks_for_clocks_ranges for SMU10

From: Mikita Lipski The function is never implemented for raven on linux. It follows similair implementation as on windows. SMU still needs to notify SMC and copy WM table, which is added here. But on other Asics such as Vega this step is not implemented. Signed-off-by:

[PATCH 2/2] drm/amd/pp: Adding a function to store cc6 data in SMU10

From: Mikita Lipski Filling the smu10_store_cc6_data based on the implementation of Windows Powerplay. There is an uncertainty with one of the parameters passed to the function pstate_switch_disable - is not a part of smu10 private data structure. So in the function its

Re: Gamma problem after 4096 LUT entries change

On 2018-04-15 05:37 AM, Môshe van der Sterre wrote: > Hello Leo Li, > > The current mainline has a gamma regression for me, running wayland on a > Ryzen 5 2400G (integrated gpu). Colors are much too dark after the following > commit: > 086247a4b2fb "drm/amd/display: Use 4096 lut entries" > >

Re: [PATCH 2/2] Revert "drm/amd/display: disable CRTCs with NULL FB on their primary plane (V2)"

On 2018-04-13 03:15 AM, Michel Dänzer wrote: > On 2018-04-13 04:55 AM, S, Shirish wrote: >> Hi Harry, Alex, >> >> The solution given while reviewing my patch was that "DC should support >> enabling a CRTC without a framebuffer." > > I think it's weird that an enabled CRTC would end up having a

Re: [PATCH 4/8] dma-buf: add peer2peer flag

On Mon, Apr 16, 2018 at 2:39 PM, Christoph Hellwig wrote: > On Tue, Apr 03, 2018 at 08:08:32PM +0200, Daniel Vetter wrote: >> I did not mean you should dma_map_sg/page. I just meant that using >> dma_map_resource to fill only the dma address part of the sg table seems >>

Re: [PATCH 4/8] dma-buf: add peer2peer flag

On Tue, Apr 03, 2018 at 08:08:32PM +0200, Daniel Vetter wrote: > I did not mean you should dma_map_sg/page. I just meant that using > dma_map_resource to fill only the dma address part of the sg table seems > perfectly sufficient. But that is not how the interface work, especially facing

Re: [PATCH 1/2] drm/amdgpu: add amdgpu_bo_param

Am 16.04.2018 um 13:13 schrieb Chunming Zhou: Change-Id: Ib2aa98ee37a70f3cb0d61eef1d336e89187554d5 Signed-off-by: Chunming Zhou Reviewed-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 81 +-

Re: [PATCH 2/2] drm/amdgpu: use amdgpu_bo_parm for amdgpu_bo_create

Am 16.04.2018 um 13:43 schrieb Huang Rui: On Mon, Apr 16, 2018 at 07:13:05PM +0800, Chunming Zhou wrote: after that, we can easily add new parameter when need. Change-Id: I6e80039c3801f163129ecc605d931483fdbc91db Signed-off-by: Chunming Zhou Cc: christian.koe...@amd.com

Re: [PATCH 2/2] drm/amdgpu: use amdgpu_bo_parm for amdgpu_bo_create

On Mon, Apr 16, 2018 at 07:13:05PM +0800, Chunming Zhou wrote: > after that, we can easily add new parameter when need. > > Change-Id: I6e80039c3801f163129ecc605d931483fdbc91db > Signed-off-by: Chunming Zhou > Cc: christian.koe...@amd.com > Cc: felix.kuehl...@amd.com > --- >

Re: [PATCH 1/2] drm/amdgpu: add amdgpu_bo_param

On Mon, Apr 16, 2018 at 07:13:04PM +0800, Chunming Zhou wrote: > Change-Id: Ib2aa98ee37a70f3cb0d61eef1d336e89187554d5 > Signed-off-by: Chunming Zhou Reviewed-by: Huang Rui > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 81 >

[PATCH 1/2] drm/amdgpu: add amdgpu_bo_param

Change-Id: Ib2aa98ee37a70f3cb0d61eef1d336e89187554d5 Signed-off-by: Chunming Zhou --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 81 +- drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 9 2 files changed, 54 insertions(+), 36 deletions(-)

[PATCH 2/2] drm/amdgpu: use amdgpu_bo_parm for amdgpu_bo_create

after that, we can easily add new parameter when need. Change-Id: I6e80039c3801f163129ecc605d931483fdbc91db Signed-off-by: Chunming Zhou Cc: christian.koe...@amd.com Cc: felix.kuehl...@amd.com --- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 12 ++--

Re: [PATCH 3/3] drm/amdgpu: set preferred_domain independent of fallback handling

On 2018年04月16日 17:36, Christian König wrote: Am 16.04.2018 um 11:21 schrieb zhoucm1: On 2018年04月16日 17:04, zhoucm1 wrote: On 2018年04月16日 16:57, Christian König wrote: Am 11.04.2018 um 11:22 schrieb Christian König: Am 11.04.2018 um 04:38 schrieb zhoucm1: On 2018年04月10日 21:42,

Re: [PATCH 3/3] drm/amdgpu: set preferred_domain independent of fallback handling

Am 16.04.2018 um 11:21 schrieb zhoucm1: On 2018年04月16日 17:04, zhoucm1 wrote: On 2018年04月16日 16:57, Christian König wrote: Am 11.04.2018 um 11:22 schrieb Christian König: Am 11.04.2018 um 04:38 schrieb zhoucm1: On 2018年04月10日 21:42, Christian König wrote: When GEM needs to fallback to

Re: [PATCH] drm/amdgpu: defer test IBs on the rings at boot (V3)

On 04/16/2018 05:19 PM, Christian König wrote: Am 16.04.2018 um 11:04 schrieb Zhang, Jerry (Junwei): On 04/16/2018 03:17 PM, Shirish S wrote: amdgpu_ib_ring_tests() runs test IB's on rings at boot contributes to ~500 ms of amdgpu driver's boot time. This patch defers it and ensures that its

Re: [PATCH 3/3] drm/amdgpu: set preferred_domain independent of fallback handling

On 2018年04月16日 17:04, zhoucm1 wrote: On 2018年04月16日 16:57, Christian König wrote: Am 11.04.2018 um 11:22 schrieb Christian König: Am 11.04.2018 um 04:38 schrieb zhoucm1: On 2018年04月10日 21:42, Christian König wrote: When GEM needs to fallback to GTT for VRAM BOs we still want the

Re: [PATCH] drm/amdgpu: defer test IBs on the rings at boot (V3)

Am 16.04.2018 um 11:04 schrieb Zhang, Jerry (Junwei): On 04/16/2018 03:17 PM, Shirish S wrote: amdgpu_ib_ring_tests() runs test IB's on rings at boot contributes to ~500 ms of amdgpu driver's boot time. This patch defers it and ensures that its executed in amdgpu_info_ioctl() if it wasn't

Re: [PATCH 3/3] drm/amdgpu: set preferred_domain independent of fallback handling

On 2018年04月16日 16:57, Christian König wrote: Am 11.04.2018 um 11:22 schrieb Christian König: Am 11.04.2018 um 04:38 schrieb zhoucm1: On 2018年04月10日 21:42, Christian König wrote: When GEM needs to fallback to GTT for VRAM BOs we still want the preferred domain to be untouched so that the

Re: [PATCH] drm/amdgpu: defer test IBs on the rings at boot (V3)

On 04/16/2018 03:17 PM, Shirish S wrote: amdgpu_ib_ring_tests() runs test IB's on rings at boot contributes to ~500 ms of amdgpu driver's boot time. This patch defers it and ensures that its executed in amdgpu_info_ioctl() if it wasn't scheduled. V2: Use queue_delayed_work() &

Re: [PATCH 3/3] drm/amdgpu: set preferred_domain independent of fallback handling

Am 11.04.2018 um 11:22 schrieb Christian König: Am 11.04.2018 um 04:38 schrieb zhoucm1: On 2018年04月10日 21:42, Christian König wrote: When GEM needs to fallback to GTT for VRAM BOs we still want the preferred domain to be untouched so that the BO has a cance to move back to VRAM in the

Re: [RFC] Rewrite page fault interception in TTM drivers

Am 15.04.2018 um 05:31 schrieb Matthew Wilcox: Three^W Two of the TTM drivers intercept the pagefault handler in a rather un-Linuxy and racy way. If they really must intercept the fault call (and it's not clear to me that they need to), I'd rather see them do it like this. The QXL driver seems

Re: [PATCH] drm/amdgpu: defer test IBs on the rings at boot (V3)

Am 16.04.2018 um 09:17 schrieb Shirish S: amdgpu_ib_ring_tests() runs test IB's on rings at boot contributes to ~500 ms of amdgpu driver's boot time. This patch defers it and ensures that its executed in amdgpu_info_ioctl() if it wasn't scheduled. V2: Use queue_delayed_work() &

Re: Raven Ridge Ryzen 2500U hang reproduced

On 14.04.2018 00:24, Bráulio Bhavamitra wrote: It ALWAYS crashes on shader15 of http://www.graphicsfuzz.com/benchmark/android-v1.html. This is very likely an unrelated issue to any kind of desktop hang you're seeing. The graphics fuzz shaders are the result of fuzzing to intentionally

Gamma problem after 4096 LUT entries change

Hello Leo Li, The current mainline has a gamma regression for me, running wayland on a Ryzen 5 2400G (integrated gpu). Colors are much too dark after the following commit: 086247a4b2fb "drm/amd/display: Use 4096 lut entries" From this commit alone I cannot deduce how to properly address the

[RFC] Rewrite page fault interception in TTM drivers

Three^W Two of the TTM drivers intercept the pagefault handler in a rather un-Linuxy and racy way. If they really must intercept the fault call (and it's not clear to me that they need to), I'd rather see them do it like this. The QXL driver seems least likely to need it; as the virtio driver

[PATCH] drm/amdgpu: defer test IBs on the rings at boot (V3)

amdgpu_ib_ring_tests() runs test IB's on rings at boot contributes to ~500 ms of amdgpu driver's boot time. This patch defers it and ensures that its executed in amdgpu_info_ioctl() if it wasn't scheduled. V2: Use queue_delayed_work() & flush_delayed_work(). V3: removed usage of separate wq,

Re: [PATCH] drm/amdgpu: defer test IBs on the rings at boot (V2)

On 4/13/2018 10:20 PM, Alex Deucher wrote: On Fri, Apr 13, 2018 at 9:25 AM, Christian König wrote: Am 13.04.2018 um 10:31 schrieb Shirish S: amdgpu_ib_ring_tests() runs test IB's on rings at boot contributes to ~500 ms of amdgpu driver's boot time. This patch