public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 5/5] drm/i915: Make wait_for_flips interruptible.
Date: Tue, 21 Jul 2015 14:33:33 +0200	[thread overview]
Message-ID: <55AE3C1D.6040806@linux.intel.com> (raw)
In-Reply-To: <20150721112657.GE6166@nuc-i3427.alporthouse.com>

Op 21-07-15 om 13:26 schreef Chris Wilson:
> On Thu, Jul 16, 2015 at 02:57:51PM +0200, Maarten Lankhorst wrote:
>> Move it from intel_crtc_atomic_commit to prepare_plane_fb.
>> Waiting is done before committing, otherwise it's too late
>> to undo the changes.
>>
>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>> ---
>>  drivers/gpu/drm/i915/intel_atomic.c  |  2 -
>>  drivers/gpu/drm/i915/intel_display.c | 72 +++++++++++++++++-------------------
>>  drivers/gpu/drm/i915/intel_drv.h     |  2 -
>>  3 files changed, 33 insertions(+), 43 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_atomic.c b/drivers/gpu/drm/i915/intel_atomic.c
>> index e2531cf59266..09a0ad611002 100644
>> --- a/drivers/gpu/drm/i915/intel_atomic.c
>> +++ b/drivers/gpu/drm/i915/intel_atomic.c
>> @@ -214,8 +214,6 @@ int intel_atomic_setup_scalers(struct drm_device *dev,
>>  				 * but since this plane is unchanged just do the
>>  				 * minimum required validation.
>>  				 */
>> -				if (plane->type == DRM_PLANE_TYPE_PRIMARY)
>> -					intel_crtc->atomic.wait_for_flips = true;
>>  				crtc_state->base.planes_changed = true;
>>  			}
>>  
>> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>> index 5a462e9a4d14..8ef0dbb33afd 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -3250,32 +3250,6 @@ void intel_finish_reset(struct drm_device *dev)
>>  	drm_modeset_unlock_all(dev);
>>  }
>>  
>> -static void
>> -intel_finish_fb(struct drm_framebuffer *old_fb)
>> -{
>> -	struct drm_i915_gem_object *obj = intel_fb_obj(old_fb);
>> -	struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
>> -	bool was_interruptible = dev_priv->mm.interruptible;
>> -	int ret;
>> -
>> -	/* Big Hammer, we also need to ensure that any pending
>> -	 * MI_WAIT_FOR_EVENT inside a user batch buffer on the
>> -	 * current scanout is retired before unpinning the old
>> -	 * framebuffer. Note that we rely on userspace rendering
>> -	 * into the buffer attached to the pipe they are waiting
>> -	 * on. If not, userspace generates a GPU hang with IPEHR
>> -	 * point to the MI_WAIT_FOR_EVENT.
>> -	 *
>> -	 * This should only fail upon a hung GPU, in which case we
>> -	 * can safely continue.
>> -	 */
>> -	dev_priv->mm.interruptible = false;
>> -	ret = i915_gem_object_wait_rendering(obj, true);
>> -	dev_priv->mm.interruptible = was_interruptible;
>> -
>> -	WARN_ON(ret);
>> -}
>> -
>>  static bool intel_crtc_has_pending_flip(struct drm_crtc *crtc)
>>  {
>>  	struct drm_device *dev = crtc->dev;
>> @@ -3890,15 +3864,23 @@ static void page_flip_completed(struct intel_crtc *intel_crtc)
>>  				 work->pending_flip_obj);
>>  }
>>  
>> -void intel_crtc_wait_for_pending_flips(struct drm_crtc *crtc)
>> +static int intel_crtc_wait_for_pending_flips(struct drm_crtc *crtc)
>>  {
>>  	struct drm_device *dev = crtc->dev;
>>  	struct drm_i915_private *dev_priv = dev->dev_private;
>> +	long ret;
>>  
>>  	WARN_ON(waitqueue_active(&dev_priv->pending_flip_queue));
>> -	if (WARN_ON(wait_event_timeout(dev_priv->pending_flip_queue,
>> -				       !intel_crtc_has_pending_flip(crtc),
>> -				       60*HZ) == 0)) {
>> +
>> +	ret = wait_event_interruptible_timeout(
>> +					dev_priv->pending_flip_queue,
>> +					!intel_crtc_has_pending_flip(crtc),
>> +					60*HZ);
>> +
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	if (ret == 0) {
>>  		struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>>  
>>  		spin_lock_irq(&dev->event_lock);
>> @@ -3909,11 +3891,7 @@ void intel_crtc_wait_for_pending_flips(struct drm_crtc *crtc)
>>  		spin_unlock_irq(&dev->event_lock);
>>  	}
>>  
>> -	if (crtc->primary->fb) {
>> -		mutex_lock(&dev->struct_mutex);
>> -		intel_finish_fb(crtc->primary->fb);
>> -		mutex_unlock(&dev->struct_mutex);
>> -	}
>> +	return 0;
>>  }
>>  
>>  /* Program iCLKIP clock to the desired frequency */
>> @@ -4773,9 +4751,6 @@ static void intel_pre_plane_update(struct intel_crtc *crtc)
>>  	struct drm_i915_private *dev_priv = dev->dev_private;
>>  	struct intel_crtc_atomic_commit *atomic = &crtc->atomic;
>>  
>> -	if (atomic->wait_for_flips)
>> -		intel_crtc_wait_for_pending_flips(&crtc->base);
>> -
>>  	if (atomic->disable_fbc)
>>  		intel_fbc_disable_crtc(crtc);
>>  
>> @@ -11701,7 +11676,6 @@ int intel_plane_atomic_calc_changes(struct drm_crtc_state *crtc_state,
>>  
>>  	switch (plane->type) {
>>  	case DRM_PLANE_TYPE_PRIMARY:
>> -		intel_crtc->atomic.wait_for_flips = true;
>>  		intel_crtc->atomic.pre_disable_primary = turn_off;
>>  		intel_crtc->atomic.post_enable_primary = turn_on;
>>  
>> @@ -13473,6 +13447,12 @@ intel_prepare_plane_fb(struct drm_plane *plane,
>>  	struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->state->fb);
>>  	int ret = 0;
>>  
>> +	if (plane->type == DRM_PLANE_TYPE_PRIMARY && old_obj) {
> Would feel safer is we just asked if the CRTC had pending flips
> irrespective of old_obj. Do you plan on moving the pending flips from
> CRTC to plane? That would seem to be implied here.
This preserves old behavior since page flips can only happen on primary planes.
Do you want cursor updates to wait on pending primary flips?

>> +		ret = intel_crtc_wait_for_pending_flips(plane->state->crtc);
>> +		if (ret)
>> +			return ret;
>> +	}
>> +
>>  	if (obj == old_obj)
>>  		return 0;
>>  
>> @@ -13492,6 +13472,20 @@ intel_prepare_plane_fb(struct drm_plane *plane,
>>  		ret = intel_pin_and_fence_fb_obj(plane, fb, new_state, NULL, NULL);
>>  	}
>>  
>> +	/* Big Hammer, we also need to ensure that any pending
>> +	 * MI_WAIT_FOR_EVENT inside a user batch buffer on the
>> +	 * current scanout is retired before unpinning the old
>> +	 * framebuffer. Note that we rely on userspace rendering
>> +	 * into the buffer attached to the pipe they are waiting
>> +	 * on. If not, userspace generates a GPU hang with IPEHR
>> +	 * point to the MI_WAIT_FOR_EVENT.
>> +	 *
>> +	 * This should only fail upon a hung GPU, in which case we
>> +	 * can safely continue.
>> +	 */
>> +	if (!ret && plane->type == DRM_PLANE_TYPE_PRIMARY && old_obj)
>> +		ret = i915_gem_object_wait_rendering(old_obj, true);
> Technically I can create a batch with a WAIT_ON_EVENT for a secondary
> plane as well. This path need only be done in a modeset, not for a
> simple plane flip. (But we actually need to serialise with rendering to
> old_obj before regarding the plane flip as complete.) Is there a
> plane-prepare-modeset hook?
The comment didn't explain that, is hiding this behind a needs_modeset(crtc_state) sufficient here?

~Maarten

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

  reply	other threads:[~2015-07-21 12:33 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-16 12:57 [PATCH 0/5] drm/i915: Make waiting interruptible Maarten Lankhorst
2015-07-16 12:57 ` [PATCH 1/5] drm/i915: Handle return value in intel_pin_and_fence_fb_obj Maarten Lankhorst
2015-07-21 11:31   ` Chris Wilson
2015-07-21 14:09     ` [PATCH v1.1 1/5] drm/i915: Handle return value in intel_pin_and_fence_fb_obj, v2 Maarten Lankhorst
2015-07-24 13:26       ` Ander Conselvan De Oliveira
2015-07-24 14:02         ` Chris Wilson
2015-07-26  7:24         ` Maarten Lankhorst
2015-07-16 12:57 ` [PATCH 2/5] drm/atomic: Make prepare_fb/cleanup_fb only take state Maarten Lankhorst
2015-07-16 14:13   ` [PATCH v1.1 2/5] drm/atomic: Make prepare_fb/cleanup_fb only take state, v2 Maarten Lankhorst
2015-07-22 13:23     ` Rob Clark
2015-07-27  7:53       ` [Intel-gfx] " Daniel Vetter
2015-07-27 11:07         ` Maarten Lankhorst
2015-07-27 11:14           ` Daniel Vetter
2015-07-27 11:55             ` [Intel-gfx] " Maarten Lankhorst
2015-07-16 12:57 ` [PATCH 3/5] drm/i915: Make prepare_plane_fb fully interruptible Maarten Lankhorst
2015-07-16 12:57 ` [PATCH 4/5] drm/i915: Remove wait_for_pending_flips from disable_noatomic Maarten Lankhorst
2015-07-21 11:35   ` Chris Wilson
2015-07-21 12:38     ` Maarten Lankhorst
2015-07-21 12:40       ` Chris Wilson
2015-07-21 12:47         ` Maarten Lankhorst
2015-07-16 12:57 ` [PATCH 5/5] drm/i915: Make wait_for_flips interruptible Maarten Lankhorst
2015-07-20 14:52   ` Maarten Lankhorst
2015-07-21  6:51     ` Daniel Vetter
2015-07-21  8:02       ` Maarten Lankhorst
2015-07-21 11:26   ` Chris Wilson
2015-07-21 12:33     ` Maarten Lankhorst [this message]
2015-07-21 13:31       ` Chris Wilson
2015-07-21 13:59         ` Maarten Lankhorst
2015-07-21 14:39           ` Chris Wilson

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=55AE3C1D.6040806@linux.intel.com \
    --to=maarten.lankhorst@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    /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