From: Matt Roper <matthew.d.roper@intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 4/4] drm/i915: Clear crtc atomic flags at beginning of transaction
Date: Thu, 9 Apr 2015 08:03:35 -0700 [thread overview]
Message-ID: <20150409150335.GP11603@intel.com> (raw)
In-Reply-To: <20150409124843.GL12038@phenom.ffwll.local>
On Thu, Apr 09, 2015 at 02:48:43PM +0200, Daniel Vetter wrote:
> On Wed, Apr 08, 2015 at 06:56:54PM -0700, Matt Roper wrote:
> > Once we have full atomic modeset, these kind of flags should be in a
> > real intel_crtc_state that's tracked properly. In the meantime, make
> > sure we clear out any old flags at the beginning of a transaction so
> > that we don't wind up seeing leftover flags from old transactions that
> > were checked, but never went to the commit step.
> >
> > A simple memset would have done here, but I expect there to be a few
> > more things that we *don't* want to clear that get added into this
> > structure before we're ready to kill off and roll everything into the
> > CRTC state.
> >
> > Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
>
> Not sure whether this helps a lot with moving intel_crtc->atomic into
> intel_crtc_state. We probably want to just move things one-by-one to
> reduce the overall churn, and then we can add them one-by-one to the intel
> crtc_state_duplicate function.
>
> Or do you have some bigger plans here?
> -Daniel
My in-progress WM work had to stick some other things in
intel_crtc->atomic, but maybe with Ander's latest patch sets we're close
enough that I can rewrite those to use crtc_state instead; I'll have to
go back and check.
Regardless, I think we do still have a bug today where an uncommitted
transaction (e.g., because check or prepare fail) will leave stale flags
in intel_crtc->atomic that the next transaction doesn't realize it needs
to clear. We either need to clear those out (as I'm doing here,
although a simple memset would work too), or we need to transition all
those flags over to CRTC state and kill off the hacky intel_crtc->atomic
structure.
Matt
>
> > ---
> > drivers/gpu/drm/i915/intel_atomic.c | 18 ++++++++++++++++++
> > drivers/gpu/drm/i915/intel_display.c | 2 +-
> > drivers/gpu/drm/i915/intel_drv.h | 1 +
> > 3 files changed, 20 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_atomic.c b/drivers/gpu/drm/i915/intel_atomic.c
> > index 3903b90..542230d 100644
> > --- a/drivers/gpu/drm/i915/intel_atomic.c
> > +++ b/drivers/gpu/drm/i915/intel_atomic.c
> > @@ -35,6 +35,22 @@
> > #include <drm/drm_plane_helper.h>
> > #include "intel_drv.h"
> >
> > +/**
> > + * intel_clear_atomic_crtc_flags
> > + * @crtc: CRTC to clear flags for
> > + *
> > + * Until we have proper atomic handling of CRTC states, we dump some atomic
> > + * task flags in intel_crtc->atomic. Those flags need to be cleared at
> > + * the beginning of each transaction so that we don't carry over stale flags
> > + * from previous transactions.
> > + *
> > + * Note that the whole intel_crtc->atomic structure is a temporary hack and
> > + * should transition into the CRTC state eventually.
> > + */
> > +void intel_clear_atomic_crtc_flags(struct intel_crtc *crtc)
> > +{
> > + memset(&crtc->atomic, 0, sizeof(crtc->atomic));
> > +}
> >
> > /**
> > * intel_atomic_check - validate state object
> > @@ -76,6 +92,8 @@ int intel_atomic_check(struct drm_device *dev,
> > state->allow_modeset = false;
> > for (i = 0; i < ncrtcs; i++) {
> > struct intel_crtc *crtc = to_intel_crtc(state->crtcs[i]);
> > + if (crtc)
> > + intel_clear_atomic_crtc_flags(crtc);
> > if (crtc && crtc->pipe != nuclear_pipe)
> > not_nuclear = true;
> > }
> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> > index 3a74923..bb8d345 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -12812,7 +12812,7 @@ static void intel_finish_crtc_commit(struct drm_crtc *crtc)
> > intel_update_sprite_watermarks(p, crtc, 0, 0, 0,
> > false, false);
> >
> > - memset(&intel_crtc->atomic, 0, sizeof(intel_crtc->atomic));
> > + intel_clear_atomic_crtc_flags(intel_crtc);
> > }
> >
> > /**
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> > index d5ea24f..28d838e 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1303,6 +1303,7 @@ void intel_pre_disable_primary(struct drm_crtc *crtc);
> > void intel_tv_init(struct drm_device *dev);
> >
> > /* intel_atomic.c */
> > +void intel_clear_atomic_crtc_flags(struct intel_crtc *crtc);
> > int intel_atomic_check(struct drm_device *dev,
> > struct drm_atomic_state *state);
> > int intel_atomic_commit(struct drm_device *dev,
> > --
> > 1.8.5.1
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-04-09 15:03 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-09 1:56 [PATCH 0/4] Misc atomic-related updates Matt Roper
2015-04-09 1:56 ` [PATCH 1/4] drm/i915: Make atomic use in-flight state for CRTC active value Matt Roper
2015-04-09 12:42 ` Daniel Vetter
2015-04-09 14:00 ` Matt Roper
2015-04-09 14:45 ` Daniel Vetter
2015-04-09 14:49 ` Matt Roper
2015-04-09 13:18 ` Ville Syrjälä
2015-04-09 14:10 ` Matt Roper
2015-04-09 14:46 ` Ville Syrjälä
2015-04-09 14:54 ` Matt Roper
2015-04-10 7:24 ` Daniel Vetter
2015-04-09 1:56 ` [PATCH 2/4] drm/i915: Lookup CRTC for plane directly Matt Roper
2015-04-09 12:44 ` Daniel Vetter
2015-04-09 14:36 ` Matt Roper
2015-04-09 1:56 ` [PATCH 3/4] drm/i915: Switch to full atomic helpers for plane updates/disable, take two Matt Roper
2015-04-09 12:46 ` Daniel Vetter
2015-04-09 18:03 ` Matt Roper
2015-04-15 0:48 ` Konduru, Chandra
2015-04-09 1:56 ` [PATCH 4/4] drm/i915: Clear crtc atomic flags at beginning of transaction Matt Roper
2015-04-09 12:48 ` Daniel Vetter
2015-04-09 15:03 ` Matt Roper [this message]
2015-04-09 15:51 ` Daniel Vetter
2015-04-09 17:48 ` [PATCH] " Matt Roper
2015-04-10 7:37 ` Daniel Vetter
2015-04-10 20:05 ` shuang.he
2015-04-10 2:36 ` [PATCH 4/4] " shuang.he
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=20150409150335.GP11603@intel.com \
--to=matthew.d.roper@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 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.