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: Mon, 10 Nov 2014 19:15:04 +0200 [thread overview]
Message-ID: <20141110171504.GB10649@intel.com> (raw)
In-Reply-To: <1415638050-3168-1-git-send-email-przanoni@gmail.com>
On Mon, Nov 10, 2014 at 02:47:30PM -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. Later, commit
> "drm/i915: use intel_fb_obj() macros to assign gem objects" introduced
> the same problem to function intel_commit_sprite_plane().
>
> 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
> and:
> commit 77cde95217484e845743818691df026cec2534f4
> Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> Date: Fri Oct 24 14:51:33 2014 +0100
> drm/i915: use intel_fb_obj() macros to assign gem objects
>
> Credits to Imre Deak for pointing out the exact lines that were wrong.
>
> v2: Also fix intel_commit_sprite_plane() (Ville)
>
> 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>
Yep, I believe that should do it.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
As a side note if someone is looking for stuff to do, then the pin/unpin
logic might be good thing to look at. We're currently a bit inconsistent
whether we have the buffer pinned when the plane is disabled, or just
otherwise invisible, or when the crtc itself is disabled. And I guess
cooking up some tests to poke at planes with disabled crtcs might be in
order too, as well as all kinds of variations on the
crtc_enable->plane_enable->crtc_disable->plane_disable theme.
> ---
> drivers/gpu/drm/i915/intel_sprite.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c
> index 64076555..7d9c340 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -1264,10 +1264,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;
> int ret;
>
> if (old_obj != obj) {
> @@ -1302,7 +1303,7 @@ intel_commit_sprite_plane(struct drm_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;
> int crtc_x, crtc_y;
> unsigned int crtc_w, crtc_h;
> uint32_t src_x, src_y, src_w, src_h;
> --
> 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
next prev parent reply other threads:[~2014-11-10 17:15 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ä
2014-10-30 19:33 ` Paulo Zanoni
2014-11-10 16:47 ` Paulo Zanoni
2014-11-10 17:15 ` Ville Syrjälä [this message]
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=20141110171504.GB10649@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.