Re: [PATCH v6 2/3] drm/amd/display: Add freesync video modes based on preferred modes

Hi Aurabindo, Thank you for the patch! Yet something to improve: [auto build test ERROR on next-20210211] [also build test ERROR on v5.11-rc7] [cannot apply to drm-intel/for-linux-next drm-tip/drm-tip tegra-drm/drm/tegra/for-next linus/master drm-exynos/exynos-drm-next drm/drm-next v5.11-rc7

[PATCH] drm/amdgpu: Modify alloc_sgt apis to consider size of request

The current method that builds SG table does not allow its users to request a sub-block of the buffer object. The change modifies api signature to allow users to specify both the offset and size of the request. Signed-off-by: Ramesh Errabolu --- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c |

[PATCH v6 3/3] drm/amd/display: Skip modeset for front porch change

[Why] A seamless transition between modes can be performed if the new incoming mode has the same timing parameters as the optimized mode on a display with a variable vtotal min/max. Smooth video playback usecases can be enabled with this seamless transition by switching to a new mode which has a

[PATCH v6 2/3] drm/amd/display: Add freesync video modes based on preferred modes

[Why] While possible for userspace to create and add custom mode based off the optimized mode for the connected display which differs only in front porch timing, this patch set adds a list of common video modes in advance. The list of common video refresh rates is small, well known and the

[PATCH v6 1/3] drm/amd/display: Add module parameter for freesync video mode

[Why] This option shall be opt-in by default since it is a temporary solution until long term solution is agreed upon which may require userspace interface changes. This feature give the user a seamless experience when freesync aware programs (media players for instance) switches to a compatible

[PATCH v6 0/3] Freesync video mode optimization

Changes in V6 = 1) Skip modeset for front porch change * Minor optimizations 2) Add freesync video modes based on preferred modes: * Remove edid parsing and use the already parsed valuescached in dm for the monitor's freesync range 3) Add module parameter for freesync video

Re: Why no spatial dithering to 10 bit depth on DCE?

On Fri, Feb 12, 2021 at 6:32 AM Alex Deucher wrote: > On Thu, Feb 11, 2021 at 4:12 PM Mario Kleiner > wrote: > > > > On Wed, Feb 10, 2021 at 10:36 PM Alex Deucher > wrote: > >> > >> On Wed, Feb 10, 2021 at 4:08 PM Mario Kleiner > >> wrote: > >> > > >> > Resending this one as well, in the hope

[PATCH] drm/amd/display: Allow spatial dither to 10 bpc on all != DCE-11.0.

Spatial dithering to 10 bpc depth was disabled for all DCE's. Restrict this to DCE-11.0, but allow it on other DCE's. Testing on DCE-8.3 and DCE-11.2 did not show any obvious ill effects, but a measureable precision improvement (via colorimeter) when displaying a fp16 framebuffer to a 10 bpc DP

Re: [PATCH 3/3] drm/amd/display: Skip modeset for front porch change

On 2021-02-08 10:06 a.m., Kazlauskas, Nicholas wrote: On 2021-01-24 11:00 p.m., Aurabindo Pillai wrote: On 2021-01-21 2:05 p.m., Kazlauskas, Nicholas wrote: On 2021-01-19 10:50 a.m., Aurabindo Pillai wrote: [Why] A seamless transition between modes can be performed if the new incoming

Re: [PATCH 1/1] drm/amdgpu: do not use drm's debugfs middle layer

On 2/12/21 7:30 PM, Christian König wrote: Am 12.02.21 um 19:20 schrieb Nirmoy Das: drm_debugfs_create_files() is a drm middle layer that drm drivers can avoid by directly using debugfs_create_file() But creating our own mid layer isn't the right thing either :) For example

Re: [PATCH 1/1] drm/amdgpu: do not use drm's debugfs middle layer

Am 12.02.21 um 19:20 schrieb Nirmoy Das: drm_debugfs_create_files() is a drm middle layer that drm drivers can avoid by directly using debugfs_create_file() But creating our own mid layer isn't the right thing either :) For example amdgpu_debugfs_get_vbios_dump() should probably be replaced

[PATCH 1/1] drm/amdgpu: do not use drm's debugfs middle layer

drm_debugfs_create_files() is a drm middle layer that drm drivers can avoid by directly using debugfs_create_file() Signed-off-by: Nirmoy Das --- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 131 +++---

[PATCH] Revert "drm/amd/display: Check lane status again after link training done"

This reverts commit 3fd20292c2352660155bbc11736dd014b2fc6e98. Fixes a display corruption issue on resume and undetected modes on some monitors. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1424 Bug: https://bugzilla.kernel.org/show_bug.cgi?id=208947 Cc: Martin Tsai Cc: Aric Cyr Cc:

Re: [PATCH 1/1] drm/amdgpu/display: remove hdcp_srm sysfs

[AMD Official Use Only - Internal Distribution Only] Acked-by: Alex Deucher From: amd-gfx on behalf of Nirmoy Sent: Friday, February 12, 2021 11:59 AM To: Das, Nirmoy ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH 1/1] drm/amdgpu/display: remove

Re: [PATCH 1/1] drm/amdgpu/display: remove hdcp_srm sysfs

ping! I should've added more info into the subject line : s/remove hdcp_srm sysfs/remove hdcp_srm sysfs on device removal Without this patch I get below error on second/later modprobes [ 404.362298] sysfs: cannot create duplicate filename

Re: [PATCH v4 11/14] drm/amdgpu: Guard against write accesses after device removal

Ping Andrey On 2/10/21 5:01 PM, Andrey Grodzovsky wrote: On 2/9/21 10:40 AM, Christian König wrote: Am 09.02.21 um 15:30 schrieb Andrey Grodzovsky: [SNIP] Question - Why can't we just set those PTEs to point to system memory (another RO dummy page) filled with 1s ? Then writes are not