diff mbox

drm/i915: use the correct obj when preparing the sprite plane

Message ID 1415638050-3168-1-git-send-email-przanoni@gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

Paulo Zanoni Nov. 10, 2014, 4:47 p.m. UTC
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>
---
 drivers/gpu/drm/i915/intel_sprite.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Comments

Ville Syrjälä Nov. 10, 2014, 5:15 p.m. UTC | #1
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
Shuang He Nov. 11, 2014, 8:41 a.m. UTC | #2
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com)
-------------------------------------Summary-------------------------------------
Platform: baseline_drm_intel_nightly_pass_rate->patch_applied_pass_rate
BYT: pass/total=277/348->277/348
PNV: pass/total=323/328->325/328
ILK: pass/total=328/330->330/330
IVB: pass/total=545/546->544/546
SNB: pass/total=558/563->562/563
HSW: pass/total=587/591->590/591
BDW: pass/total=435/435->434/435
-------------------------------------Detailed-------------------------------------
test_platform: test_suite, test_case, result_with_drm_intel_nightly(count, machine_id...)...->result_with_patch_applied(count, machine_id)...
PNV: Intel_gpu_tools, igt_gem_mmap_offset_exhaustion, DMESG_WARN(2, M23M24)PASS(14, M24M23M7) -> PASS(4, M7)
PNV: Intel_gpu_tools, igt_gem_unref_active_buffers, DMESG_WARN(2, M23)PASS(14, M24M23M7) -> PASS(4, M7)
ILK: Intel_gpu_tools, igt_kms_render_gpu-blit, DMESG_WARN(1, M26)PASS(15, M6M26M37) -> PASS(4, M6)
ILK: Intel_gpu_tools, igt_kms_flip_wf_vblank-vs-dpms-interruptible, DMESG_WARN(1, M26)PASS(15, M6M26M37) -> PASS(4, M6)
IVB: Intel_gpu_tools, igt_gem_bad_reloc_negative-reloc, NSPT(5, M4M34)PASS(11, M34M4) -> NSPT(2, M4)PASS(2, M4)
IVB: Intel_gpu_tools, igt_kms_plane_plane-position-covered-pipe-A-plane-1, TIMEOUT(1, M34)PASS(9, M4) -> PASS(4, M4)
IVB: Intel_gpu_tools, igt_kms_flip_absolute-wf_vblank-interruptible, PASS(4, M34M4) -> DMESG_WARN(1, M4)PASS(3, M4)
SNB: Intel_gpu_tools, igt_kms_cursor_crc_cursor-256x256-sliding, DMESG_WARN(3, M35M22)PASS(7, M22M35) -> PASS(4, M35)
SNB: Intel_gpu_tools, igt_kms_plane_plane-panning-top-left-pipe-A-plane-1, PASS(1, M35) -> FAIL(1, M35)PASS(3, M35)
SNB: Intel_gpu_tools, igt_pm_rpm_legacy-planes, TIMEOUT(1, M35) -> TIMEOUT(3, M35)PASS(1, M35)
SNB: Intel_gpu_tools, igt_pm_rpm_legacy-planes-dpms, TIMEOUT(1, M35) -> TIMEOUT(3, M35)PASS(1, M35)
SNB: Intel_gpu_tools, igt_pm_rpm_universal-planes, TIMEOUT(1, M35) -> TIMEOUT(2, M35)PASS(1, M35)
SNB: Intel_gpu_tools, igt_pm_rpm_universal-planes-dpms, TIMEOUT(1, M35) -> PASS(1, M35)
HSW: Intel_gpu_tools, igt_gem_bad_reloc_negative-reloc, NSPT(4, M39M20M40)PASS(9, M40M39M20) -> NSPT(2, M19)PASS(2, M19)
HSW: Intel_gpu_tools, igt_pm_rpm_legacy-planes, TIMEOUT(1, M40) -> TIMEOUT(3, M19)PASS(1, M19)
HSW: Intel_gpu_tools, igt_pm_rpm_legacy-planes-dpms, TIMEOUT(1, M40) -> TIMEOUT(3, M19)PASS(1, M19)
HSW: Intel_gpu_tools, igt_pm_rpm_universal-planes, TIMEOUT(1, M40) -> TIMEOUT(2, M19)PASS(1, M19)
HSW: Intel_gpu_tools, igt_pm_rpm_universal-planes-dpms, TIMEOUT(1, M40) -> PASS(1, M19)
BDW: Intel_gpu_tools, igt_gem_reset_stats_ban-bsd, PASS(16, M30M28M42) -> DMESG_WARN(1, M30)PASS(3, M30)
Daniel Vetter Nov. 11, 2014, 9:30 a.m. UTC | #3
On Mon, Nov 10, 2014 at 07:15:04PM +0200, Ville Syrjälä wrote:
> 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.

Hm, I've thought that thus far we've kept the buffer pinned when the crtc
is enabled (irrespective or crtc state). And when the crtc gets disabled
we dropped the buffers. Then planes happened and everything got messy.

Actually I'm not really sure what the right semantics are here - in the
atomic helpers I don't disable planes/framebuffers. Which is consistent
with the legacy plane interface, but not consistent with the legacy
setCrtc ioctl.

Anyone has a good idea how to handle all this properly?
-Daniel
Daniel Vetter Nov. 11, 2014, 9:31 a.m. UTC | #4
On Mon, Nov 10, 2014 at 07:15:04PM +0200, Ville Syrjälä wrote:
> 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>

Queued for -next, thanks for the patch.
-Daniel
Ville Syrjälä Nov. 12, 2014, 11:49 a.m. UTC | #5
On Tue, Nov 11, 2014 at 10:30:57AM +0100, Daniel Vetter wrote:
> On Mon, Nov 10, 2014 at 07:15:04PM +0200, Ville Syrjälä wrote:
> > 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.
> 
> Hm, I've thought that thus far we've kept the buffer pinned when the crtc
> is enabled (irrespective or crtc state). And when the crtc gets disabled
> we dropped the buffers. Then planes happened and everything got messy.
> 
> Actually I'm not really sure what the right semantics are here - in the
> atomic helpers I don't disable planes/framebuffers. Which is consistent
> with the legacy plane interface, but not consistent with the legacy
> setCrtc ioctl.
> 
> Anyone has a good idea how to handle all this properly?

Well I think we should avoid the "change in property X changes
property Y" problem. That means leaving the plane->fb alone when the
crtc is disabled.

But as as far as the pinning goes, my original idea was that we keep
things pinned as long as plane->fb is set, whether the plane is
invisible or crtc disabled. The idea was you could set up all the planes
in advance, and then enable the crtc and it would at least not fail due
to failure to pin the buffers.

But that is rather wasteful and might prevent defragmenting the address
space. So I suppose we should just change things so that at least we
don't keep the buffers pinned when the crtc is disabled. And perhaps
we should just go all the way and not pin when the plane is invisible,
for any reason.
Daniel Vetter Nov. 12, 2014, 2:22 p.m. UTC | #6
On Wed, Nov 12, 2014 at 01:49:47PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 11, 2014 at 10:30:57AM +0100, Daniel Vetter wrote:
> > On Mon, Nov 10, 2014 at 07:15:04PM +0200, Ville Syrjälä wrote:
> > > 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.
> > 
> > Hm, I've thought that thus far we've kept the buffer pinned when the crtc
> > is enabled (irrespective or crtc state). And when the crtc gets disabled
> > we dropped the buffers. Then planes happened and everything got messy.
> > 
> > Actually I'm not really sure what the right semantics are here - in the
> > atomic helpers I don't disable planes/framebuffers. Which is consistent
> > with the legacy plane interface, but not consistent with the legacy
> > setCrtc ioctl.
> > 
> > Anyone has a good idea how to handle all this properly?
> 
> Well I think we should avoid the "change in property X changes
> property Y" problem. That means leaving the plane->fb alone when the
> crtc is disabled.
> 
> But as as far as the pinning goes, my original idea was that we keep
> things pinned as long as plane->fb is set, whether the plane is
> invisible or crtc disabled. The idea was you could set up all the planes
> in advance, and then enable the crtc and it would at least not fail due
> to failure to pin the buffers.
> 
> But that is rather wasteful and might prevent defragmenting the address
> space. So I suppose we should just change things so that at least we
> don't keep the buffers pinned when the crtc is disabled. And perhaps
> we should just go all the way and not pin when the plane is invisible,
> for any reason.

The problem is a bit that the legacy setCrtc does free the buffer, and
userspace might rely on that. So if we decide to keep the plane fb around
when the crtc is disabled we need to at least update the set_config atomic
helper function to release the fb of the primary plane and unlink/disable
the primary plane.
-Daniel
Ville Syrjälä Nov. 12, 2014, 2:45 p.m. UTC | #7
On Wed, Nov 12, 2014 at 03:22:07PM +0100, Daniel Vetter wrote:
> On Wed, Nov 12, 2014 at 01:49:47PM +0200, Ville Syrjälä wrote:
> > On Tue, Nov 11, 2014 at 10:30:57AM +0100, Daniel Vetter wrote:
> > > On Mon, Nov 10, 2014 at 07:15:04PM +0200, Ville Syrjälä wrote:
> > > > 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.
> > > 
> > > Hm, I've thought that thus far we've kept the buffer pinned when the crtc
> > > is enabled (irrespective or crtc state). And when the crtc gets disabled
> > > we dropped the buffers. Then planes happened and everything got messy.
> > > 
> > > Actually I'm not really sure what the right semantics are here - in the
> > > atomic helpers I don't disable planes/framebuffers. Which is consistent
> > > with the legacy plane interface, but not consistent with the legacy
> > > setCrtc ioctl.
> > > 
> > > Anyone has a good idea how to handle all this properly?
> > 
> > Well I think we should avoid the "change in property X changes
> > property Y" problem. That means leaving the plane->fb alone when the
> > crtc is disabled.
> > 
> > But as as far as the pinning goes, my original idea was that we keep
> > things pinned as long as plane->fb is set, whether the plane is
> > invisible or crtc disabled. The idea was you could set up all the planes
> > in advance, and then enable the crtc and it would at least not fail due
> > to failure to pin the buffers.
> > 
> > But that is rather wasteful and might prevent defragmenting the address
> > space. So I suppose we should just change things so that at least we
> > don't keep the buffers pinned when the crtc is disabled. And perhaps
> > we should just go all the way and not pin when the plane is invisible,
> > for any reason.
> 
> The problem is a bit that the legacy setCrtc does free the buffer, and
> userspace might rely on that. So if we decide to keep the plane fb around
> when the crtc is disabled we need to at least update the set_config atomic
> helper function to release the fb of the primary plane and unlink/disable
> the primary plane.

Sounds reasonable. At least I'd prefer if we can keep such uglies neatly
tucked away in their own legacy corner, and not let them spread into the
general population.
diff mbox

Patch

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;