Re: [PATCH v2 2/3] drm: Add variable refresh property to DRM CRTC

On 10/05/2018 12:56 PM, Michel Dänzer wrote: On 2018-10-05 6:21 p.m., Kazlauskas, Nicholas wrote: On 10/05/2018 04:10 AM, Pekka Paalanen wrote: 2. User preference A toggle on the desktop environment's display settings application to allow or disallow VRR. After all, video mode

Re: [PATCH v2 2/3] drm: Add variable refresh property to DRM CRTC

On 10/05/2018 04:10 AM, Pekka Paalanen wrote: Hi, I have a somewhat of my own view on what would be involved with VRR, and I'd like to hear what you think of it. Comments inline. On Tue, 25 Sep 2018 09:51:37 -0400 "Kazlauskas, Nicholas" wrote: On 09/24/2018 04:26 PM, Ville Syr

Re: [PATCH v4 4/4] drm/amd/display: Set FreeSync state using drm VRR properties

On 10/11/2018 04:39 PM, Harry Wentland wrote: On 2018-10-11 12:39 PM, Nicholas Kazlauskas wrote: Support for AMDGPU specific FreeSync properties and ioctls are dropped from amdgpu_dm in favor of supporting drm variable refresh rate properties. The drm vrr_capable property is now attached to

Re: [PATCH v2 2/3] drm: Add variable refresh property to DRM CRTC

On 10/15/2018 09:57 AM, Pekka Paalanen wrote: On Fri, 12 Oct 2018 08:58:23 -0400 "Kazlauskas, Nicholas" wrote: On 10/12/2018 07:20 AM, Koenig, Christian wrote: Am 12.10.2018 um 11:21 schrieb Pekka Paalanen: On Fri, 12 Oct 2018 07:35:57 + "Koenig, Christian" wrote:

Re: [PATCH v2 2/3] drm: Add variable refresh property to DRM CRTC

On 10/12/2018 07:20 AM, Koenig, Christian wrote: Am 12.10.2018 um 11:21 schrieb Pekka Paalanen: On Fri, 12 Oct 2018 07:35:57 + "Koenig, Christian" wrote: Am 12.10.2018 um 09:23 schrieb Pekka Paalanen: On Wed, 10 Oct 2018 09:35:50 -0400 "Kazlauskas, Nicholas" wro

Re: [PATCH v4 3/4] drm: Document variable refresh properties

On 10/26/18 7:37 AM, Pekka Paalanen wrote: > On Thu, 11 Oct 2018 12:39:41 -0400 > Nicholas Kazlauskas wrote: > >> These include the drm_connector 'vrr_capable' and the drm_crtc >> 'vrr_enabled' properties. >> >> Signed-off-by: Nicholas Kazlauskas >> --- >> Documentation/gpu/drm-kms.rst | 7

Re: [PATCH v4 3/4] drm: Document variable refresh properties

On 10/29/18 2:03 PM, Ville Syrjälä wrote: > On Mon, Oct 29, 2018 at 05:37:49PM +0100, Michel Dänzer wrote: >> On 2018-10-26 7:59 p.m., Ville Syrjälä wrote: >>> On Fri, Oct 26, 2018 at 05:34:15PM +, Kazlauskas, Nicholas wrote: >>>> On 10/26/18 10:53 AM, Ville Syrjä

Re: [PATCH v4 3/4] drm: Document variable refresh properties

On 11/1/18 6:58 AM, Michel Dänzer wrote: > On 2018-10-31 6:54 p.m., Kazlauskas, Nicholas wrote: >> On 10/31/18 12:20 PM, Michel Dänzer wrote: >>> On 2018-10-31 3:41 p.m., Kazlauskas, Nicholas wrote: >>>> On 10/31/18 10:12 AM, Michel Dänzer wrote: >>>>>

Re: [PATCH v4 3/4] drm: Document variable refresh properties

On 10/30/18 11:34 AM, Kazlauskas, Nicholas wrote: > On 10/30/18 5:29 AM, Michel Dänzer wrote: >> On 2018-10-29 7:03 p.m., Ville Syrjälä wrote: >>> On Mon, Oct 29, 2018 at 05:37:49PM +0100, Michel Dänzer wrote: >>>> On 2018-10-26 7:59 p.m., Ville Syrjälä wrote: >&

Re: [PATCH v4 3/4] drm: Document variable refresh properties

On 10/31/18 10:12 AM, Michel Dänzer wrote: > On 2018-10-31 2:38 p.m., Kazlauskas, Nicholas wrote: >> On 10/30/18 11:34 AM, Kazlauskas, Nicholas wrote: >>> On 10/30/18 5:29 AM, Michel Dänzer wrote: >>>> On 2018-10-29 7:03 p.m., Ville Syrjälä wrote: >>>>

Re: [PATCH v4 3/4] drm: Document variable refresh properties

On 10/31/18 12:20 PM, Michel Dänzer wrote: > On 2018-10-31 3:41 p.m., Kazlauskas, Nicholas wrote: >> On 10/31/18 10:12 AM, Michel Dänzer wrote: >>> On 2018-10-31 2:38 p.m., Kazlauskas, Nicholas wrote: >>>> On 10/30/18 11:34 AM, Kazlauskas, Nicholas wrote: >>>

Re: [PATCH v4 3/4] drm: Document variable refresh properties

On 10/26/18 10:53 AM, Ville Syrjälä wrote: > On Fri, Oct 26, 2018 at 02:49:31PM +0000, Kazlauskas, Nicholas wrote: >> On 10/26/18 7:37 AM, Pekka Paalanen wrote: >>> On Thu, 11 Oct 2018 12:39:41 -0400 >>> Nicholas Kazlauskas wrote: >>> >>>&

