From: "Zanoni, Paulo R" <paulo.r.zanoni@intel.com>
To: "Pandiyan, Dhinakaran" <dhinakaran.pandiyan@intel.com>,
"chris@chris-wilson.co.uk" <chris@chris-wilson.co.uk>
Cc: "intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"stefanr@s5r6.in-berlin.de" <stefanr@s5r6.in-berlin.de>,
"stevenhoneyman@gmail.com" <stevenhoneyman@gmail.com>
Subject: Re: drm/i915/fbc: disable FBC on FIFO underruns
Date: Mon, 15 Aug 2016 20:49:00 +0000 [thread overview]
Message-ID: <1471294136.5339.10.camel@intel.com> (raw)
In-Reply-To: <20160813090541.GK15011@nuc-i3427.alporthouse.com>
Em Sáb, 2016-08-13 às 10:05 +0100, Chris Wilson escreveu:
> On Fri, Aug 12, 2016 at 11:24:59PM +0000, Pandiyan, Dhinakaran wrote:
> Do we know why we get black screens in this scenario?
I don't know exactly, but I can speculate that it's probably because
the display engine fails to decompress the framebuffer and gets
completely lost on when the data ends, so it gives up and shows black.
> >
> > >
> > > +/**
> > > + * intel_fbc_handle_fifo_underrun - disable FBC when we get a
> > > FIFO underrun
> > > + * @dev_priv: i915 device instance
> > > + *
> > > + * Without FBC, most underruns are harmless and don't really
> > > cause too many
> > > + * problems, except for an annoying message on dmesg. With FBC,
> > > underruns can
> > > + * become black screens or even worse, especially when paired
> > > with bad
> > > + * watermarks. So in order for us to be on the safe side,
> > > completely disable FBC
> > > + * in case we ever detect a FIFO underrun on any pipe. An
> > > underrun on any pipe
> > > + * already suggests that watermarks may be bad, so try to be as
> > > safe as
> > > + * possible.
> > > + */
> > > +void intel_fbc_handle_fifo_underrun(struct drm_i915_private
> > > *dev_priv)
> > > +{
> > > + struct intel_fbc *fbc = &dev_priv->fbc;
> > > +
> > > + if (!fbc_supported(dev_priv))
> > > + return;
> > > +
> >
> > Should we bail out if fbc is not enabled?
No. Even if FBC is disabled or deactivated we need to make sure the
code doesn't decide to enable/activate FBC later, and simply disabling
it now won't prevent it from being reactivated on the next modesets.
> > Also, can we just disable fbc if we see an underrun instead of
> > using a
> > new flag to prevent activation?
No, for the same reason as above: we don't want the code to decide to
enable/activate FBC later.
>
> The information that is crucially absent in the function name, and
> its
> kerneldoc, is that this function is run from hardirq context. There
> isn't
> much you are allowed to do here but schedule work.
You're right. I'll rename the function and improve the doc.
> -Chris
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-08-15 20:49 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-11 1:18 [PATCH] drm/i915/fbc: disable FBC on FIFO underruns Paulo Zanoni
2016-06-11 6:56 ` ✗ Ro.CI.BAT: warning for " Patchwork
2016-06-13 11:47 ` [PATCH] " Stefan Richter
2016-06-13 14:33 ` Zanoni, Paulo R
2016-06-15 12:19 ` Stefan Richter
2016-08-12 23:24 ` Pandiyan, Dhinakaran
2016-08-13 9:05 ` Chris Wilson
2016-08-15 20:49 ` Zanoni, Paulo R [this message]
2016-08-15 22:36 ` [PATCH] " Paulo Zanoni
2016-09-02 5:58 ` Pandiyan, Dhinakaran
2016-09-02 14:45 ` Zanoni, Paulo R
2016-09-12 20:02 ` Paulo Zanoni
2016-09-12 20:25 ` Chris Wilson
2016-09-12 21:25 ` Zanoni, Paulo R
2016-09-13 13:38 ` Paulo Zanoni
2016-09-13 13:56 ` Chris Wilson
2016-09-13 17:07 ` Pandiyan, Dhinakaran
2016-08-16 5:57 ` ✗ Ro.CI.BAT: failure for drm/i915/fbc: disable FBC on FIFO underruns (rev2) Patchwork
2016-09-12 20:54 ` ✓ Fi.CI.BAT: success for drm/i915/fbc: disable FBC on FIFO underruns (rev3) Patchwork
2016-09-13 14:19 ` ✗ Fi.CI.BAT: warning for drm/i915/fbc: disable FBC on FIFO underruns (rev4) Patchwork
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=1471294136.5339.10.camel@intel.com \
--to=paulo.r.zanoni@intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=dhinakaran.pandiyan@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=stefanr@s5r6.in-berlin.de \
--cc=stevenhoneyman@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.