public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Matt Roper <matthew.d.roper@intel.com>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 5/9] drm/i915: Setup clipped src/dest coordinates during FB reconstruction (v2)
Date: Thu, 3 Dec 2015 09:08:48 -0800	[thread overview]
Message-ID: <20151203170848.GB6257@intel.com> (raw)
In-Reply-To: <56603054.4080102@linux.intel.com>

On Thu, Dec 03, 2015 at 01:06:44PM +0100, Maarten Lankhorst wrote:
> Op 25-11-15 om 17:48 schreef Matt Roper:
> > Plane state objects contain two copies of src/dest coordinates:  the
> > original (requested by userspace) coordinates in the base
> > drm_plane_state object, and a second, clipped copy (i.e., what we
> > actually want to program to the hardware) in intel_plane_state.  We've
> > only been setting up the former set of values during boot time FB
> > reconstruction, but we should really be initializing both.
> >
> > Note that the code here probably still needs some more work since we
> > make a lot of assumptions about how the BIOS programmed the hardware
> > that may not always be true, especially on gen9+; e.g.,
> >  * Primary plane might not be positioned at 0,0
> >  * Primary plane could have been rotated by the BIOS
> >  * Primary plane might be scaled
> >  * The BIOS fb might be a single "extended mode" FB that spans
> >    multiple displays.
> >  * ...etc...
> >
> > v2: Reword/expand commit message description of assumptions we make
> >
> > Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> > Reviewed-by(v1): Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 11 +++++++++++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> > index 73e9bf9..00e4c37 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -2599,6 +2599,8 @@ intel_find_initial_plane_obj(struct intel_crtc *intel_crtc,
> >  	struct drm_plane_state *plane_state = primary->state;
> >  	struct drm_crtc_state *crtc_state = intel_crtc->base.state;
> >  	struct intel_plane *intel_plane = to_intel_plane(primary);
> > +	struct intel_plane_state *intel_state =
> > +		to_intel_plane_state(plane_state);
> >  	struct drm_framebuffer *fb;
> >  
> >  	if (!plane_config->fb)
> > @@ -2659,6 +2661,15 @@ valid_fb:
> >  	plane_state->crtc_w = fb->width;
> >  	plane_state->crtc_h = fb->height;
> >  
> > +	intel_state->src.x1 = plane_state->src_x;
> > +	intel_state->src.y1 = plane_state->src_y;
> > +	intel_state->src.x2 = plane_state->src_x + plane_state->src_w;
> > +	intel_state->src.y2 = plane_state->src_y + plane_state->src_h;
> > +	intel_state->dst.x1 = plane_state->crtc_x;
> > +	intel_state->dst.y1 = plane_state->crtc_y;
> > +	intel_state->dst.x2 = plane_state->crtc_x + plane_state->crtc_w;
> > +	intel_state->dst.y2 = plane_state->crtc_y + plane_state->crtc_h;
> >
> Why does it matter that those coordinates are set up? The first atomic commit would overwrite those anyway..

We potentially use these during watermark calculations when trying to
calculate what we think sane watermark values would be for the
hardware-readout state, which is before we get to our first commit.


Matt

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-12-03 17:08 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-25 16:48 [PATCH 0/9] Wrap up ILK-style atomic watermarks Matt Roper
2015-11-25 16:48 ` [PATCH 1/9] drm/i915: Disable primary plane if we fail to reconstruct BIOS fb Matt Roper
2015-12-03 11:40   ` Maarten Lankhorst
2015-11-25 16:48 ` [PATCH 2/9] drm/i915: Dump in-flight plane state while dumping in-flight CRTC state Matt Roper
2015-12-03 12:27   ` Maarten Lankhorst
2015-12-04  9:31     ` Daniel Vetter
2015-11-25 16:48 ` [PATCH 3/9] drm/i915: Clarify plane state during CRTC state dumps (v2) Matt Roper
2015-12-03 12:28   ` Maarten Lankhorst
2015-11-25 16:48 ` [PATCH 4/9] drm/i915: Dump pipe config after initial FB is reconstructed Matt Roper
2015-12-03 12:29   ` Maarten Lankhorst
2015-11-25 16:48 ` [PATCH 5/9] drm/i915: Setup clipped src/dest coordinates during FB reconstruction (v2) Matt Roper
2015-12-03 12:06   ` Maarten Lankhorst
2015-12-03 17:08     ` Matt Roper [this message]
2015-11-25 16:48 ` [PATCH 6/9] drm/i915: Convert hsw_compute_linetime_wm to use in-flight state Matt Roper
2015-11-25 16:48 ` [PATCH 7/9] drm/i915: Add extra paranoia to ILK watermark calculations Matt Roper
2015-11-25 16:48 ` [PATCH 8/9] drm/i915: Sanitize watermarks after hardware state readout (v2) Matt Roper
2015-11-25 17:05   ` Ville Syrjälä
2015-11-30 23:56     ` [PATCH] drm/i915: Sanitize watermarks after hardware state readout (v3) Matt Roper
2015-12-01  7:42       ` Maarten Lankhorst
2015-11-30  9:50   ` [PATCH 8/9] drm/i915: Sanitize watermarks after hardware state readout (v2) Maarten Lankhorst
2015-11-30 23:09     ` Matt Roper
2015-11-30 23:22     ` [PATCH] drm/atomic-helper: Grab connection_mutex while duplicating state Matt Roper
2015-12-01  7:24       ` Daniel Vetter
2015-12-01  7:37       ` Maarten Lankhorst
2015-11-25 16:48 ` [PATCH 9/9] drm/i915: Add two-stage ILK-style watermark programming (v7) Matt Roper
2015-11-25 17:08   ` Ville Syrjälä
2015-12-01  0:08     ` Matt Roper
2015-11-25 17:00 ` [PATCH 0/9] Wrap up ILK-style atomic watermarks Ville Syrjälä
2015-11-25 17:04   ` Matt Roper
2015-11-25 17:14     ` 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=20151203170848.GB6257@intel.com \
    --to=matthew.d.roper@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=maarten.lankhorst@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