All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Paulo Zanoni <przanoni@gmail.com>
Cc: intel-gfx@lists.freedesktop.org,
	Gustavo Padovan <gustavo.padovan@collabora.co.uk>,
	Paulo Zanoni <paulo.r.zanoni@intel.com>
Subject: Re: [PATCH] drm/i915: use the correct obj when preparing the sprite plane
Date: Thu, 30 Oct 2014 21:10:03 +0200	[thread overview]
Message-ID: <20141030191003.GU10649@intel.com> (raw)
In-Reply-To: <1414692121-13150-1-git-send-email-przanoni@gmail.com>

On Thu, Oct 30, 2014 at 04:02:01PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni <paulo.r.zanoni@intel.com>
> 
> Commit "drm/i915: create a prepare phase for sprite plane updates"
> changed the old_obj pointer we use when committing sprite planes,
> which caused a WARN() and a BUG() to be triggered. This patch should
> revert the code back to the previous behavior, fixing the regression.
> 
> Regression introduced by:
>     commit ec82cb793c9224e0692eed904f43490cf70e8258
>     Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
>     Date:   Fri Oct 24 14:51:32 2014 +0100
>         drm/i915: create a prepare phase for sprite plane updates
> 
> Credits to Imre Deak for pointing out the exact lines that were wrong.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85634
> Testcase: igt/pm_rpm/legacy-planes
> Testcase: igt/pm_rpm/legacy-planes-dpms
> Testcase: igt/pm_rpm/universal-planes
> Testcase: igt/pm_rpm/universal-planes-dpms
> Credits-to: Imre Deak <imre.deak@intel.com>
> Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_sprite.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c
> index 8b80d68..1c874309 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -1197,10 +1197,11 @@ intel_prepare_sprite_plane(struct drm_plane *plane,
>  	struct drm_device *dev = plane->dev;
>  	struct drm_crtc *crtc = state->crtc;
>  	struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> +	struct intel_plane *intel_plane = to_intel_plane(plane);
>  	enum pipe pipe = intel_crtc->pipe;
>  	struct drm_framebuffer *fb = state->fb;
>  	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_plane->obj;

You need to change intel_commit_sprite_plane() too. Othwerwise something
like this could happen:

1. .update_plane(fb=A)
   // note plane->fb=NULL here
   -> prepare() -> pin(A) -> obj=A
   -> commit() -> nop
   ...
   plane->fb=A

2. .crtc_disable()
   -> disable() -> unpin(A) -> obj=NULL

3. .update_plane(fb=B)
   // note plane->fb=A here still
   -> prepare() -> pin(B)
   -> commit() -> unpin(A) -> obj=B
   ...
   plane->fb=B

So we still get the double unpin of A.

I take it our basic plane tests didn't catch this?

>  	int ret;
>  
>  	if (old_obj != obj) {
> -- 
> 2.1.1

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2014-10-30 19:10 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-24 13:51 [PATCH v4 1/5] drm/i915: create a prepare step for primary planes updates Gustavo Padovan
2014-10-24 13:51 ` [PATCH v4 2/5] drm/i915: create a prepare phase for sprite plane updates Gustavo Padovan
2014-10-30 13:32   ` Paulo Zanoni
2014-10-30 14:08     ` [Intel-gfx] " Imre Deak
2014-10-30 14:34     ` Ville Syrjälä
2014-10-30 18:02       ` [PATCH] drm/i915: use the correct obj when preparing the sprite plane Paulo Zanoni
2014-10-30 19:10         ` Ville Syrjälä [this message]
2014-10-30 19:33           ` Paulo Zanoni
2014-11-10 16:47           ` Paulo Zanoni
2014-11-10 17:15             ` Ville Syrjälä
2014-11-11  9:30               ` How to handle planes/fbs when disabling the crtc? (was Re: [Intel-gfx] [PATCH] drm/i915: use the correct obj when preparing the sprite plane) Daniel Vetter
2014-11-12 11:49                 ` Ville Syrjälä
2014-11-12 14:22                   ` How to handle planes/fbs when disabling the crtc? (was " Daniel Vetter
2014-11-12 14:45                     ` Ville Syrjälä
2014-11-11  9:31               ` [PATCH] drm/i915: use the correct obj when preparing the sprite plane Daniel Vetter
2014-11-11  8:41             ` [PATCH] drm/i915: use the correct obj when preparing shuang.he
2014-10-24 13:51 ` [PATCH v4 3/5] drm/i915: use intel_fb_obj() macros to assign gem objects Gustavo Padovan
2014-10-24 13:51 ` [PATCH v4 4/5] drm/i915: only flip frontbuffer if crtc is active Gustavo Padovan
2014-10-24 15:07   ` Ville Syrjälä
2014-10-27  9:10     ` Daniel Vetter
2014-10-24 13:51 ` [PATCH v4 5/5] drm/i915: remove intel_crtc_cursor_set_obj() Gustavo Padovan
2014-10-24 15:16   ` Ville Syrjälä
2014-10-28 12:02     ` Gustavo Padovan
2014-10-28 12:35   ` [Intel-gfx] " 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=20141030191003.GU10649@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=gustavo.padovan@collabora.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=paulo.r.zanoni@intel.com \
    --cc=przanoni@gmail.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 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.