Re: [PATCH v4 3/4] drm: Document variable refresh properties

On 10/30/18 5:29 AM, Michel Dänzer wrote: > On 2018-10-29 7:03 p.m., Ville Syrjälä wrote: >> On Mon, Oct 29, 2018 at 05:37:49PM +0100, Michel Dänzer wrote: >>> On 2018-10-26 7:59 p.m., Ville Syrjälä wrote: >>>> On Fri, Oct 26, 2018 at 05:34:15PM +, Kazlauskas, Nic

Re: [PATCH v4 3/4] drm: Document variable refresh properties

On 10/26/18 3:13 PM, Manasi Navare wrote: > On Fri, Oct 26, 2018 at 05:34:15PM +0000, Kazlauskas, Nicholas wrote: >> On 10/26/18 10:53 AM, Ville Syrjälä wrote: >>> On Fri, Oct 26, 2018 at 02:49:31PM +, Kazlauskas, Nicholas wrote: >>>> On 10/26/18 7:37 AM, Pekka Pa

Re: [PATCH v4 3/4] drm: Document variable refresh properties

On 11/1/18 1:05 PM, Michel Dänzer wrote: > On 2018-11-01 3:58 p.m., Kazlauskas, Nicholas wrote: >> On 11/1/18 6:58 AM, Michel Dänzer wrote: >>> On 2018-10-31 6:54 p.m., Kazlauskas, Nicholas wrote: >>>> On 10/31/18 12:20 PM, Michel Dänzer wrote: >>>>>

Re: [PATCH v4 3/4] drm: Document variable refresh properties

On 10/29/18 4:36 AM, Pekka Paalanen wrote: > On Fri, 26 Oct 2018 17:34:15 + > "Kazlauskas, Nicholas" wrote: > >> On 10/26/18 10:53 AM, Ville Syrjälä wrote: >>> On Fri, Oct 26, 2018 at 02:49:31PM +, Kazlauskas, Nicholas wrote: >>>> On 10/26

Re: [PATCH v6 3/5] drm: Document variable refresh properties

On 11/7/18 9:57 AM, Wentland, Harry wrote: > > > On 2018-11-06 3:24 p.m., Nicholas Kazlauskas wrote: >> These include the drm_connector 'vrr_capable' and the drm_crtc >> 'vrr_enabled' properties. >> >> Signed-off-by: Nicholas Kazlauskas >> Cc: Harry Wentland >> Cc: Manasi Navare >> Cc: Pekka

Re: [PATCH 1/2] drm/amdgpu: Add "max_bpc" connector property

_connector_attach_max_bpc_property down the line. > > > *From:* amd-gfx on behalf of > Nicholas Kazlauskas > *Sent:* Wednesday, November 7, 2018 9:56:54 AM > *To:* amd-gfx@lists.freedesktop.org >

Re: [PATCH v7 3/5] drm: Document variable refresh properties

On 11/12/18 11:12 AM, Wentland, Harry wrote: > On 2018-11-08 9:43 a.m., Nicholas Kazlauskas wrote: >> These include the drm_connector 'vrr_capable' and the drm_crtc >> 'vrr_enabled' properties. >> >> Signed-off-by: Nicholas Kazlauskas >> Cc: Harry Wentland >> Cc: Manasi Navare >> Cc: Pekka

Re: [PATCH v3 1/4] drm: Add vrr_capable property to the drm connector

On 10/05/2018 06:10 PM, Manasi Navare wrote: On Fri, Oct 05, 2018 at 04:39:46PM -0400, Nicholas Kazlauskas wrote: Modern display hardware is capable of supporting variable refresh rates. This patch introduces the "vrr_capable" property on the connector to allow userspace to query support for

Re: [PATCH v2 2/3] drm: Add variable refresh property to DRM CRTC

On 10/10/2018 03:14 AM, Pekka Paalanen wrote: On Fri, 5 Oct 2018 12:21:20 -0400 "Kazlauskas, Nicholas" wrote: On 10/05/2018 04:10 AM, Pekka Paalanen wrote: Hi, I have a somewhat of my own view on what would be involved with VRR, and I'd like to hear what you think of it. Comme

Re: [PATCH v2 2/3] drm: Add variable refresh property to DRM CRTC

On 09/24/2018 04:26 PM, Ville Syrjälä wrote: On Mon, Sep 24, 2018 at 03:06:02PM -0400, Kazlauskas, Nicholas wrote: On 09/24/2018 02:38 PM, Ville Syrjälä wrote: On Mon, Sep 24, 2018 at 02:15:36PM -0400, Nicholas Kazlauskas wrote: Variable refresh rate algorithms have typically been enabled

Re: [PATCH v2 2/3] drm: Add variable refresh property to DRM CRTC

On 09/24/2018 02:38 PM, Ville Syrjälä wrote: On Mon, Sep 24, 2018 at 02:15:36PM -0400, Nicholas Kazlauskas wrote: Variable refresh rate algorithms have typically been enabled only when the display is covered by a single source of content. This patch introduces a new default CRTC property that

Re: [PATCH libdrm] amdgpu: update amdgpu_drm.h

On 1/16/19 11:24 AM, Koenig, Christian wrote: > Am 16.01.19 um 17:15 schrieb Marek Olšák: >> On Wed, Jan 16, 2019 at 2:37 AM Christian König >> > > wrote: >> >> Am 15.01.19 um 20:25 schrieb Marek Olšák: >> > From: Marek Olšák

Re: [PATCH] drm/amd/display: Skip create new stream if crtc state doesn't change

On 1/14/19 11:05 AM, Jerry (Fangzhi) Zuo wrote: > Need to check if crtc state is changed so that mode set is > required before trying to create new stream. > > It deals with the MST hotplug use case when plug back to the > same connector where the failure to create new stream for the > inactive

Re: [PATCH] drm/amd/display: Skip create new stream if crtc state doesn't change

On 1/14/19 1:41 PM, Jerry (Fangzhi) Zuo wrote: > Need to check if crtc state is changed so that mode set is > required before trying to create new stream. > > It deals with the MST hotplug use case when plug back to the > same connector where the failure to create new stream for the > inactive

Re: [PATCH 04/20] drm/amd/display: Know what a pageflip is

On 1/23/19 11:08 AM, Grodzovsky, Andrey wrote: > > > On 01/22/2019 01:28 PM, sunpeng...@amd.com wrote: >> From: David Francis >> >> [Why] >> We were assuming that any commit with allow_modeset == false >> was a pageflip. This was against drm intention and only >> worked by sheer luck >> >>

Re: [PATCH] drm/amd/display: Fix cursor pos and hotspot calcs

On 12/12/18 9:40 AM, Michel Dänzer wrote: > On 2018-12-12 3:17 p.m., Kazlauskas, Nicholas wrote: >> On 12/12/18 9:10 AM, Michel Dänzer wrote: >>> On 2018-12-12 3:04 p.m., Nicholas Kazlauskas wrote: >>>> [Why] >>>> The cursor calculations in amdgpu_dm incor

Re: [PATCH] drm/amd/display: Fix cursor pos and hotspot calcs

On 12/12/18 10:18 AM, Alex Deucher wrote: > On Wed, Dec 12, 2018 at 9:04 AM Nicholas Kazlauskas > wrote: >> >> [Why] >> The cursor calculations in amdgpu_dm incorrectly assume that the >> cursor hotspot is always (0, 0) and don't respect the hot_x and hot_y >> attributes that can be passed in via

Re: [PATCH] drm/amd/display: Add fast path for cursor plane updates

On 12/13/18 10:48 AM, Michel Dänzer wrote: > On 2018-12-05 8:59 p.m., Nicholas Kazlauskas wrote: >> [Why] >> Legacy cursor plane updates from drm helpers go through the full >> atomic codepath. A high volume of cursor updates through this slow >> code path can cause subsequent page-flips to skip

Re: [PATCH] drm/amd/display: Add fast path for cursor plane updates

On 12/13/18 2:21 PM, Kazlauskas, Nicholas wrote: > On 12/13/18 11:01 AM, Kazlauskas, Nicholas wrote: >> On 12/13/18 10:48 AM, Michel Dänzer wrote: >>> On 2018-12-05 8:59 p.m., Nicholas Kazlauskas wrote: >>>> [Why] >>>> Legacy cursor plane updates from d

Re: [PATCH] drm/amd/display: Add fast path for cursor plane updates

On 12/13/18 11:01 AM, Kazlauskas, Nicholas wrote: > On 12/13/18 10:48 AM, Michel Dänzer wrote: >> On 2018-12-05 8:59 p.m., Nicholas Kazlauskas wrote: >>> [Why] >>> Legacy cursor plane updates from drm helpers go through the full >>> atomic codepath. A h

Re: [PATCH 5/5] drm/amd/display: Move the dm update dance to crtc->atomic_check

