All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Pandiyan, Dhinakaran" <dhinakaran.pandiyan@intel.com>
Cc: "Nikula, Jani" <jani.nikula@intel.com>,
	"intel-gfx@freedesktop.org" <intel-gfx@freedesktop.org>,
	"libin.yang@linux.intel.com" <libin.yang@linux.intel.com>,
	"Kp, Jeeja" <jeeja.kp@intel.com>
Subject: Re: [PATCH] drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2
Date: Mon, 17 Oct 2016 11:33:06 +0300	[thread overview]
Message-ID: <20161017083306.GH4329@intel.com> (raw)
In-Reply-To: <1476478179.31308.50.camel@dk-H97M-D3H>

On Fri, Oct 14, 2016 at 08:33:37PM +0000, Pandiyan, Dhinakaran wrote:
> On Thu, 2016-10-13 at 21:44 +0300, Ville Syrjälä wrote:
> > On Thu, Oct 13, 2016 at 11:04:19AM -0700, Dhinakaran Pandiyan wrote:
> > > According to BSpec, cdclk has to be not less than 432 MHz with DP audio
> > > enabled, port width x4, and link rate HBR2 (5.4 GHz)
> > > 
> > > Having a lower cdclk triggers pipe underruns, which then lead to displays
> > > continuously cycling off and on. This is essential for DP MST audio as the
> > > link is trained at HBR2 and 4 lanes by default.
> > > 
> > > This should fix https://bugs.freedesktop.org/show_bug.cgi?id=97907
> > > 
> > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/intel_display.c | 47 +++++++++++++++++++++++++++++++++---
> > >  1 file changed, 43 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> > > index cfcb03f..6a05183 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -6603,14 +6603,43 @@ static int valleyview_modeset_calc_cdclk(struct drm_atomic_state *state)
> > >  	return 0;
> > >  }
> > >  
> > > +static bool cdclk_min_for_dp_audio(struct drm_atomic_state *state)
> > > +{
> > > +
> > > +	struct drm_crtc_state *crtc_state;
> > > +	struct drm_crtc *crtc;
> > > +	int i;
> > > +
> > > +	/* BSpec says "Do not use DisplayPort with CDCLK less than 432 MHz,
> > > +	 * audio enabled, port width x4, and link rate HBR2 (5.4 GHz), or else
> > > +	 * there may be audio corruption or screen corruption."
> > > +	 */
> > > +
> > > +	for_each_crtc_in_state(state, crtc, crtc_state, i) {
> > > +		struct intel_crtc_state *pipe_config =
> > > +			to_intel_crtc_state(crtc_state);
> > > +
> > > +		return (intel_crtc_has_dp_encoder(pipe_config) &&
> > > +			pipe_config->has_audio &&
> > > +			pipe_config->port_clock == 540000 &&
> > > +			pipe_config->lane_count == 4);
> > > +	}
> > 
> > That's not good enough on account of crtcs not part of the state
> > potentially needing the workaround as well. However, since we only do
> > this when there's a modeset, I think we'll be covered by the
> > connection_mutex, and so we should be able to peek at the current state
> > of all crtcs without grabbing the corresponding crtc locks.
> > 
> 
> Please correct me if I am wrong. Won't the first modeset that has all
> the conditions met (DP + HBR2 + 4 lanes + audio) include the crtc
> driving the display which triggered the modeset?
> 
> Since, the new cdclk freq that will be set is common for all the crtcs,
> we don't need the workaround for crtcs that are not in state. 

There can be another modeset afterwards that doesn't need the w/a and
that would then end up reducing cdclk below the required frequency.

> 
> > So I think we'd be OK with something like:
> > 
> > WARN_ON(!locked(connection_mutex));
> > 
> > for_each_intel_crtc() {
> > 	/*
> > 	 * Peeking at the current state is safe since
> > 	 * we can only get here while holding the
> > 	 * connection_mutex.
> > 	 */
> > 	crtc_state = intel_get_existing_crtc_state();
> > 	if (!crtc_state)
> > 		crtc_state = to_intel_crtc_state(crtc->base.state);
> > 
> > 	...
> > }
> > 
> > The other option would be to track the min cdclk for each pipe in the
> > top level state I suppose. We already do that for the pixel rate
> > actually so that we can calculate the cdclk to begin with. Hmm. Maybe
> > we should just switch to tracking the min cdclk per pipe instead of the
> > pixel rate. Or did we need to the pixel rate itself for something else,
> > Maarten?
> > 
> > Or we could perhaps replace the pixel rate/pixclk tracking with the peek
> > approach entirely. Not quite sure. Would have to read the entire thing
> > through.
> > 
> 
> I thought of this, but the work around applies for only three platforms
> (potentially just two) as of now. Does it warrant a driver wide change?
> I have to check if mincdclk is useful elsewhere.

We need to do one of these options. No way around it if we need this
w/a. Though I guess it's a little bit of an open question at the moment
since on SKL it only supposedly applies up to D stepping which we don't
care about. On BDW it seems to be for everything though.

> 
> > > +
> > > +	return false;
> > > +}
> > > +
> > >  static int bxt_modeset_calc_cdclk(struct drm_atomic_state *state)
> > >  {
> > >  	int max_pixclk = ilk_max_pixel_rate(state);
> > > +	int cdclk, min_cdclk = 0;
> > >  	struct intel_atomic_state *intel_state =
> > >  		to_intel_atomic_state(state);
> > >  
> > > -	intel_state->cdclk = intel_state->dev_cdclk =
> > > -		bxt_calc_cdclk(max_pixclk);
> > > +	if (cdclk_min_for_dp_audio(state))
> > > +		min_cdclk = bxt_calc_cdclk(432000);
> > > +
> > > +	cdclk = bxt_calc_cdclk(max_pixclk);
> > > +	intel_state->cdclk = intel_state->dev_cdclk = max(min_cdclk, cdclk);
> > >  
> > >  	if (!intel_state->active_crtcs)
> > >  		intel_state->dev_cdclk = bxt_calc_cdclk(0);
> > > @@ -10374,7 +10403,10 @@ static int broadwell_modeset_calc_cdclk(struct drm_atomic_state *state)
> > >  	struct drm_i915_private *dev_priv = to_i915(state->dev);
> > >  	struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
> > >  	int max_pixclk = ilk_max_pixel_rate(state);
> > > -	int cdclk;
> > > +	int cdclk, min_cdclk = 0;
> > > +
> > > +	if (cdclk_min_for_dp_audio(state))
> > > +		min_cdclk = broadwell_calc_cdclk(432000);
> > >  
> > >  	/*
> > >  	 * FIXME should also account for plane ratio
> > > @@ -10382,6 +10414,8 @@ static int broadwell_modeset_calc_cdclk(struct drm_atomic_state *state)
> > >  	 */
> > >  	cdclk = broadwell_calc_cdclk(max_pixclk);
> > >  
> > > +	cdclk =	max(min_cdclk, cdclk);
> > > +
> > >  	if (cdclk > dev_priv->max_cdclk_freq) {
> > >  		DRM_DEBUG_KMS("requested cdclk (%d kHz) exceeds max (%d kHz)\n",
> > >  			      cdclk, dev_priv->max_cdclk_freq);
> > > @@ -10411,7 +10445,10 @@ static int skl_modeset_calc_cdclk(struct drm_atomic_state *state)
> > >  	struct drm_i915_private *dev_priv = to_i915(state->dev);
> > >  	const int max_pixclk = ilk_max_pixel_rate(state);
> > >  	int vco = intel_state->cdclk_pll_vco;
> > > -	int cdclk;
> > > +	int cdclk, min_cdclk = 0;
> > > +
> > > +	if (cdclk_min_for_dp_audio(state))
> > > +		min_cdclk = skl_calc_cdclk(432000, vco);
> > >  
> > >  	/*
> > >  	 * FIXME should also account for plane ratio
> > > @@ -10419,6 +10456,8 @@ static int skl_modeset_calc_cdclk(struct drm_atomic_state *state)
> > >  	 */
> > >  	cdclk = skl_calc_cdclk(max_pixclk, vco);
> > >  
> > > +	cdclk = max(min_cdclk, cdclk);
> > > +
> > >  	/*
> > >  	 * FIXME move the cdclk caclulation to
> > >  	 * compute_config() so we can fail gracegully.
> > > -- 
> > > 2.7.4
> > 
> 

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2016-10-17  8:33 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-13 18:04 [PATCH] drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2 Dhinakaran Pandiyan
2016-10-13 18:28 ` Paulo Zanoni
2016-10-14 19:21   ` Pandiyan, Dhinakaran
2016-10-13 18:30 ` Jim Bride
2016-10-14 19:27   ` Pandiyan, Dhinakaran
2016-10-17  6:55     ` Daniel Vetter
2016-10-17  8:40       ` Ville Syrjälä
2016-10-13 18:44 ` Ville Syrjälä
2016-10-14 20:33   ` Pandiyan, Dhinakaran
2016-10-17  8:33     ` Ville Syrjälä [this message]
2016-10-21  1:45       ` Pandiyan, Dhinakaran
2016-10-13 18:49 ` ✓ Fi.CI.BAT: success for " Patchwork
2016-10-14  3:09 ` [PATCH] " Yang, Libin
2016-10-14 20:35   ` Pandiyan, Dhinakaran
2016-10-17  1:55     ` Yang, Libin
2016-10-14  8:40 ` Jani Nikula
2016-10-14 19:30   ` Pandiyan, Dhinakaran

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=20161017083306.GH4329@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=dhinakaran.pandiyan@intel.com \
    --cc=intel-gfx@freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=jeeja.kp@intel.com \
    --cc=libin.yang@linux.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 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.