From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 9/9] drm/i915: Don't re-enable an explicitly disabled primary plane due to sprite coverage changes
Date: Wed, 11 Mar 2015 12:09:24 +0200 [thread overview]
Message-ID: <20150311100924.GP11371@intel.com> (raw)
In-Reply-To: <20150311100032.GC3800@phenom.ffwll.local>
On Wed, Mar 11, 2015 at 11:00:32AM +0100, Daniel Vetter wrote:
> On Tue, Mar 10, 2015 at 01:15:29PM +0200, ville.syrjala@linux.intel.com wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > When the sprite is covering the entire pipe (and color keying is not
> > enabled) we currently try to automagically disable the primary plane
> > which is fully covered by the sprite.
> >
> > Now that .crtc_disable() will simply disable planes by setting the
> > state->visible to false, the sprite code will actually end up
> > re-enabling the primary after it got disabled, and then we proceed to
> > turn off the pipe and are greeted with some warnings from
> > assert_plane_disabled().
> >
> > The code doing the automagic disable of covered planes needs to
> > rewritten to do things correctly as part of the atomic update (or simply
> > removed), but in the meantime add a a bit of duct tape and simply have
> > the sprite code check the primary plane's state->visible before
> > re-enabling it.
> >
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> > drivers/gpu/drm/i915/intel_sprite.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c
> > index a828736..7286497 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -1287,7 +1287,9 @@ intel_commit_sprite_plane(struct drm_plane *plane,
> > intel_plane->obj = obj;
> >
> > if (intel_crtc->active) {
> > - intel_crtc->primary_enabled = !state->hides_primary;
> > + intel_crtc->primary_enabled =
> > + to_intel_plane_state(crtc->primary->state)->visible &&
> > + !state->hides_primary;
>
> Can't we just nuke intel_crtc->primary_enabled with all your work to tread
> state through functions correctly?
Not if we want to keep this magic "disable primary when sprite covers
it" code.
I think ideally we'd do the .atomic_check() for all planes, and then
once all planes are clipped and whatnot, we could check which planes
are fully covered by something opaque and make them invisible. Though
that would perhaps mean that we always have to .atomic_check() all the
planes even if only one of them changed.
> -Daniel
>
> >
> > if (state->visible) {
> > crtc_x = state->dst.x1;
> > --
> > 2.0.5
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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:[~2015-03-11 10:09 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-10 11:15 [PATCH 0/9] drm/i915: Update derived plane state at crtc enable/disable ville.syrjala
2015-03-10 11:15 ` [PATCH 1/9] drm/i915: Remove debug prints from primary plane update funcs ville.syrjala
2015-03-10 15:55 ` Jesse Barnes
2015-03-10 11:15 ` [PATCH 2/9] drm/i915: Reduce clutter by using the local plane pointer ville.syrjala
2015-03-10 16:00 ` Jesse Barnes
2015-03-10 11:15 ` [PATCH 3/9] drm/i915: Use plane->state->fb instead of plane->fb in intel_plane_restore() ville.syrjala
2015-03-10 17:01 ` Matt Roper
2015-03-10 17:48 ` Ville Syrjälä
2015-03-11 9:41 ` Daniel Vetter
2015-03-11 10:04 ` Daniel Vetter
2015-03-10 11:15 ` [PATCH 4/9] drm/i915: Make derived plane state correct after crtc_enable ville.syrjala
2015-03-10 17:01 ` Matt Roper
2015-03-10 17:57 ` Ville Syrjälä
2015-03-11 9:52 ` Daniel Vetter
2015-03-11 10:03 ` Daniel Vetter
2015-03-11 10:05 ` Ville Syrjälä
2015-03-11 10:24 ` Daniel Vetter
2015-03-11 12:19 ` Ville Syrjälä
2015-03-11 16:23 ` Daniel Vetter
2015-03-11 16:40 ` Ville Syrjälä
2015-03-10 11:15 ` [PATCH 5/9] drm/i915: Pass primary plane size to .update_primary_plane() ville.syrjala
2015-03-10 17:10 ` Matt Roper
2015-03-10 17:59 ` Ville Syrjälä
2015-03-10 20:57 ` Matt Roper
2015-03-11 9:42 ` Ville Syrjälä
2015-03-11 9:57 ` Daniel Vetter
2015-03-11 5:09 ` sonika
2015-03-11 9:27 ` Ville Syrjälä
2015-03-11 9:26 ` sonika
2015-03-19 14:28 ` [PATCH v2 " ville.syrjala
2015-03-20 9:49 ` Jindal, Sonika
2015-03-20 10:04 ` Ville Syrjälä
2015-03-20 10:53 ` Jindal, Sonika
2015-03-20 14:26 ` Ville Syrjälä
2015-03-23 4:11 ` sonika
2015-03-10 11:15 ` [PATCH 6/9] drm/i915: Pass the primary plane position " ville.syrjala
2015-03-19 14:29 ` [PATCH v2 " ville.syrjala
2015-03-20 11:22 ` Jindal, Sonika
2015-03-10 11:15 ` [PATCH 7/9] drm/i915: Update watermarks after the derived plane state is uptodate ville.syrjala
2015-03-10 17:13 ` Matt Roper
2015-03-11 9:59 ` Daniel Vetter
2015-03-10 11:15 ` [PATCH 8/9] drm/i915: Use state->visible in wm calculation ville.syrjala
2015-03-10 17:19 ` Matt Roper
2015-03-10 18:01 ` Ville Syrjälä
2015-03-19 14:31 ` [PATCH v2 " ville.syrjala
2015-03-10 11:15 ` [PATCH 9/9] drm/i915: Don't re-enable an explicitly disabled primary plane due to sprite coverage changes ville.syrjala
2015-03-10 17:58 ` shuang.he
2015-03-11 10:00 ` Daniel Vetter
2015-03-11 10:09 ` Ville Syrjälä [this message]
2015-03-11 10:28 ` Daniel Vetter
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=20150311100924.GP11371@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=daniel@ffwll.ch \
--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