All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aurabindo Pillai <aurabindo.pillai@amd.com>
To: Shashank Sharma <shashank.sharma@amd.com>, amd-gfx@lists.freedesktop.org
Cc: stylon.wang@amd.com, thong.thai@amd.com, wayne.lin@amd.com,
	alexander.deucher@amd.com, Harry.Wentland@amd.com,
	nicholas.kazlauskas@amd.com
Subject: Re: [PATCH 3/3] drm/amd/display: Skip modeset for front porch change
Date: Thu, 10 Dec 2020 12:50:04 -0500	[thread overview]
Message-ID: <f102763220b62e64e377e84a2e8d354bb8d89173.camel@amd.com> (raw)
In-Reply-To: <9cc10157-d533-95fd-0f20-8bbc2db75a79@amd.com>


[-- Attachment #1.1: Type: text/plain, Size: 5527 bytes --]

On Thu, 2020-12-10 at 18:29 +0530, Shashank Sharma wrote:
> On 10/12/20 8:15 am, Aurabindo Pillai wrote:
> > [Why&How]
> > Inorder to enable freesync video mode, driver adds extra
> > modes based on preferred modes for common freesync frame rates.
> > When commiting these mode changes, a full modeset is not needed.
> > If the change in only in the front porch timing value, skip full
> > modeset and continue using the same stream.
> > 
> > Signed-off-by: Aurabindo Pillai <
> > aurabindo.pillai@amd.com
> > >
> > ---
> >  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 169
> > ++++++++++++++++--
> >  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |   1 +
> >  2 files changed, 153 insertions(+), 17 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index f699a3d41cad..c8c72887906a 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -217,6 +217,9 @@ static bool amdgpu_dm_psr_disable_all(struct
> > amdgpu_display_manager *dm);
> >  static const struct drm_format_info *
> >  amd_get_format_info(const struct drm_mode_fb_cmd2 *cmd);
> >  
> > +static bool
> > +is_timing_unchanged_for_freesync(struct drm_crtc_state
> > *old_crtc_state,
> > +				 struct drm_crtc_state
> > *new_crtc_state);
> >  /*
> >   * dm_vblank_get_counter
> >   *
> > @@ -5096,8 +5099,11 @@ copy_crtc_timing_for_drm_display_mode(const
> > struct drm_display_mode *src_mode,
> >  static void
> >  decide_crtc_timing_for_drm_display_mode(struct drm_display_mode
> > *drm_mode,
> >  					const struct drm_display_mode
> > *native_mode,
> > -					bool scale_enabled)
> > +					bool scale_enabled, bool
> > fs_mode)
> >  {
> > +	if (fs_mode)
> > +		return;
> 
> so we are adding an input flag just so that we can return from the
> function at top ? How about adding this check at the caller without
> changing the function parameters ?

Will fix this.

> > +
> >  	if (scale_enabled) {
> >  		copy_crtc_timing_for_drm_display_mode(native_mode,
> > drm_mode);
> >  	} else if (native_mode->clock == drm_mode->clock &&
> > @@ -5241,6 +5247,24 @@ get_highest_freesync_mode(struct
> > amdgpu_dm_connector *aconnector,
> >  	return m_high;
> >  }
> >  
> > +static bool is_freesync_video_mode(struct drm_display_mode *mode,
> > +				   struct amdgpu_dm_connector
> > *aconnector)
> > +{
> > +	struct drm_display_mode *high_mode;
> > +
> 
> I thought we were adding a string "_FSV" in the end for the mode-
> >name, why can't we check that instead of going through the whole
> list of modes again ?

Actually I only added _FSV to distinguish the newly added modes easily.
On second thoughts, I'm not sure if there are any userspace
applications that might depend on parsing the mode name, for maybe to
print the resolution. I think its better not to break any such
assumptions if they do exist by any chance. I think I'll just remove
_FSV from the mode name. We already set DRM_MODE_TYPE_DRIVER for
userspace to recognize these additional modes, so it shouldnt be a
problem.

> > +	high_mode = get_highest_freesync_mode(aconnector, false);
> > +	if (!high_mode)
> > +		return false;
> > +
> > +	if (high_mode->clock == 0 ||
> > +	    high_mode->hdisplay != mode->hdisplay ||
> > +	    high_mode->clock != mode->clock ||
> > +	    !mode)
> > +		return false;
> > +	else
> > +		return true;
> > +}
> > +
> >  static struct dc_stream_state *
> >  create_stream_for_sink(struct amdgpu_dm_connector *aconnector,
> >  		       const struct drm_display_mode *drm_mode,
> > @@ -5253,17 +5277,21 @@ create_stream_for_sink(struct
> > amdgpu_dm_connector *aconnector,
> >  	const struct drm_connector_state *con_state =
> >  		dm_state ? &dm_state->base : NULL;
> >  	struct dc_stream_state *stream = NULL;
> > -	struct drm_display_mode mode = *drm_mode;
> > +	struct drm_display_mode saved_mode, mode = *drm_mode;
> 
> How about shifting this definition to new line to follow the existing
> convention ?

Sure.

> > +	struct drm_display_mode *freesync_mode = NULL;
> >  	bool native_mode_found = false;
> >  	bool scale = dm_state ? (dm_state->scaling != RMX_OFF) : false;
> >  	int mode_refresh;
> >  	int preferred_refresh = 0;
> > +	bool is_fs_vid_mode = 0;
> >  #if defined(CONFIG_DRM_AMD_DC_DCN)
> >  	struct dsc_dec_dpcd_caps dsc_caps;
> >  #endif
> >  	uint32_t link_bandwidth_kbps;
> > -
> >  	struct dc_sink *sink = NULL;
> > +
> > +	memset(&saved_mode, 0, sizeof(struct drm_display_mode));
> > +
> >  	if (aconnector == NULL) {
> >  		DRM_ERROR("aconnector is NULL!\n");
> >  		return stream;
> > @@ -5316,20 +5344,33 @@ create_stream_for_sink(struct
> > amdgpu_dm_connector *aconnector,
> >  		 */
> >  		DRM_DEBUG_DRIVER("No preferred mode found\n");
> >  	} else {
> > +		is_fs_vid_mode = is_freesync_video_mode(&mode,
> > aconnector);
> > +		if (is_fs_vid_mode) {
> > +			freesync_mode =
> > get_highest_freesync_mode(aconnector, false);
> > +			if (freesync_mode) {
> 
> As the freesync modes are being added by the driver, and we have
> passed one check which says is_fs_vid_mode, will it ever be the case
> where freesync_mode == NULL ? Ideally we should get atleast one mode
> equal to this isn't it ? in that case we can drop one if () check.

Yes, thanks for catching this. Will fix.


--

Regards,
Aurabindo Pillai

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

  reply	other threads:[~2020-12-10 17:50 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-10  2:45 [PATCH 0/3] Experimental freesync video mode optimization Aurabindo Pillai
2020-12-10  2:45 ` [PATCH 1/3] drm/amd/display: Add module parameter for freesync video mode Aurabindo Pillai
2021-01-04 15:58   ` Kazlauskas, Nicholas
2020-12-10  2:45 ` [PATCH 2/3] drm/amd/display: Add freesync video modes based on preferred modes Aurabindo Pillai
2020-12-10 12:37   ` Shashank Sharma
2020-12-10 16:56     ` Aurabindo Pillai
2020-12-10  2:45 ` [PATCH 3/3] drm/amd/display: Skip modeset for front porch change Aurabindo Pillai
2020-12-10 10:21   ` Christian König
2020-12-10 12:59   ` Shashank Sharma
2020-12-10 17:50     ` Aurabindo Pillai [this message]
2020-12-11  5:08       ` Shashank Sharma
2020-12-11 14:49         ` Kazlauskas, Nicholas
2020-12-11 15:35           ` Shashank Sharma
2020-12-11 16:20             ` Kazlauskas, Nicholas
2020-12-11 18:31               ` Shashank Sharma
2021-01-04 16:16   ` Kazlauskas, Nicholas
2021-01-04 20:43     ` Aurabindo Pillai
2021-01-19 15:50 [PATCH 0/3] Experimental freesync video mode optimization Aurabindo Pillai
2021-01-19 15:50 ` [PATCH 3/3] drm/amd/display: Skip modeset for front porch change Aurabindo Pillai
2021-01-19 15:50   ` Aurabindo Pillai
2021-01-21 19:05   ` Kazlauskas, Nicholas
2021-01-21 19:05     ` Kazlauskas, Nicholas
2021-01-25  4:00     ` Aurabindo Pillai
2021-01-25  4:00       ` Aurabindo Pillai
2021-02-08 15:06       ` Kazlauskas, Nicholas
2021-02-08 15:06         ` Kazlauskas, Nicholas
2021-02-12 20:01         ` Aurabindo Pillai
2021-02-12 20:01           ` Aurabindo Pillai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f102763220b62e64e377e84a2e8d354bb8d89173.camel@amd.com \
    --to=aurabindo.pillai@amd.com \
    --cc=Harry.Wentland@amd.com \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=nicholas.kazlauskas@amd.com \
    --cc=shashank.sharma@amd.com \
    --cc=stylon.wang@amd.com \
    --cc=thong.thai@amd.com \
    --cc=wayne.lin@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.