public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: ville.syrjala@linux.intel.com
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 4/4] drm/i915: Do some basic sanity adjustments on the user provided mode
Date: Tue, 1 Oct 2013 21:06:10 +0200	[thread overview]
Message-ID: <20131001190610.GS26592@phenom.ffwll.local> (raw)
In-Reply-To: <1380633211-16138-5-git-send-email-ville.syrjala@linux.intel.com>

On Tue, Oct 01, 2013 at 04:13:31PM +0300, ville.syrjala@linux.intel.com wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> Make sure the active, blanking and sync portions of the timings are in
> the proper order. The contract with userspace basically is that we must
> not increase the active portion. For the rest we're more or less free to
> do as we please. A good rul IMO is that we only increase the non-active
> portions of the timings.
> 
> We could do a lot more adjustment to make sure the timings meet all
> the minimum requirements of the hardware. But as the mimimums may depend
> on the output type and other details, we should perhaps do the adjustments
> at some later point.
> 
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

Do we actually get such modes?

I'd vote to just filter them from our ->get_modes callbacks and reject
them here if at all possible ...
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_display.c | 60 ++++++++++++++++++++++++++++++++++--
>  1 file changed, 58 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 7f61cfb..48cad99 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -8458,6 +8458,55 @@ static bool check_encoder_cloning(struct drm_crtc *crtc)
>  	return !(num_encoders > 1 && uncloneable_encoders);
>  }
>  
> +static void adjust_timings(struct drm_display_mode *mode,
> +			   int *val, int min, int clocks_per_unit)
> +{
> +	if (*val >= min)
> +		return;
> +
> +	/* maintain the same refresh rate */
> +	mode->clock += (min - *val) * clocks_per_unit;
> +
> +	*val = min;
> +}
> +
> +static int intel_adjust_mode(struct drm_display_mode *mode)
> +{
> +	if (mode->clock == 0) {
> +		DRM_DEBUG_KMS("bad pixel clock\n");
> +		drm_mode_debug_printmodeline(mode);
> +		return -EINVAL;
> +	}
> +
> +	if (mode->hdisplay == 0 || mode->vdisplay == 0) {
> +		DRM_DEBUG_KMS("bad hdisplay or vdisplay\n");
> +		drm_mode_debug_printmodeline(mode);
> +		return -EINVAL;
> +	}
> +
> +	adjust_timings(mode, &mode->hsync_start, mode->hdisplay, 0);
> +	adjust_timings(mode, &mode->hsync_end, mode->hsync_start, 0);
> +	adjust_timings(mode, &mode->htotal, mode->hsync_end, mode->vtotal);
> +
> +	adjust_timings(mode, &mode->vsync_start, mode->vdisplay, 0);
> +	adjust_timings(mode, &mode->vsync_end, mode->vsync_start, 0);
> +
> +	/*
> +	 * We must not increase the size of the active
> +	 * space area for frame packing modes.
> +	 */
> +	if ((mode->flags & DRM_MODE_FLAG_3D_MASK) == DRM_MODE_FLAG_3D_FRAME_PACKING) {
> +		if (mode->vtotal <  mode->vsync_end) {
> +			DRM_DEBUG_KMS("refusing to adjust vtotal for frame packing mode\n");
> +			drm_mode_debug_printmodeline(mode);
> +			return -EINVAL;
> +		}
> +	} else
> +		adjust_timings(mode, &mode->vtotal, mode->vsync_end, mode->htotal);
> +
> +	return 0;
> +}
> +
>  static struct intel_crtc_config *
>  intel_modeset_pipe_config(struct drm_crtc *crtc,
>  			  struct drm_framebuffer *fb,
> @@ -8466,7 +8515,7 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
>  	struct drm_device *dev = crtc->dev;
>  	struct intel_encoder *encoder;
>  	struct intel_crtc_config *pipe_config;
> -	int plane_bpp, ret = -EINVAL;
> +	int plane_bpp, ret;
>  	bool retry = true;
>  
>  	if (!check_encoder_cloning(crtc)) {
> @@ -8498,14 +8547,20 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
>  	      (DRM_MODE_FLAG_PVSYNC | DRM_MODE_FLAG_NVSYNC)))
>  		pipe_config->adjusted_mode.flags |= DRM_MODE_FLAG_NVSYNC;
>  
> +	ret = intel_adjust_mode(&pipe_config->adjusted_mode);
> +	if (ret)
> +		goto fail;
> +
>  	/* Compute a starting value for pipe_config->pipe_bpp taking the source
>  	 * plane pixel format and any sink constraints into account. Returns the
>  	 * source plane bpp so that dithering can be selected on mismatches
>  	 * after encoders and crtc also have had their say. */
>  	plane_bpp = compute_baseline_pipe_bpp(to_intel_crtc(crtc),
>  					      fb, pipe_config);
> -	if (plane_bpp < 0)
> +	if (plane_bpp < 0) {
> +		ret = -EINVAL;
>  		goto fail;
> +	}
>  
>  	/* Determine the real pipe dimensions */
>  	drm_mode_set_crtcinfo(&pipe_config->adjusted_mode, CRTC_STEREO_DOUBLE);
> @@ -8532,6 +8587,7 @@ encoder_retry:
>  
>  		if (!(encoder->compute_config(encoder, pipe_config))) {
>  			DRM_DEBUG_KMS("Encoder config failure\n");
> +			ret = -EINVAL;
>  			goto fail;
>  		}
>  	}
> -- 
> 1.8.1.5
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

  reply	other threads:[~2013-10-01 19:05 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-01 13:13 [PATCH 0/4] drm/i915: Some sanity checks for modes ville.syrjala
2013-10-01 13:13 ` [PATCH 1/4] drm/i915: Don't populate pipe_src_{w, h} multiple times ville.syrjala
2013-10-01 19:03   ` Daniel Vetter
2013-10-01 19:14     ` Ville Syrjälä
2013-10-01 19:52     ` [PATCH v2 " ville.syrjala
2013-10-01 20:03       ` Daniel Vetter
2013-10-01 13:13 ` [PATCH 2/4] drm/i915: Reject modes where hdisplay or vdisplay is too small ville.syrjala
2013-10-01 20:08   ` Rodrigo Vivi
2013-10-01 20:55     ` Ville Syrjälä
2013-10-01 21:08       ` Rodrigo Vivi
2013-10-01 13:13 ` [PATCH 3/4] drm/915: Make sure pipe source size isn't zero ville.syrjala
2013-10-01 13:13 ` [PATCH 4/4] drm/i915: Do some basic sanity adjustments on the user provided mode ville.syrjala
2013-10-01 19:06   ` Daniel Vetter [this message]
2013-10-01 19:12     ` Ville Syrjälä

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=20131001190610.GS26592@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ville.syrjala@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox