All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Ramalingam C <ramalingam.c@intel.com>
Cc: jani.nikula@intel.com, intel-gfx@lists.freedesktop.org
Subject: Re: [RFC PATCH 2/2] drm/i915/bxt: Adjusting the error in horizontal timings retrieval
Date: Wed, 27 Apr 2016 20:11:18 +0300	[thread overview]
Message-ID: <20160427171118.GQ4329@intel.com> (raw)
In-Reply-To: <1461053894-5058-2-git-send-email-ramalingam.c@intel.com>

On Tue, Apr 19, 2016 at 01:48:14PM +0530, Ramalingam C wrote:
> In BXT DSI there is no regs programmed with few horizontal timings
> in Pixels but txbyteclkhs.. So retrieval process adds some
> ROUND_UP ERRORS in the process of PIXELS<==>txbyteclkhs.
> 
> Actually here for the given adjusted_mode, we are calculating the
> value programmed to the port and then back to the horizontal timing
> param in pixels. This is the expected value at the end of get_config,
> including roundup errors. And if that is same as retrieved value
> from port, then retrieved (HW state) adjusted_mode's horizontal
> timings are corrected to match with SW state to nullify the errors.
> 
> Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_dsi.c |   97 ++++++++++++++++++++++++++++++++++----
>  1 file changed, 88 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
> index e0259e6..8a1b872 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -46,6 +46,14 @@ static const struct {
>  	},
>  };
>  
> +/* return pixels in terms of txbyteclkhs */
> +static u16 txbyteclkhs(u16 pixels, int bpp, int lane_count,
> +		       u16 burst_mode_ratio)
> +{
> +	return DIV_ROUND_UP(DIV_ROUND_UP(pixels * bpp * burst_mode_ratio,
> +					 8 * 100), lane_count);
> +}
> +
>  /* return pixels equvalent to txbyteclkhs */
>  static u16 pixels_from_txbyteclkhs(u16 clk_hs, int bpp, int lane_count,
>  			u16 burst_mode_ratio)
> @@ -779,11 +787,19 @@ static void bxt_dsi_get_pipe_config(struct intel_encoder *encoder,
>  	struct drm_i915_private *dev_priv = dev->dev_private;
>  	struct drm_display_mode *adjusted_mode =
>  					&pipe_config->base.adjusted_mode;
> +	struct drm_display_mode *adjusted_mode_sw;
> +	struct intel_crtc *intel_crtc;
>  	struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
>  	unsigned int lane_count = intel_dsi->lane_count;
>  	unsigned int bpp, fmt;
>  	enum port port;
>  	u16 hactive, hfp, hsync, hbp, vfp, vsync, vbp;
> +	u16 hfp_sw, hsync_sw, hbp_sw;
> +	u16 crtc_htotal_sw, crtc_hsync_start_sw, crtc_hsync_end_sw,
> +				crtc_hblank_start_sw, crtc_hblank_end_sw;
> +
> +	intel_crtc = to_intel_crtc(encoder->base.crtc);
> +	adjusted_mode_sw = &intel_crtc->config->base.adjusted_mode;
>
 
>  	/*
>  	 * Atleast one port is active as encoder->get_config called only if
> @@ -847,8 +863,79 @@ static void bxt_dsi_get_pipe_config(struct intel_encoder *encoder,
>  	adjusted_mode->crtc_vsync_end = vsync + adjusted_mode->crtc_vsync_start;
>  	adjusted_mode->crtc_vblank_start = adjusted_mode->crtc_vdisplay;
>  	adjusted_mode->crtc_vblank_end = adjusted_mode->crtc_vtotal;
> -}
>  
> +	/*
> +	 * In BXT DSI there is no regs programmed with few horizontal timings
> +	 * in Pixels but txbyteclkhs.. So retrieval process adds some
> +	 * ROUND_UP ERRORS in the process of PIXELS<==>txbyteclkhs.
> +	 * Actually here for the given adjusted_mode, we are calculating the
> +	 * value programmed to the port and then back to the horizontal timing
> +	 * param in pixels. This is the expected value, including roundup errors
> +	 * And if that is same as retrieved value from port, then
> +	 * (HW state) adjusted_mode's horizontal timings are corrected to
> +	 * match with SW state to nullify the errors.
> +	 */
> +	/* Calculating the value programmed to the Port register */
> +	hfp_sw = adjusted_mode_sw->crtc_hsync_start -
> +					adjusted_mode_sw->crtc_hdisplay;
> +	hsync_sw = adjusted_mode_sw->crtc_hsync_end -
> +					adjusted_mode_sw->crtc_hsync_start;
> +	hbp_sw = adjusted_mode_sw->crtc_htotal -
> +					adjusted_mode_sw->crtc_hsync_end;

So during the initial state readout we get passed crtc->config as
pipe_config, and so we'll end up comparing the thing with itself. That
should be fine. A bit of extra care is needed to make sure we don't use
anything from crtc->config before we've filled it out with something,
but looks like the code does things in the right order (given the
previous patch which fills out all the htimings with something).

I think the biggest issue with this patch is seeing the forest from the
trees. Some refactoring would be good so that we'd have some kind of
htimings_{to,from}_txbyteclkhs() functions instead of duplicating the
same code multiple times.

So while it does look quite strange to be using crtc->config in the
.get_config() I think it should work out.

Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

> +
> +	if (intel_dsi->dual_link) {
> +		hfp_sw /= 2;
> +		hsync_sw /= 2;
> +		hbp_sw /= 2;
> +	}
> +
> +	hfp_sw = txbyteclkhs(hfp_sw, bpp, lane_count,
> +						intel_dsi->burst_mode_ratio);
> +	hsync_sw = txbyteclkhs(hsync_sw, bpp, lane_count,
> +			    intel_dsi->burst_mode_ratio);
> +	hbp_sw = txbyteclkhs(hbp_sw, bpp, lane_count,
> +						intel_dsi->burst_mode_ratio);
> +
> +	/* Reverse calculating the adjusted mode parameters from port reg vals*/
> +	hfp_sw = pixels_from_txbyteclkhs(hfp_sw, bpp, lane_count,
> +						intel_dsi->burst_mode_ratio);
> +	hsync_sw = pixels_from_txbyteclkhs(hsync_sw, bpp, lane_count,
> +						intel_dsi->burst_mode_ratio);
> +	hbp_sw = pixels_from_txbyteclkhs(hbp_sw, bpp, lane_count,
> +						intel_dsi->burst_mode_ratio);
> +
> +	if (intel_dsi->dual_link) {
> +		hfp_sw *= 2;
> +		hsync_sw *= 2;
> +		hbp_sw *= 2;
> +	}
> +
> +	crtc_htotal_sw = adjusted_mode_sw->crtc_hdisplay + hfp_sw +
> +							hsync_sw + hbp_sw;
> +	crtc_hsync_start_sw = hfp_sw + adjusted_mode_sw->crtc_hdisplay;
> +	crtc_hsync_end_sw = hsync_sw + crtc_hsync_start_sw;
> +	crtc_hblank_start_sw = adjusted_mode_sw->crtc_hdisplay;
> +	crtc_hblank_end_sw = crtc_htotal_sw;
> +
> +	if (adjusted_mode->crtc_htotal == crtc_htotal_sw)
> +		adjusted_mode->crtc_htotal = adjusted_mode_sw->crtc_htotal;
> +
> +	if (adjusted_mode->crtc_hsync_start == crtc_hsync_start_sw)
> +		adjusted_mode->crtc_hsync_start =
> +					adjusted_mode_sw->crtc_hsync_start;
> +
> +	if (adjusted_mode->crtc_hsync_end == crtc_hsync_end_sw)
> +		adjusted_mode->crtc_hsync_end =
> +					adjusted_mode_sw->crtc_hsync_end;
> +
> +	if (adjusted_mode->crtc_hblank_start == crtc_hblank_start_sw)
> +		adjusted_mode->crtc_hblank_start =
> +					adjusted_mode_sw->crtc_hblank_start;
> +
> +	if (adjusted_mode->crtc_hblank_end == crtc_hblank_end_sw)
> +		adjusted_mode->crtc_hblank_end =
> +					adjusted_mode_sw->crtc_hblank_end;
> +}
>  
>  static void intel_dsi_get_config(struct intel_encoder *encoder,
>  				 struct intel_crtc_state *pipe_config)
> @@ -917,14 +1004,6 @@ static u16 txclkesc(u32 divider, unsigned int us)
>  	}
>  }
>  
> -/* return pixels in terms of txbyteclkhs */
> -static u16 txbyteclkhs(u16 pixels, int bpp, int lane_count,
> -		       u16 burst_mode_ratio)
> -{
> -	return DIV_ROUND_UP(DIV_ROUND_UP(pixels * bpp * burst_mode_ratio,
> -					 8 * 100), lane_count);
> -}
> -
>  static void set_dsi_timings(struct drm_encoder *encoder,
>  			    const struct drm_display_mode *adjusted_mode)
>  {
> -- 
> 1.7.9.5
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

  parent reply	other threads:[~2016-04-27 17:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-19  8:18 [PATCH 1/2] drm/i915/BXT: Retrieving the horizontal timing for DSI Ramalingam C
2016-04-19  8:18 ` [RFC PATCH 2/2] drm/i915/bxt: Adjusting the error in horizontal timings retrieval Ramalingam C
2016-04-20 13:26   ` Daniel Vetter
2016-04-21  4:41     ` Ramalingam C
2016-04-27 17:11   ` Ville Syrjälä [this message]
2016-04-28 14:11     ` Jani Nikula
2016-04-27 16:20 ` [PATCH 1/2] drm/i915/BXT: Retrieving the horizontal timing for DSI Imre Deak

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=20160427171118.GQ4329@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=ramalingam.c@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.