Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Manasi Navare <manasi.d.navare@intel.com>
To: Jani Nikula <jani.nikula@intel.com>
Cc: intel-gfx@lists.freedesktop.org, rodrigo.vivi@intel.com
Subject: Re: [PATCH 6/7] drm/i915/dp: abstract link config selection
Date: Wed, 25 Apr 2018 18:43:40 -0700	[thread overview]
Message-ID: <20180426014340.GJ31618@intel.com> (raw)
In-Reply-To: <877epgjwp8.fsf@intel.com>

On Mon, Apr 09, 2018 at 05:12:03PM +0300, Jani Nikula wrote:
> On Thu, 05 Apr 2018, Manasi Navare <manasi.d.navare@intel.com> wrote:
> > On Thu, Apr 05, 2018 at 05:39:04PM +0300, Jani Nikula wrote:
> >> For now, there's just the one link config selection, optimizing for slow
> >> and wide link. No functional changes.
> >> 
> >> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> >> ---
> >>  drivers/gpu/drm/i915/intel_dp.c | 81 +++++++++++++++++++++++++----------------
> >>  1 file changed, 50 insertions(+), 31 deletions(-)
> >> 
> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> >> index 3c5fbdf42b9b..c98626b3af65 100644
> >> --- a/drivers/gpu/drm/i915/intel_dp.c
> >> +++ b/drivers/gpu/drm/i915/intel_dp.c
> >> @@ -1704,6 +1704,42 @@ static bool intel_edp_compare_alt_mode(struct drm_display_mode *m1,
> >>  	return bres;
> >>  }
> >>  
> >> +/* Optimize link config in order: max bpp, min clock, min lanes */
> >> +static bool
> >> +intel_dp_compute_link_config_wide(struct intel_dp *intel_dp,
> >> +				  struct intel_crtc_state *pipe_config,
> >> +				  const struct link_config_limits *limits)
> >> +{
> >> +	struct drm_display_mode *adjusted_mode = &pipe_config->base.adjusted_mode;
> >> +	int bpp, clock, lane_count;
> >> +	int mode_rate, link_clock, link_avail;
> >> +
> >> +	for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
> >> +		mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
> >> +						   bpp);
> >> +
> >> +		for (clock = limits->min_clock; clock <= limits->max_clock; clock++) {
> >> +			for (lane_count = limits->min_lane_count;
> >> +			     lane_count <= limits->max_lane_count;
> >> +			     lane_count <<= 1) {
> >> +				link_clock = intel_dp->common_rates[clock];
> >> +				link_avail = intel_dp_max_data_rate(link_clock,
> >> +								    lane_count);
> >> +
> >> +				if (mode_rate <= link_avail) {
> >> +					pipe_config->lane_count = lane_count;
> >> +					pipe_config->pipe_bpp = bpp;
> >> +					pipe_config->port_clock = link_clock;
> >> +
> >> +					return true;
> >> +				}
> >> +			}
> >> +		}
> >> +	}
> >> +
> >> +	return false;
> >> +}
> >> +
> >>  static bool
> >>  intel_dp_compute_link_config(struct intel_encoder *encoder,
> >>  			     struct intel_crtc_state *pipe_config)
> >> @@ -1711,8 +1747,6 @@ intel_dp_compute_link_config(struct intel_encoder *encoder,
> >>  	struct drm_display_mode *adjusted_mode = &pipe_config->base.adjusted_mode;
> >>  	struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
> >>  	struct link_config_limits limits;
> >> -	int bpp, clock, lane_count;
> >> -	int mode_rate, link_avail, link_clock;
> >>  	int common_len;
> >>  
> >>  	common_len = intel_dp_common_len_rate_limit(intel_dp,
> >> @@ -1766,37 +1800,22 @@ intel_dp_compute_link_config(struct intel_encoder *encoder,
> >>  		      intel_dp->common_rates[limits.max_clock],
> >>  		      limits.max_bpp, adjusted_mode->crtc_clock);
> >>  
> >> -	for (bpp = limits.max_bpp; bpp >= limits.min_bpp; bpp -= 2 * 3) {
> >> -		mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
> >> -						   bpp);
> >> -
> >> -		for (clock = limits.min_clock; clock <= limits.max_clock; clock++) {
> >> -			for (lane_count = limits.min_lane_count;
> >> -			     lane_count <= limits.max_lane_count;
> >> -			     lane_count <<= 1) {
> >> -
> >> -				link_clock = intel_dp->common_rates[clock];
> >> -				link_avail = intel_dp_max_data_rate(link_clock,
> >> -								    lane_count);
> >> -
> >> -				if (mode_rate <= link_avail) {
> >> -					goto found;
> >> -				}
> >> -			}
> >> -		}
> >> -	}
> >> -
> >> -	return false;
> >> -
> >> -found:
> >> -	pipe_config->lane_count = lane_count;
> >> -	pipe_config->pipe_bpp = bpp;
> >> -	pipe_config->port_clock = intel_dp->common_rates[clock];
> >> +	/*
> >> +	 * Optimize for slow and wide. This is the place to add alternative
> >> +	 * optimization policy.
> >> +	 */
> >> +	if (!intel_dp_compute_link_config_wide(intel_dp, pipe_config, &limits))
> >> +		return false;
> >>  
> >>  	DRM_DEBUG_KMS("DP lane count %d clock %d bpp %d\n",
> >> -		      pipe_config->lane_count, pipe_config->port_clock, bpp);
> >> -	DRM_DEBUG_KMS("DP link bw required %i available %i\n",
> >> -		      mode_rate, link_avail);
> >> +		      pipe_config->lane_count, pipe_config->port_clock,
> >> +		      pipe_config->pipe_bpp);
> >> +
> >> +	DRM_DEBUG_KMS("DP link rate required %i available %i\n",
> >> +		      intel_dp_link_required(adjusted_mode->crtc_clock,
> >> +					     pipe_config->pipe_bpp),
> >> +		      intel_dp_max_data_rate(pipe_config->port_clock,
> >> +					     pipe_config->lane_count));
> >
> > Wouldnt it be better if we move this Debug message about Available and
> > required link rate in the other function right after the condition
> > if (mode_rate <= link_avail) is true, before returning true from that function.
> > I think it will be just more intuitive there.
> 
> That's what I thought too at first, but then realized if we're going to
> add an alternative call to an alternative approach, and perhaps yet
> another for DSC, the debugging gets duplicated in all of them.
> 
> BR,
> Jani.

Yes that makes sense then to have the debug messages outside in the main compute_config function.
Thanks for the clarification. So with that:

Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>

Manasi

> 
> 
> >
> > Everything else looks good. So
> >
> > Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
> >
> > Manasi
> >
> >>  
> >>  	return true;
> >>  }
> >> -- 
> >> 2.11.0
> >> 
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2018-04-26  1:40 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-05 14:38 [PATCH 0/7] drm/i915/dp: link config compute refactoring Jani Nikula
2018-04-05 14:38 ` [PATCH 1/7] drm/i915/dp: remove stale comment about bw constants Jani Nikula
2018-04-05 17:10   ` Rodrigo Vivi
2018-04-05 18:46   ` Manasi Navare
2018-04-05 14:39 ` [PATCH 2/7] drm/i915/dp: move link_bw and rate_select debugging where used Jani Nikula
2018-04-05 17:22   ` Rodrigo Vivi
2018-04-05 19:03     ` Manasi Navare
2018-04-05 14:39 ` [PATCH 3/7] drm/i915/dp: abstract dp link config computation from the rest Jani Nikula
2018-04-25 19:03   ` Manasi Navare
2018-04-05 14:39 ` [PATCH 4/7] drm/i915/dp: move eDP VBT bpp claming code to intel_dp_compute_bpp() Jani Nikula
2018-04-05 19:44   ` Manasi Navare
2018-04-05 14:39 ` [PATCH 5/7] drm/i915/dp: group link config limits in a struct Jani Nikula
2018-04-25 19:07   ` Manasi Navare
2018-04-05 14:39 ` [PATCH 6/7] drm/i915/dp: abstract link config selection Jani Nikula
2018-04-05 19:55   ` Manasi Navare
2018-04-09 14:12     ` Jani Nikula
2018-04-09 18:22       ` Manasi Navare
2018-04-26  1:43       ` Manasi Navare [this message]
2018-04-05 14:39 ` [PATCH 7/7] drm/i915/dp: fix compliance test adjustments Jani Nikula
2018-04-05 19:59   ` Manasi Navare
2018-04-05 14:49 ` ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dp: link config compute refactoring Patchwork
2018-04-05 15:06 ` ✓ Fi.CI.BAT: success " Patchwork
2018-04-05 18:35 ` ✓ Fi.CI.IGT: " Patchwork

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=20180426014340.GJ31618@intel.com \
    --to=manasi.d.navare@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=rodrigo.vivi@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox