All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
To: Ander Conselvan De Oliveira <conselvan2@gmail.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/5] drm/i915: Make plane fb tracking work correctly, v2.
Date: Wed, 14 Oct 2015 15:54:19 +0200	[thread overview]
Message-ID: <561E5E8B.3090405@linux.intel.com> (raw)
In-Reply-To: <1444827570.2636.13.camel@gmail.com>

Op 14-10-15 om 14:59 schreef Ander Conselvan De Oliveira:
> On Wed, 2015-09-23 at 13:27 +0200, Maarten Lankhorst wrote:
>> atomic->disabled_planes is a hack that had to exist because
>> prepare_fb was only called when a new fb was set. This messed
>> up fb tracking in some circumstances like aborts from
>> interruptible waits. As a result interruptible waiting in
>> prepare_plane_fb was forbidden, but other errors could still
>> cause frontbuffer tracking to be messed up.
>>
>> Now that prepare_fb is always called, this hack is no longer
>> required and prepare_fb may fail without consequences.
>>
>> Changes since v1:
>> - Clean up a few fb tracking warnings by changing plane->fb to
>>   plane->state->fb.
>>
>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>> ---
>>  drivers/gpu/drm/i915/intel_display.c | 47 ++++++++++++++----------------------
>>  drivers/gpu/drm/i915/intel_drv.h     |  1 -
>>  2 files changed, 18 insertions(+), 30 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>> index fc0086748b71..ac97af69be62 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -4752,17 +4752,6 @@ static void intel_pre_plane_update(struct intel_crtc *crtc)
>>  	struct drm_device *dev = crtc->base.dev;
>>  	struct drm_i915_private *dev_priv = dev->dev_private;
>>  	struct intel_crtc_atomic_commit *atomic = &crtc->atomic;
>> -	struct drm_plane *p;
>> -
>> -	/* Track fb's for any planes being disabled */
>> -	drm_for_each_plane_mask(p, dev, atomic->disabled_planes) {
>> -		struct intel_plane *plane = to_intel_plane(p);
>> -
>> -		mutex_lock(&dev->struct_mutex);
>> -		i915_gem_track_fb(intel_fb_obj(plane->base.fb), NULL,
>> -				  plane->frontbuffer_bit);
>> -		mutex_unlock(&dev->struct_mutex);
>> -	}
>>  
>>  	if (atomic->wait_for_flips)
>>  		intel_crtc_wait_for_pending_flips(&crtc->base);
>> @@ -11561,14 +11550,6 @@ int intel_plane_atomic_calc_changes(struct drm_crtc_state *crtc_state,
>>  			return ret;
>>  	}
>>  
>> -	/*
>> -	 * Disabling a plane is always okay; we just need to update
>> -	 * fb tracking in a special way since cleanup_fb() won't
>> -	 * get called by the plane helpers.
>> -	 */
>> -	if (old_plane_state->base.fb && !fb)
>> -		intel_crtc->atomic.disabled_planes |= 1 << i;
>> -
>>  	was_visible = old_plane_state->visible;
>>  	visible = to_intel_plane_state(plane_state)->visible;
>>  
>> @@ -13318,15 +13299,17 @@ intel_prepare_plane_fb(struct drm_plane *plane,
>>  	struct drm_framebuffer *fb = new_state->fb;
>>  	struct intel_plane *intel_plane = to_intel_plane(plane);
>>  	struct drm_i915_gem_object *obj = intel_fb_obj(fb);
>> -	struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb);
>> +	struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->state->fb);
>>  	int ret = 0;
>>  
>> -	if (!obj)
>> +	if (!obj && !old_obj)
>>  		return 0;
>>  
>>  	mutex_lock(&dev->struct_mutex);
>>  
>> -	if (plane->type == DRM_PLANE_TYPE_CURSOR &&
>> +	if (!obj) {
>> +		ret = 0;
>> +	} else if (plane->type == DRM_PLANE_TYPE_CURSOR &&
>>  	    INTEL_INFO(dev)->cursor_needs_physical) {
>>  		int align = IS_I830(dev) ? 16 * 1024 : 256;
>>  		ret = i915_gem_object_attach_phys(obj, align);
>> @@ -13356,17 +13339,23 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
>>  		       const struct drm_plane_state *old_state)
>>  {
>>  	struct drm_device *dev = plane->dev;
>> -	struct drm_i915_gem_object *obj = intel_fb_obj(old_state->fb);
>> +	struct intel_plane *intel_plane = to_intel_plane(plane);
>> +	struct drm_i915_gem_object *old_obj = intel_fb_obj(old_state->fb);
>> +	struct drm_i915_gem_object *obj = intel_fb_obj(plane->state->fb);
>>  
>> -	if (!obj)
>> +	if (!obj && !old_obj)
>>  		return;
>>  
>> -	if (plane->type != DRM_PLANE_TYPE_CURSOR ||
>> -	    !INTEL_INFO(dev)->cursor_needs_physical) {
>> -		mutex_lock(&dev->struct_mutex);
>> +	mutex_lock(&dev->struct_mutex);
>> +	if (old_obj && (plane->type != DRM_PLANE_TYPE_CURSOR ||
>> +	    !INTEL_INFO(dev)->cursor_needs_physical))
>>  		intel_unpin_fb_obj(old_state->fb, old_state);
>> -		mutex_unlock(&dev->struct_mutex);
>> -	}
>> +
>> +	/* prepare_fb aborted? */
>> +	if ((old_obj && (old_obj->frontbuffer_bits & intel_plane->frontbuffer_bit)) ||
>> +	    (obj && !(obj->frontbuffer_bits & intel_plane->frontbuffer_bit)))
>> +		i915_gem_track_fb(old_obj, obj, intel_plane->frontbuffer_bit);
> I'm not a fan of this big condition. Would it make sense to add a new parameter to cleanup_fb() that
> tells us if this is an abort clean up?
>
> But in any case, that can be done later.
>
> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
>
This is only temporarily though. I plan to make unpin async in the future. When that happens cleanup_fb will only be called when aborting so it will become a moot point. :)
We could also add a force flag to i915_gem_track_fb to ignore warnings in cleanup_plane_fb later on.

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

  reply	other threads:[~2015-10-14 13:54 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-23 11:27 [PATCH 0/5] drm/i915: Interruptible framebuffer pinning Maarten Lankhorst
2015-09-23 11:27 ` [PATCH 1/5] drm/i915: Make plane fb tracking work correctly, v2 Maarten Lankhorst
2015-10-14 12:59   ` Ander Conselvan De Oliveira
2015-10-14 13:54     ` Maarten Lankhorst [this message]
2015-09-23 11:27 ` [PATCH 2/5] drm/i915: Make prepare_plane_fb fully interruptible Maarten Lankhorst
2015-10-16 11:21   ` Ander Conselvan De Oliveira
2015-10-19  9:39     ` Daniel Vetter
2015-09-23 11:27 ` [PATCH 3/5] drm/i915: Make wait_for_flips interruptible Maarten Lankhorst
2015-10-19 13:16   ` Ander Conselvan De Oliveira
2015-10-19 13:30     ` Daniel Vetter
2015-10-20  7:38       ` Ander Conselvan De Oliveira
2015-10-20  8:10         ` Daniel Vetter
2015-10-20 13:07           ` Ander Conselvan De Oliveira
2015-10-19 14:38     ` Maarten Lankhorst
2015-10-19 15:09     ` [PATCH 2.9/5] drm/i915: Do not wait for flips in intel_crtc_disable_noatomic Maarten Lankhorst
2015-10-20 12:56       ` Ander Conselvan De Oliveira
2015-10-20 18:33       ` Daniel Vetter
2015-09-23 11:27 ` [PATCH 4/5] drm/i915: Change locking for struct_mutex Maarten Lankhorst
2015-10-28 22:48   ` Matt Roper
2015-11-02 12:57     ` [PATCH v2 4/5] drm/i915: Change locking for struct_mutex, v2 Maarten Lankhorst
2015-11-02 13:06       ` Chris Wilson
2015-11-02 13:55         ` Maarten Lankhorst
2015-09-23 11:27 ` [PATCH 5/5] drm/i915: Wait for object idle without locks in atomic_commit Maarten Lankhorst
2015-10-29  0:30   ` Matt Roper
2015-11-02 13:13     ` Maarten Lankhorst
2015-11-02 13:46       ` Chris Wilson
2015-11-02 13:53         ` Maarten Lankhorst
2015-11-02 13:58           ` 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=561E5E8B.3090405@linux.intel.com \
    --to=maarten.lankhorst@linux.intel.com \
    --cc=conselvan2@gmail.com \
    --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 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.