On 12/18/18 10:26 AM, sunpeng...@amd.com wrote: > From: Leo Li > > drm_atomic_helper_check_planes() calls the crtc atomic check helpers. In > an attempt to better align with the DRM framework, we can move the > entire dm_update dance to the crtc check helper (since it essentially > checks that

Re: [PATCH] drm/amd/display: Skip fast cursor updates for fb changes

e bugs than this one to pop up since nothing else in DRM works like that. Nicholas Kazlauskas > > > On 12/14/2018 12:51 PM, Kazlauskas, Nicholas wrote: >> On 12/14/18 12:47 PM, Grodzovsky, Andrey wrote: >>> >>> On 12/14/2018 12:41 PM, Kazlauskas, Nicholas wrote: >&

Re: [PATCH] drm/amd/display: Add fast path for cursor plane updates

On 12/14/18 3:46 AM, Michel Dänzer wrote: > On 2018-12-13 9:59 p.m., Kazlauskas, Nicholas wrote: >> On 12/13/18 2:21 PM, Kazlauskas, Nicholas wrote: >>> On 12/13/18 11:01 AM, Kazlauskas, Nicholas wrote: >>>> On 12/13/18 10:48 AM, Michel Dänzer wrote: >>&

Re: [PATCH] drm/amd/display: Don't cleanup new cursor fb in fast cursor update

On 12/14/18 10:01 AM, Michel Dänzer wrote: > On 2018-12-14 3:48 p.m., Nicholas Kazlauskas wrote: >> [Why] >> The behavior of dm_plane_helper_cleanup_fb differs depending on >> whether the commit was asynchronous or not. When it's called from >> amdgpu_dm_atomic_commit_tail during a typical atomic

Re: [PATCH] drm/amd/display: Fix cursor pos and hotspot calcs

On 12/12/18 9:10 AM, Michel Dänzer wrote: > On 2018-12-12 3:04 p.m., Nicholas Kazlauskas wrote: >> [Why] >> The cursor calculations in amdgpu_dm incorrectly assume that the >> cursor hotspot is always (0, 0) and don't respect the hot_x and hot_y >> attributes that can be passed in via the

Re: [PATCH] drm/amd/display: Don't cleanup new cursor fb in fast cursor update

On 12/14/18 10:19 AM, Kazlauskas, Nicholas wrote: > On 12/14/18 10:01 AM, Michel Dänzer wrote: >> On 2018-12-14 3:48 p.m., Nicholas Kazlauskas wrote: >>> [Why] >>> The behavior of dm_plane_helper_cleanup_fb differs depending on >>> whether the commit was asynch

Re: [PATCH] drm/amd/display: Skip fast cursor updates for fb changes

On 12/14/18 12:34 PM, Grodzovsky, Andrey wrote: > > > On 12/14/2018 12:26 PM, Nicholas Kazlauskas wrote: >> [Why] >> The behavior of drm_atomic_helper_cleanup_planes differs depending on >> whether the commit was asynchronous or not. When it's called from >> amdgpu_dm_atomic_commit_tail during a

Re: [PATCH] drm/amd/display: Skip fast cursor updates for fb changes

On 12/14/18 12:47 PM, Grodzovsky, Andrey wrote: > > > On 12/14/2018 12:41 PM, Kazlauskas, Nicholas wrote: >> On 12/14/18 12:34 PM, Grodzovsky, Andrey wrote: >>> >>> On 12/14/2018 12:26 PM, Nicholas Kazlauskas wrote: >>>> [Why] >>>>

Re: [PATCH] drm/amd/display: Add fast path for cursor plane updates

On 12/5/18 4:01 PM, Kazlauskas, Nicholas wrote: > On 2018-12-05 3:44 p.m., Grodzovsky, Andrey wrote: >> >> >> On 12/05/2018 03:42 PM, Kazlauskas, Nicholas wrote: >>> On 2018-12-05 3:26 p.m., Grodzovsky, Andrey wrote: >>>> >>>> On 12/0

Re: [PATCH 1/2] drm/amd/display: Use private obj helpers for dm_atomic_state

On 11/27/18 4:20 PM, Li, Sun peng (Leo) wrote: > > > On 2018-11-22 12:34 p.m., Nicholas Kazlauskas wrote: >> [Why] >> Two non-blocking commits in succession can result in a sequence where >> the same dc->current_state is queried for both commits. >> >> 1. 1st commit -> check -> commit -> swaps

Re: [PATCH 2/2] drm/amd/display: Remove wait for hw/flip done in atomic check

On 11/22/18 2:39 PM, Grodzovsky, Andrey wrote: > > > On 11/22/2018 12:34 PM, Nicholas Kazlauskas wrote: >> [Why] >> Atomic check can't truly be non-blocking if amdgpu_dm is waiting for >> hw_done and flip_done in atomic check. This introduces waits when >> any previous non-blocking commits

Re: [PATCH 2/2] drm/amd/display: Move iteration out of dm_update_crtcs

On 1/7/19 10:53 AM, sunpeng...@amd.com wrote: > From: Leo Li > > [Why] > To reduce indent in dm_update_crtcs, and to make it operate on single > instances. > > [How] > Move iteration of plane states into atomic_check. > No functional change is intended. > > Signed-off-by: Leo Li Series is:

Re: [PATCH xf86-video-amdgpu 0/6] xf86-video-amdgpu integration for DRM variable refresh rate API

On 09/12/2018 12:22 PM, Michel Dänzer wrote: On 2018-09-12 2:48 p.m., Kazlauskas, Nicholas wrote: On 09/12/2018 04:13 AM, Michel Dänzer wrote: On 2018-09-11 6:18 p.m., Nicholas Kazlauskas wrote: These patches are part of a proposed new interface for supporting variable refresh rate via DRM

Re: [PATCH 1/9] drm: Add variable refresh rate properties to DRM connector

On 09/11/2018 12:31 PM, Ville Syrjälä wrote: On Tue, Sep 11, 2018 at 07:22:43PM +0300, Ville Syrjälä wrote: On Tue, Sep 11, 2018 at 12:13:25PM -0400, Nicholas Kazlauskas wrote: Modern monitor hardware is capable of supporting variable refresh rates and adaptive sync technologies. The

Re: [PATCH xf86-video-amdgpu 0/6] xf86-video-amdgpu integration for DRM variable refresh rate API

On 09/12/2018 04:13 AM, Michel Dänzer wrote: Hi Nicholas, thanks for the patches. On 2018-09-11 6:18 p.m., Nicholas Kazlauskas wrote: These patches are part of a proposed new interface for supporting variable refresh rate via DRM properties.

Re: [PATCH 1/9] drm: Add variable refresh rate properties to DRM connector

On 09/11/2018 01:56 PM, Ville Syrjälä wrote: On Tue, Sep 11, 2018 at 01:36:01PM -0400, Kazlauskas, Nicholas wrote: On 09/11/2018 12:31 PM, Ville Syrjälä wrote: On Tue, Sep 11, 2018 at 07:22:43PM +0300, Ville Syrjälä wrote: On Tue, Sep 11, 2018 at 12:13:25PM -0400, Nicholas Kazlauskas wrote

Re: [PATCH 6/9] drm/amdgpu: add freesync ioctl

On 09/11/2018 01:51 PM, Christian König wrote: Am 11.09.2018 um 18:13 schrieb Nicholas Kazlauskas: From: Harry Wentland Add the ioctl to enable/disable freesync. Why do we still need this now that we have the DRM CRTC properties? These patches were already merged into amd-staging-drm-next

Re: [PATCH 5/5] drm/amd/display: Move the dm update dance to crtc->atomic_check

On 12/18/18 3:12 PM, Grodzovsky, Andrey wrote: > > > On 12/18/2018 10:26 AM, sunpeng...@amd.com wrote: >> From: Leo Li >> >> drm_atomic_helper_check_planes() calls the crtc atomic check helpers. In >> an attempt to better align with the DRM framework, we can move the >> entire dm_update dance

Re: [PATCH 05/20] drm/amd/display: Call into DC once per multiplane flip

On 1/28/19 6:59 AM, Michel Dänzer wrote: > On 2019-01-22 7:28 p.m., sunpeng...@amd.com wrote: >> From: David Francis >> >> [Why] >> amdgpu_dm_commit_planes was performing multi-plane >> flips incorrectly: >> >> It waited for vblank once per flipped plane >> >> It prepared flip ISR and acquired

Re: [PATCH 2/5] drm/amd/display: Prevent vblank irq disable while VRR is active. (v3)

On 3/29/19 8:00 AM, Mario Kleiner wrote: > During VRR mode we can not allow vblank irq dis-/enable > transitions, as an enable after a disable can happen at > an arbitrary time during the video refresh cycle, e.g., > with a high likelyhood inside vblank front-porch. An > enable during front-porch

Re: [PATCH] drm/amd/display: wait for fence without holding reservation lock

On 4/2/19 10:41 AM, Kazlauskas, Nicholas wrote: > On 4/2/19 10:28 AM, Christian König wrote: >> Don't block others while waiting for the fences to finish, concurrent >> submission is perfectly valid in this case and holding the lock can >> prevent killed applications from term

Re: [PATCH] drm/amd/display: wait for fence without holding reservation lock

On 4/2/19 10:28 AM, Christian König wrote: > Don't block others while waiting for the fences to finish, concurrent > submission is perfectly valid in this case and holding the lock can > prevent killed applications from terminating. > > Signed-off-by: Christian König Reviewed-by: Nicholas

Re: [PATCH 3/4] drm/amd/display: In VRR mode, do DRM core vblank handling at end of vblank. (v2)

On 3/22/19 4:04 PM, Mario Kleiner wrote: > In VRR mode, proper vblank/pageflip timestamps can only be computed > after the display scanout position has left front-porch. Therefore > delay calls to drm_crtc_handle_vblank(), and thereby calls to > drm_update_vblank_count() and pageflip event

Re: [PATCH] drm/amdgpu/display: fix build when DCN KCONFIG is not set

On 3/20/19 5:22 PM, Alex Deucher wrote: > Leads to an undefined symbol otherwise. > > Signed-off-by: Alex Deucher Reviewed-by: Nicholas Kazlauskas > --- > drivers/gpu/drm/amd/display/dc/core/dc_stream.c | 4 > 1 file changed, 4 insertions(+) > > diff --git

Re: [PATCH] drm/amd/display: fix cursor black issue

On 4/2/19 10:26 PM, tiancyin wrote: > [Why] > the member sdr_white_level of struct dc_cursor_attributes was not > initialized, then the random value result that > dcn10_set_cursor_sdr_white_level() set error hw_scale value 0x20D9(normal > value is 0x3c00), this cause the black cursor issue. > >

Re: [PATCH 1/5] drm/amd/display: Update VRR state earlier in atomic_commit_tail.

On 3/29/19 8:00 AM, Mario Kleiner wrote: > We need the VRR active/inactive state info earlier in > the commit sequence, so VRR related setup functions like > amdgpu_dm_handle_vrr_transition() know the final VRR state > when they need to do their hw setup work. > > Split

Re: [PATCH 06/18] drm/amd/display: Drop underlay plane support

On 3/5/19 12:09 PM, Michel Dänzer wrote: > On 2019-02-25 11:46 p.m., Bhawanpreet Lakha wrote: >> From: Nicholas Kazlauskas >> >> [Why] >> Primary and underlay planes were previously exposed to DRM by using >> max_planes and max_slave_planes. >> >> The value for max_planes was always pipe_count +

Re: [PATCH 2/4] drm/amd/display: Rework vrr flip throttling for late vblank irq.

On 3/18/19 1:19 PM, Mario Kleiner wrote: > For throttling to work correctly, we always need a baseline vblank > count last_flip_vblank that increments at start of front-porch. > > This is the case for drm_crtc_vblank_count() in non-VRR mode, where > the vblank irq fires at start of front-porch

Re: [PATCH 1/4] drm/amd/display: Prevent vblank irq disable while VRR is active.

On 3/18/19 1:19 PM, Mario Kleiner wrote: > During VRR mode we can not allow vblank irq dis-/enable > transitions, as an enable after a disable can happen at > an arbitrary time during the video refresh cycle, e.g., > with a high likelyhood inside vblank front-porch. An > enable during front-porch

Re: [PATCH 1/4] drm/amd/display: Prevent vblank irq disable while VRR is active. (v2)

On 3/20/19 4:12 AM, Mario Kleiner wrote: > During VRR mode we can not allow vblank irq dis-/enable > transitions, as an enable after a disable can happen at > an arbitrary time during the video refresh cycle, e.g., > with a high likelyhood inside vblank front-porch. An > enable during front-porch

Re: [PATCH 3/4] drm/amd/display: In VRR mode, do DRM core vblank handling at end of vblank.

On 3/20/19 3:51 AM, Mario Kleiner wrote: > Ok, fixed all the style issues and ran checkpatch over the patches. Thanks. > > On Tue, Mar 19, 2019 at 2:32 PM Kazlauskas, Nicholas > wrote: >> >> On 3/19/19 9:23 AM, Kazlauskas, Nicholas wrote: >>> On 3/18/19 1:19 PM,

Re: [PATCH 4/4] drm/amd/display: Make pageflip event delivery compatible with VRR.

On 3/18/19 1:19 PM, Mario Kleiner wrote: > We want vblank counts and timestamps of flip completion as sent > in pageflip completion events to be consistent with the vblank > count and timestamp of the vblank of flip completion, like in non > VRR mode. > > In VRR mode, drm_update_vblank_count() -

Re: [PATCH 3/4] drm/amd/display: In VRR mode, do DRM core vblank handling at end of vblank.

On 3/18/19 1:19 PM, Mario Kleiner wrote: > In VRR mode, proper vblank/pageflip timestamps can only be computed > after the display scanout position has left front-porch. Therefore > delay calls to drm_crtc_handle_vblank(), and thereby calls to > drm_update_vblank_count() and pageflip event

Re: [PATCH 3/4] drm/amd/display: In VRR mode, do DRM core vblank handling at end of vblank.

On 3/19/19 9:23 AM, Kazlauskas, Nicholas wrote: > On 3/18/19 1:19 PM, Mario Kleiner wrote: >> In VRR mode, proper vblank/pageflip timestamps can only be computed >> after the display scanout position has left front-porch. Therefore >> delay calls to drm_crtc_handle_vblank

Re: [PATCH] drm/amdgpu: Clear VRAM for DRM dumb_create buffers

On 3/11/19 12:58 PM, Christian König wrote: > Am 08.03.19 um 17:47 schrieb Alex Deucher: >> On Fri, Mar 8, 2019 at 10:38 AM Nicholas Kazlauskas >> wrote: >>> The dumb_create API isn't intended for high performance rendering >>> and it's more useful for userspace (ie. IGT) to have them precleared.

Re: [PATCH v2 5/5] drm: don't block fb changes for async plane updates

On 3/12/19 2:44 AM, Boris Brezillon wrote: > On Mon, 11 Mar 2019 23:22:03 -0300 > Helen Koike wrote: > >> In the case of a normal sync update, the preparation of framebuffers (be >> it calling drm_atomic_helper_prepare_planes() or doing setups with >> drm_framebuffer_get()) are performed in the

Re: [PATCH] drm/amdgpu: Clear VRAM for DRM dumb_create buffers

On 3/11/19 1:31 PM, Koenig, Christian wrote: > Am 11.03.19 um 18:04 schrieb Kazlauskas, Nicholas: >> On 3/11/19 12:58 PM, Christian König wrote: >>> Am 08.03.19 um 17:47 schrieb Alex Deucher: >>>> On Fri, Mar 8, 2019 at 10:38 AM Nicholas Kazlauskas >>>&g

Re: [PATCH] drm/amd/display: Fix "dc has no member named dml" compile error

On 3/21/19 10:44 AM, sunpeng...@amd.com wrote: > From: Leo Li > > For DCN disabled builds, dc->dml is stripped out. Therefore, guard usage > in dc_create_state() with CONFIG_DRM_AMD_DC_DCN1_0. > > It fixes the following error: > > drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c: In function

Re: [PATCH 3/4] drm/amd/display: In VRR mode, do DRM core vblank handling at end of vblank.

On 3/21/19 11:38 AM, Wentland, Harry wrote: > > > On 2019-03-21 5:39 a.m., Mario Kleiner wrote: >> On Wed, Mar 20, 2019 at 1:53 PM Kazlauskas, Nicholas >> wrote: >>> >>> On 3/20/19 3:51 AM, Mario Kleiner wrote: >>>> Ok, fixed all the style

Re: [PATCH] drm/amd/display: Initialize stream_update with memset

On 3/22/19 9:49 AM, Paul Menzel wrote: > Dear Nicholas, > > > On 03/22/19 14:15, Nicholas Kazlauskas wrote: >> The brace initialization used here generates errors on some >> compilers. Use memset to make this more portable. > > Could you please specify the problematic compiler/toolchain in >

Re: [PATCH 2/3] drm: Add basic helper to allow precise pageflip timestamps in vrr.

On 2/13/19 4:50 AM, Daniel Vetter wrote: > On Tue, Feb 12, 2019 at 10:32:31PM +0100, Mario Kleiner wrote: >> On Mon, Feb 11, 2019 at 6:04 PM Daniel Vetter wrote: >>> >>> On Mon, Feb 11, 2019 at 4:01 PM Kazlauskas, Nicholas >>> wrote: >>>&

Re: [PATCH] drm/amd/display: Fix deadlock with display during hanged ring recovery.

On 2/13/19 2:21 PM, Grodzovsky, Andrey wrote: > > On 2/13/19 2:16 PM, Kazlauskas, Nicholas wrote: >> On 2/13/19 2:10 PM, Grodzovsky, Andrey wrote: >>> On 2/13/19 2:00 PM, Kazlauskas, Nicholas wrote: >>>> On 2/13/19 1:58 PM, Andrey Grodzovsky wr

Re: [PATCH 2/3] drm: Add basic helper to allow precise pageflip timestamps in vrr.

On 2/13/19 1:10 PM, Mario Kleiner wrote: > On Wed, Feb 13, 2019 at 5:03 PM Daniel Vetter wrote: >> >> On Wed, Feb 13, 2019 at 4:46 PM Kazlauskas, Nicholas >> wrote: >>> >>> On 2/13/19 10:14 AM, Daniel Vetter wrote: >>>> On Wed, Feb 1

Re: [PATCH] drm/amd/display: Fix deadlock with display during hanged ring recovery.

On 2/13/19 1:58 PM, Andrey Grodzovsky wrote: > When ring hang happens amdgpu_dm_commit_planes during flip is holding > the BO reserved and then stack waiting for fences to signal in > reservation_object_wait_timeout_rcu (which won't signal because there > was a hnag). Then when we try to shutdown

Re: [PATCH] drm/amd/display: Fix deadlock with display during hanged ring recovery.

On 2/13/19 2:10 PM, Grodzovsky, Andrey wrote: > > On 2/13/19 2:00 PM, Kazlauskas, Nicholas wrote: >> On 2/13/19 1:58 PM, Andrey Grodzovsky wrote: >>> When ring hang happens amdgpu_dm_commit_planes during flip is holding >>> the BO reserved and then stac

Re: [PATCH] drm/amd/display: Fix deadlock with display during hanged ring recovery.

On 2/14/19 10:42 AM, Grodzovsky, Andrey wrote: > > On 2/14/19 4:05 AM, Christian König wrote: >> Am 13.02.19 um 19:58 schrieb Andrey Grodzovsky: >>> When ring hang happens amdgpu_dm_commit_planes during flip is holding >>> the BO reserved and then stack waiting for fences to signal in >>>

Re: [PATCH] drm/amd/display: Fix deadlock with display during hanged ring recovery.

On 2/14/19 12:47 PM, Grodzovsky, Andrey wrote: > > On 2/14/19 11:57 AM, Kazlauskas, Nicholas wrote: >> On 2/14/19 11:47 AM, Grodzovsky, Andrey wrote: >>> On 2/14/19 11:07 AM, Michel Dänzer wrote: >>>> On 2019-02-14 4:54 p.m., Kazlauskas, Nicholas wrote: >

Re: [PATCH] drm/amd/display: Fix deadlock with display during hanged ring recovery.

On 2/14/19 11:47 AM, Grodzovsky, Andrey wrote: > > On 2/14/19 11:07 AM, Michel Dänzer wrote: >> On 2019-02-14 4:54 p.m., Kazlauskas, Nicholas wrote: >>> On 2/14/19 10:42 AM, Grodzovsky, Andrey wrote: >>>> On 2/14/19 4:05 AM, Christian König wrote: >>

Re: [PATCH 2/3] drm: Add basic helper to allow precise pageflip timestamps in vrr.

On 2/13/19 10:14 AM, Daniel Vetter wrote: > On Wed, Feb 13, 2019 at 3:33 PM Kazlauskas, Nicholas > wrote: >> >> On 2/13/19 4:50 AM, Daniel Vetter wrote: >>> On Tue, Feb 12, 2019 at 10:32:31PM +0100, Mario Kleiner wrote: >>>> On Mon, Feb 11, 2019 at 6:04 PM D

Re: [PATCH] drm/amd/display: Use vrr friendly pageflip throttling in DC.

On 2/11/19 10:01 AM, Michel Dänzer wrote: > On 2019-02-09 7:52 a.m., Mario Kleiner wrote: >> In VRR mode, keep track of the vblank count of the last >> completed pageflip in amdgpu_crtc->last_flip_vblank, as >> recorded in the pageflip completion handler after each >> completed flip. >> >> Use

Re: [PATCH] drm/amd/display: Use vrr friendly pageflip throttling in DC.

On 2/9/19 1:52 AM, Mario Kleiner wrote: > In VRR mode, keep track of the vblank count of the last > completed pageflip in amdgpu_crtc->last_flip_vblank, as > recorded in the pageflip completion handler after each > completed flip. > > Use that count to prevent mmio programming a new pageflip >

Re: [PATCH 2/3] drm: Add basic helper to allow precise pageflip timestamps in vrr.

On 2/11/19 3:35 AM, Daniel Vetter wrote: > On Mon, Feb 11, 2019 at 04:22:24AM +0100, Mario Kleiner wrote: >> The pageflip completion timestamps transmitted to userspace >> via pageflip completion events are supposed to describe the >> time at which the first pixel of the new post-pageflip scanout

Re: [PATCH v7 2/5] drm: Add vrr_enabled property to drm CRTC

On 1/30/19 6:02 AM, Daniel Vetter wrote: > On Wed, Jan 30, 2019 at 11:42 AM Daniel Vetter wrote: >> >> On Thu, Nov 8, 2018 at 3:44 PM Nicholas Kazlauskas >> wrote: >>> >>> This patch introduces the 'vrr_enabled' CRTC property to allow >>> dynamic control over variable refresh rate support for a

Re: [PATCH] drm/amd/display: Expose connector VRR range via debugfs

On 1/25/19 3:13 AM, Koenig, Christian wrote: > Am 24.01.19 um 18:56 schrieb Wentland, Harry: >> >> On 2019-01-24 12:41 p.m., Christian König wrote: >>> Am 24.01.19 um 18:06 schrieb Nicholas Kazlauskas: [Why] It's useful to know the min and max vrr range for IGT testing. [How]

Re: [PATCH] SWDEV-183622 4k@60hz dp monitor always flicking

On 4/15/19 10:00 AM, Deucher, Alexander wrote: > Maybe mention that this fixes issues with stutter mode and 4k.  With that, > Acked-by: Alex Deucher > > *From:* amd-gfx on behalf of > hersen wu > *Sent:* Monday, April 15,

Re: [PATCH] drm/amd/display: Expose support for DRM_FORMAT_RGB565

On 4/15/19 11:11 AM, Michel Dänzer wrote: > On 2019-04-15 4:27 p.m., Nicholas Kazlauskas wrote: >> DC and DM already support DRM_FORMAT_RGB565, it's just missing from the >> list of valid formats. >> >> Cc: Harry Wentland >> Cc: Leo Li >> Signed-off-by: Nicholas Kazlauskas >> --- >>

Re: [PATCH v3 5/5] Patch '5edb0c9b Fix deadlock with display during hanged ring recovery' was accidentaly removed during one of DALs code merges.

On 4/15/19 3:43 PM, Andrey Grodzovsky wrote: > Signed-off-by: Andrey Grodzovsky > Reviewed-by: Nicholas Kazlauskas Nitpicks: Put the current commit message (with the spelling mistake in accidentally fixed) in the body of the commit and give the commit title something a little more

Re: [PATCH] drm/amd/display: Expose support for DRM_FORMAT_RGB565

On 4/16/19 9:28 AM, Wentland, Harry wrote: > On 2019-04-15 10:27 a.m., Nicholas Kazlauskas wrote: >> DC and DM already support DRM_FORMAT_RGB565, it's just missing from the >> list of valid formats. >> >> Cc: Harry Wentland >> Cc: Leo Li >> Signed-off-by: Nicholas Kazlauskas > > Reviewed-by:

Re: [PATCH 4/4] drm/amd/display: Restore deleted patch to resolve reset deadlock.

On 4/11/19 12:03 PM, Andrey Grodzovsky wrote: > Patch '5edb0c9b Fix deadlock with display during hanged ring recovery' > was accidentaly removed during one of DALs code merges. > > Signed-off-by: Andrey Grodzovsky Reviewed-by: Nicholas Kazlauskas Probably got lost in a refactor. Also, didn't

Re: [PATCH] drm/amd/display: Add debugfs entry for amdgpu_dm_visual_confirm

On 3/15/19 8:47 AM, Christian König wrote: > Am 15.03.19 um 13:42 schrieb Nicholas Kazlauskas: >> [Why] >> DC provides a few visual confirmation debug options that can be >> dynamically changed at runtime to help debug surface programming issues >> but we don't have any way to access it from

Re: [PATCH] drm/amdgpu/display: Drop some new CONFIG_DRM_AMD_DC_DCN1_01 guards

On 5/31/19 12:37 PM, Alex Deucher wrote: > These got added back by subsequent merges accidently. > > Signed-off-by: Alex Deucher Reviewed-by: Nicholas Kazlauskas > --- > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 -- > drivers/gpu/drm/amd/display/dc/clk_mgr/clk_mgr.c | 4 >

Re: [PATCH 10/24] drm/amd/display: Rework CRTC color management

On 6/7/19 3:58 AM, Michel Dänzer wrote: > On 2019-06-06 10:54 p.m., Bhawanpreet Lakha wrote: >> From: Nicholas Kazlauskas >> >> [Why] >> To prepare for the upcoming DRM plane color management properties >> we need to correct a lot of wrong behavior and assumptions made for >> CRTC color

Re: [PATCH] drm/amd/display: Use current connector state if NULL when checking bpc

- > *From:* amd-gfx on behalf of > Nicholas Kazlauskas > *Sent:* Wednesday, June 5, 2019 12:33 PM > *To:* amd-gfx@lists.freedesktop.org > *Cc:* Li, Sun peng (Leo); Wentland, Harry; Kazlauskas, Nicholas > *Subject:* [PATCH] drm/amd/display: Use current connector state if NULL

Re: [PATCH 10/24] drm/amd/display: Rework CRTC color management

On 6/7/19 11:51 AM, Michel Dänzer wrote: > On 2019-06-07 2:26 p.m., Kazlauskas, Nicholas wrote: >> On 6/7/19 3:58 AM, Michel Dänzer wrote: >>> On 2019-06-06 10:54 p.m., Bhawanpreet Lakha wrote: >>>> From: Nicholas Kazlauskas >>>> >>>>

Re: [PATCH v2] drm/amdgpu/display: Fix reload driver error

On 5/28/19 11:12 PM, Emily Deng wrote: > Issue: > Will have follow error when reload driver: > [ 3986.567739] sysfs: cannot create duplicate filename > '/devices/pci:00/:00:07.0/drm_dp_aux_dev' > [ 3986.567743] CPU: 6 PID: 1767 Comm: modprobe Tainted: G OE >

Re: [PATCH] drm/amdgpu/display: Fix reload driver error

On 5/28/19 6:28 AM, Emily Deng wrote: > Issue: > Will have follow error when reload driver: > [ 3986.567739] sysfs: cannot create duplicate filename > '/devices/pci:00/:00:07.0/drm_dp_aux_dev' > [ 3986.567743] CPU: 6 PID: 1767 Comm: modprobe Tainted: G OE > 5.0.0-rc1-custom

Re: [PATCH 1/2] drm/amdgpu/powerplay: FEATURE_MASK is 64 bit so use ULL

On 6/25/19 9:58 AM, Alex Deucher wrote: > ULL is needed for 32 bit arches. > > Signed-off-by: Alex Deucher Reviewed-by: Nicholas Kazlauskas > --- > drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 2 +- > drivers/gpu/drm/amd/powerplay/vega20_ppt.c | 2 +- > 2 files changed, 2 insertions(+), 2

Re: [PATCH 2/2] drm/amdgpu/display: switch udelay to msleep

On 6/25/19 9:58 AM, Alex Deucher wrote: > We may need to sleep for up to 80ms: > > /* First DPCD read after VDD ON can fail if the particular board > * does not have HPD pin wired correctly. So if DPCD read fails, > * which it should never happen, retry a few times. Target worst > * case

  1   2   3   4   >