Re: [PATCH 3/3] drm/amdgpu/powerplay/vega10: enable AVFS control via ppfeaturemask

Series is: Reviewed-by: Rex Zhu Regards Rex From: amd-gfx on behalf of Alex Deucher Sent: Saturday, August 11, 2018 2:24 AM To: amd-gfx@lists.freedesktop.org Cc: Deucher, Alexander Subject: [PATCH 3/3] drm/amdgpu/powerplay/vega10: enable AVFS control via

[PATCH libdrm] amdgpu: add a function to create amdgpu bo internally (v3)

a helper function to create and initialize amdgpu bo v2: update error handling: add label and free bo v3: update error handling: separate each error label Signed-off-by: Junwei Zhang --- amdgpu/amdgpu_bo.c | 196 ++--- 1 file changed, 95

Re: [PATCH v2 5/5] drm/amdgpu:add VCN booting with firmware loaded by PSP

Why only the mmUVD_LMI_VCPU_CACHE_64BIT_BAR_LOW/HIGH use the new tmr_mc_addr? And the mmUVD_LMI_VCPU_CACHE1_64BIT_BAR_LOW/HIGH and mmUVD_LMI_VCPU_CACHE1_64BIT_BAR_LOW/HIGH still use the old adev->vcn.gpu_addr? Regards, Evan From: amd-gfx on behalf of James

[PATCH 2/2] drm/amdgpu/vce: VCE entity initialization relies on ring initializtion

Entity init should after ring init, as the entity's sched_rq's initialization is in ring init. SWDEV-161495 Signed-off-by: Emily Deng --- drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 33 +++-- drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h | 1 +

[PATCH 1/2] drm/amdgpu/uvd: UVD entity initialization relys on ring initialization

Entity init should after ring init, as the entity's sched_rq's initialization is in ring init. SWDEV-161495 Signed-off-by: Emily Deng --- drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 32 +++- drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.h | 1 +

Re: [PATCH libdrm 2/2] [RFC] amdgpu: do not free flink bo for flink_fd

On 08/10/2018 10:20 PM, Christian König wrote: Am 10.08.2018 um 07:05 schrieb Junwei Zhang: the flink bo is used to export Why should we do this? That makes no sense, this way we would create a memory leak. Get the thought from bo_import code, but neglected the detail of

Re: [PATCH] drm/amdgpu: move amdgpu ttm structures to amdgpu_ttm.h

On 08/10/2018 10:21 PM, Christian König wrote: Well NAK, that is intentionally kept local to the amdgpu_ttm.c file. This way we can make sure that we don't accidentally leak the structure somewhere else. Thanks to explain that. I thought those were left in the file accidentally. Then fine to

Re: [PATCH v2 0/5] drm/ttm, amdgpu: Introduce LRU bulk move functionality

Hi I've been testing these patches over the weekend on my Tonga and Raven systems Tested-by: Mike Lothian Cheers Mike On Fri, 10 Aug 2018 at 12:56 Huang Rui wrote: > The idea and proposal is originally from Christian, and I continue to work > to > deliver it. > > Background: > amdgpu

[PATCH v3 1/3] drm/amd/display: enable ABGR and XBGR formats (v4)

SURFACE_PIXEL_FORMAT_GRPH_ABGR is supported in amd/display/dc/dc_hw_types.h and the necessary crossbars register controls to swap red and blue channels are already implemented in drm/amd/display/dc/dce/dce_mem_input.c (v4) Logic to handle new formats is added only in amdgpu_dm module.

[PATCH v3 3/3] drm/radeon: enable ABGR and XBGR formats (v2)

Add support for DRM_FORMAT_{A,X}BGR in atombios_crtc Swapping of red and blue channels is implemented for radeon chipsets: DCE2/R6xx and later - crossbar registers defined where needed and used DCE1/R5xx - AVIVO_D1GRPH_SWAP_RB bit is used (v2) Set AVIVO_D1GRPH_SWAP_RB bit in fb_format, using

[PATCH v3 2/3] drm/amdgpu: enable ABGR and XBGR formats (v2)

Add support for DRM_FORMAT_{A,X}BGR in amdgpu with amd dc disabled (v2) Crossbar registers are defined and used to swap red and blue channels, keeping the existing coding style in each of the dce modules. After setting crossbar bits in fb_swap, use bitwise OR for big endian

[PATCH v3] drm/radeon,amdgpu,dc: enable ABGR and XBGR formats

Sending PATCH v3 series for support of {A,X}RGB pixel formats in DCE1/R5xx and later, with separated patches for amd dc, amdgpu and radeon, based on Alexander Deucher comments Tested and working on R5xx (X1300), R6xx (HD2400), R7xx (HD4830), Juniper (HD5770), Turks (HD7600M), Tahiti (HD7950),

Re: [PATCH] [v3] drm: amd: dc: don't use FP math when Kcov is enabled

Adding Harry as well. Am 11.08.2018 um 17:54 schrieb Arnd Bergmann: Building the DCN 1.0 Raven display driver with CONFIG_KCOV_INSTRUMENT_ALL=y and CONFIG_KCOV_ENABLE_COMPARISONS=y results in warnings about many functions that do a comparison of floating-point variables: