public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Ander Conselvan De Oliveira <conselvan2@gmail.com>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 02/11] drm/i915: Remove stallcheck special handling.
Date: Mon, 18 Apr 2016 10:57:55 +0300	[thread overview]
Message-ID: <1460966275.3739.18.camel@gmail.com> (raw)
In-Reply-To: <5714714C.3040803@linux.intel.com>

On Mon, 2016-04-18 at 07:31 +0200, Maarten Lankhorst wrote:
> Op 15-04-16 om 09:07 schreef Ander Conselvan De Oliveira:
> > On Wed, 2016-04-13 at 11:18 +0200, Maarten Lankhorst wrote:
> > > Re-use unpin_work->pending, but also set vblank count before
> > > intel_mark_page_flip_active to be sure.
> > Be sure of what?
> > 
> > > Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/i915_debugfs.c  | 11 ++++++-----
> > >  drivers/gpu/drm/i915/intel_display.c | 31 ++++++++++++-------------------
> > >  drivers/gpu/drm/i915/intel_drv.h     |  1 -
> > >  3 files changed, 18 insertions(+), 25 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > > b/drivers/gpu/drm/i915/i915_debugfs.c
> > > index 9640738aabf2..df8073a2ffbe 100644
> > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > @@ -582,9 +582,14 @@ static int i915_gem_pageflip_info(struct seq_file *m,
> > > void *data)
> > >  			seq_printf(m, "No flip due on pipe %c (plane
> > > %c)\n",
> > >  				   pipe, plane);
> > >  		} else {
> > > +			u32 pending;
> > >  			u32 addr;
> > >  
> > > -			if (atomic_read(&work->pending) <
> > > INTEL_FLIP_COMPLETE) {
> > > +			pending = atomic_read(&work->pending);
> > > +			if (pending == INTEL_FLIP_INACTIVE) {
> > > +				seq_printf(m, "Flip ioctl preparing on
> > > pipe
> > > %c (plane %c)\n",
> > > +					   pipe, plane);
> > > +			} else if (pending >= INTEL_FLIP_COMPLETE) {
> > >  				seq_printf(m, "Flip queued on pipe %c
> > > (plane
> > > %c)\n",
> > >  					   pipe, plane);
> > >  			} else {
> > > @@ -606,10 +611,6 @@ static int i915_gem_pageflip_info(struct seq_file *m,
> > > void *data)
> > >  				   work->flip_queued_vblank,
> > >  				   work->flip_ready_vblank,
> > >  				   drm_crtc_vblank_count(&crtc->base));
> > > -			if (work->enable_stall_check)
> > > -				seq_puts(m, "Stall check enabled, ");
> > > -			else
> > > -				seq_puts(m, "Stall check waiting for page
> > > flip ioctl, ");
> > >  			seq_printf(m, "%d prepares\n", atomic_read(&work
> > > ->pending));
> > >  
> > >  			if (INTEL_INFO(dev)->gen >= 4)
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index f2be54a48727..618e034a7a5e 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -11415,8 +11415,6 @@ static void intel_do_mmio_flip(struct
> > > intel_mmio_flip
> > > *mmio_flip)
> > >  	if (work == NULL)
> > >  		return;
> > >  
> > > -	intel_mark_page_flip_active(work);
> > > -
> > >  	intel_pipe_update_start(crtc);
> > >  
> > >  	if (INTEL_INFO(mmio_flip->i915)->gen >= 9)
> > > @@ -11426,6 +11424,8 @@ static void intel_do_mmio_flip(struct
> > > intel_mmio_flip
> > > *mmio_flip)
> > >  		ilk_do_mmio_flip(crtc, work);
> > >  
> > >  	intel_pipe_update_end(crtc);
> > > +
> > > +	intel_mark_page_flip_active(work);
> > Is this to avoid triggering the stall check during the wait from a vblank
> > evasion?
> It's to ensure that if a vblank happens before pipe_update_end, we don't mark 
> the flip as completed until we actually updated the mmio registers.

But interrupts are disabled between pipe_update_start() and pipe_update_end(),
so if that happens it either happens before or during pipe_update_start(), no?

Is it possible the vblank happens just after pipe_update_end() and before
marking it active? Seems to me that in that case, first prepare_page_flip() will
increase unpin_work->pending (so it will go from INACTIVE to PENDING) and then
marking it active will set it again to PENDING, so it never gets to COMPLETE.

But even if the above can happen, that is fixed by the removal of the COMPLETE
state in patch 3.

> > 
> > >  }
> > >  
> > >  static void intel_mmio_flip_work_func(struct work_struct *work)
> > > @@ -11492,15 +11492,11 @@ static bool __intel_pageflip_stall_check(struct
> > > drm_device *dev,
> > >  	struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > >  	struct intel_unpin_work *work = intel_crtc->unpin_work;
> > >  	u32 addr;
> > > +	u32 pending;
> > >  
> > > -	if (atomic_read(&work->pending) >= INTEL_FLIP_COMPLETE)
> > > -		return true;
> > > -
> > > -	if (atomic_read(&work->pending) < INTEL_FLIP_PENDING)
> > > -		return false;
> > > -
> > > -	if (!work->enable_stall_check)
> > > -		return false;
> > > +	pending = atomic_read(&work->pending);
> > > +	if (pending != INTEL_FLIP_PENDING)
> > > +		return pending == INTEL_FLIP_COMPLETE;
> > >  
> > >  	if (work->flip_ready_vblank == 0) {
> > >  		if (work->flip_queued_req &&
> > > @@ -11676,6 +11672,11 @@ static int intel_crtc_page_flip(struct drm_crtc
> > > *crtc,
> > >  	 */
> > >  	if (!mmio_flip) {
> > >  		ret = i915_gem_object_sync(obj, engine, &request);
> > > +		if (!ret && !request) {
> > > +			request = i915_gem_request_alloc(engine, NULL);
> > > +			ret = PTR_ERR_OR_ZERO(request);
> > > +		}
> > > +
> > >  		if (ret)
> > >  			goto cleanup_pending;
> > >  	}
> > > @@ -11687,6 +11688,7 @@ static int intel_crtc_page_flip(struct drm_crtc
> > > *crtc,
> > >  	work->gtt_offset =
> > > intel_plane_obj_offset(to_intel_plane(primary),
> > >  						  obj, 0);
> > >  	work->gtt_offset += intel_crtc->dspaddr_offset;
> > > +	work->flip_queued_vblank = drm_crtc_vblank_count(crtc);
> > >  
> > >  	if (mmio_flip) {
> > >  		ret = intel_queue_mmio_flip(dev, crtc, obj);
> > > @@ -11696,14 +11698,6 @@ static int intel_crtc_page_flip(struct drm_crtc
> > > *crtc,
> > >  		i915_gem_request_assign(&work->flip_queued_req,
> > >  					obj->last_write_req);
> > >  	} else {
> > > -		if (!request) {
> > > -			request = i915_gem_request_alloc(engine, NULL);
> > > -			if (IS_ERR(request)) {
> > > -				ret = PTR_ERR(request);
> > > -				goto cleanup_unpin;
> > > -			}
> > > -		}
> > > -
> > >  		ret = dev_priv->display.queue_flip(dev, crtc, fb, obj,
> > > request,
> > >  						   page_flip_flags);
> > >  		if (ret)
> > > @@ -11716,7 +11710,6 @@ static int intel_crtc_page_flip(struct drm_crtc
> > > *crtc,
> > >  		i915_add_request_no_flush(request);
> > >  
> > >  	work->flip_queued_vblank = drm_crtc_vblank_count(crtc);
> > Do we still need the assigment above?
> > 
> It's used for rps boosting, so likely...

But you added the same assignment above, so removing it would only change the
timing of the boost if the count were to flip while queuing but not prevent the
boost from happening. It's no big deal, I just find it odd that we need to set
that value twice.

Ander


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2016-04-18  7:57 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-13  9:18 [PATCH v2 00/11] drm/i915: Rework page flip to be more atomic like, and remove cs flips Maarten Lankhorst
2016-04-13  9:18 ` [PATCH v2 01/11] drm/core: Add drm_accurate_vblank_count, v4 Maarten Lankhorst
2016-04-13  9:18 ` [PATCH v2 02/11] drm/i915: Remove stallcheck special handling Maarten Lankhorst
2016-04-15  7:07   ` Ander Conselvan De Oliveira
2016-04-18  5:31     ` Maarten Lankhorst
2016-04-18  7:57       ` Ander Conselvan De Oliveira [this message]
2016-04-18  8:23         ` Maarten Lankhorst
2016-04-18 10:00         ` [PATCH v2.1 02/11] drm/i915: Remove stallcheck special handling, v2 Maarten Lankhorst
2016-04-13  9:18 ` [PATCH v2 03/11] drm/i915: Remove intel_prepare_page_flip Maarten Lankhorst
2016-04-15 12:21   ` Ander Conselvan De Oliveira
2016-04-18  5:27     ` Maarten Lankhorst
2016-04-18 10:09     ` [PATCH v2.1 03/11] drm/i915: Remove intel_prepare_page_flip, v2 Maarten Lankhorst
2016-04-18 10:10       ` [PATCH v2.2 " Maarten Lankhorst
2016-04-13  9:18 ` [PATCH v2 04/11] drm/i915: Add support for detecting vblanks when hw frame counter is unavailable Maarten Lankhorst
2016-04-13  9:18 ` [PATCH v2 05/11] drm/i915: Allow mmio updates on all platforms, v2 Maarten Lankhorst
2016-04-15 12:31   ` Ander Conselvan De Oliveira
2016-04-18  5:47     ` Maarten Lankhorst
2016-04-13  9:18 ` [PATCH v2 06/11] drm/i915: Convert flip_work to a list Maarten Lankhorst
2016-04-13  9:18 ` [PATCH v2 07/11] drm/i915: Add the exclusive fence to plane_state Maarten Lankhorst
2016-04-13  9:18 ` [PATCH v2 08/11] drm/i915: Rework intel_crtc_page_flip to be almost atomic, v3 Maarten Lankhorst
2016-04-13  9:18 ` [PATCH v2 09/11] drm/i915: Remove cs based page flip support Maarten Lankhorst
2016-04-13  9:18 ` [PATCH v2 10/11] drm/i915: Remove use_mmio_flip kernel parameter Maarten Lankhorst
2016-04-13  9:18 ` [PATCH v2 11/11] drm/i915: Remove queue_flip pointer Maarten Lankhorst
2016-04-13 17:55 ` ✗ Fi.CI.BAT: failure for drm/i915: Rework page flip to be more atomic like, and remove cs flips 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=1460966275.3739.18.camel@gmail.com \
    --to=conselvan2@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --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