From: Paulo Zanoni <paulo.r.zanoni@intel.com>
To: Manasi Navare <manasi.d.navare@intel.com>,
Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Cc: daniel.vetter@intel.com, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH RESEND] drm: i915: Preserve old FBC status for update without new planes
Date: Mon, 05 Jun 2017 16:46:26 -0300 [thread overview]
Message-ID: <1496691986.2727.3.camel@intel.com> (raw)
In-Reply-To: <20170601230952.GA26925@intel.com>
Em Qui, 2017-06-01 às 16:09 -0700, Manasi Navare escreveu:
> The modified commit message looks good to me.
>
> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
As a longer term plan we could try to think some way to reduce the
complexity between the Kernel and IGT interaction here: maybe there's a
way to make things work without having to preserve no_fbc_reason
between multiple commits. But I don't have any specific ideas, so
suggestions are welcome.
>
> On Thu, Jun 01, 2017 at 12:36:08PM -0300, Gabriel Krisman Bertazi
> wrote:
> > If the atomic commit doesn't include any new plane, there is no
> > need to
> > choose a new CRTC for FBC, and the intel_fbc_choose_crtc() will
> > bail out
> > early. Although, if the FBC setup failed in the previous commit,
> > if the
> > current commit doesn't include new plane update, it tries to
> > overwrite
> > no_fbc_reason to "no suitable CRTC for FBC". For that scenario, it
> > is
> > better that we simply keep the old message in-place to make
> > debugging
> > easier.
> >
> > A scenario where this happens is with the
> > igt@kms_frontbuffer_tracking@fbc-suspend testcase when executed on
> > a
> > Haswell system with not enough stolen memory. When enabling the
> > CRTC,
> > the FBC setup will be correctly initialized to a specific CRTC, but
> > won't be enabled, since there is not enough memory. The testcase
> > will
> > then enable CRC checking, which requires a quirk for Haswell, which
> > issues a new atomic commit that doesn't update the planes. Since
> > that
> > update doesn't include any new planes (and the FBC wasn't enabled),
> > intel_fbc_choose_crtc() will not find any suitable CRTC, but update
> > the
> > error message, hiding the lack of memory information, which is the
> > actual cause of the initialization failure. As a result, this
> > causes
> > that test, which should skip, to fail on Haswell.
> >
> > Changes since v1:
> > - Update commit message (Manasi)
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100020
> > Fixes: f7e9b004b8a3 ("drm/i915/fbc: inline intel_fbc_can_choose()")
> > Reported-by: Dorota Czaplejewicz <dorota.czaplejewicz@collabora.co.
> > uk>
> > Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
> > Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > ---
> > drivers/gpu/drm/i915/intel_fbc.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> > b/drivers/gpu/drm/i915/intel_fbc.c
> > index ded2add18b26..0c99c9b731ee 100644
> > --- a/drivers/gpu/drm/i915/intel_fbc.c
> > +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > @@ -1045,6 +1045,7 @@ void intel_fbc_choose_crtc(struct
> > drm_i915_private *dev_priv,
> > struct drm_plane *plane;
> > struct drm_plane_state *plane_state;
> > bool crtc_chosen = false;
> > + bool new_planes = false;
> > int i;
> >
> > mutex_lock(&fbc->lock);
> > @@ -1066,6 +1067,7 @@ void intel_fbc_choose_crtc(struct
> > drm_i915_private *dev_priv,
> > to_intel_plane_state(plane_state);
> > struct intel_crtc_state *intel_crtc_state;
> > struct intel_crtc *crtc =
> > to_intel_crtc(plane_state->crtc);
> > + new_planes = true;
> >
> > if (!intel_plane_state->base.visible)
> > continue;
> > @@ -1084,7 +1086,7 @@ void intel_fbc_choose_crtc(struct
> > drm_i915_private *dev_priv,
> > break;
> > }
> >
> > - if (!crtc_chosen)
> > + if (new_planes && !crtc_chosen)
> > fbc->no_fbc_reason = "no suitable CRTC for FBC";
> >
> > out:
> > --
> > 2.11.0
> >
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2017-06-05 19:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-01 15:36 [PATCH RESEND] drm: i915: Preserve old FBC status for update without new planes Gabriel Krisman Bertazi
2017-06-01 15:54 ` ✓ Fi.CI.BAT: success for drm: i915: Preserve old FBC status for update without new planes (rev2) Patchwork
2017-06-01 23:09 ` [PATCH RESEND] drm: i915: Preserve old FBC status for update without new planes Manasi Navare
2017-06-05 19:46 ` Paulo Zanoni [this message]
2017-06-09 19:24 ` Chris Wilson
2017-06-09 19:40 ` Ville Syrjälä
2017-06-09 19:53 ` Paulo Zanoni
2017-06-09 22:20 ` Gabriel Krisman Bertazi
2017-06-09 19:40 ` Paulo Zanoni
2017-06-09 22:09 ` Gabriel Krisman Bertazi
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=1496691986.2727.3.camel@intel.com \
--to=paulo.r.zanoni@intel.com \
--cc=daniel.vetter@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=krisman@collabora.co.uk \
--cc=manasi.d.navare@intel.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.