Message ID | 1446664257-32012-8-git-send-email-paulo.r.zanoni@intel.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Wed, Nov 04, 2015 at 05:10:51PM -0200, Paulo Zanoni wrote: > If FBC is disabled we will still call intel_fbc_invalidate(), and as a > result we may call intel_fbc_deactivate(), which will try to touch > registers. > > I'm pretty sure I saw this happen on a runtime suspended device, and This is one of the BAT failures we have. I don't really understand why we track the frontbuffer bits with FBC totally disabled, but this fix seems simple enough on its own. Not sure if it applies without the others, but if it doesn't I suggest trying to reorder the patchset so we can put this in ASAP. > I'm almost sure I was running igt/pm_rpm. It produced the "you touched > registers while the device is suspended" WARNs. But this was some time > ago and I can't remember exactly which conditions were necessary to > reproduce the problem. > > v2: Rebase to new series order. > > Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> > --- > drivers/gpu/drm/i915/intel_fbc.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c > index dfb8657..5a853c6 100644 > --- a/drivers/gpu/drm/i915/intel_fbc.c > +++ b/drivers/gpu/drm/i915/intel_fbc.c > @@ -438,7 +438,8 @@ static void __intel_fbc_disable(struct drm_i915_private *dev_priv) > > intel_fbc_cancel_work(dev_priv); > > - dev_priv->fbc.disable_fbc(dev_priv); > + if (dev_priv->fbc.enabled) > + dev_priv->fbc.disable_fbc(dev_priv); > dev_priv->fbc.crtc = NULL; > } > > -- > 2.6.1 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Hey, Op 05-11-15 om 12:29 schreef Ville Syrjälä: > On Wed, Nov 04, 2015 at 05:10:51PM -0200, Paulo Zanoni wrote: >> If FBC is disabled we will still call intel_fbc_invalidate(), and as a >> result we may call intel_fbc_deactivate(), which will try to touch >> registers. >> >> I'm pretty sure I saw this happen on a runtime suspended device, and > This is one of the BAT failures we have. I don't really understand why > we track the frontbuffer bits with FBC totally disabled, but this fix > seems simple enough on its own. Not sure if it applies without the > others, but if it doesn't I suggest trying to reorder the patchset so > we can put this in ASAP. > For the commit message what BAT is affected? ~Maarten
On Thu, Nov 05, 2015 at 03:52:31PM +0100, Maarten Lankhorst wrote: > Hey, > > Op 05-11-15 om 12:29 schreef Ville Syrjälä: > > On Wed, Nov 04, 2015 at 05:10:51PM -0200, Paulo Zanoni wrote: > >> If FBC is disabled we will still call intel_fbc_invalidate(), and as a > >> result we may call intel_fbc_deactivate(), which will try to touch > >> registers. > >> > >> I'm pretty sure I saw this happen on a runtime suspended device, and > > This is one of the BAT failures we have. I don't really understand why > > we track the frontbuffer bits with FBC totally disabled, but this fix > > seems simple enough on its own. Not sure if it applies without the > > others, but if it doesn't I suggest trying to reorder the patchset so > > we can put this in ASAP. > > > For the commit message what BAT is affected? /me looks pm_rpm@basic-rte at least.
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c index dfb8657..5a853c6 100644 --- a/drivers/gpu/drm/i915/intel_fbc.c +++ b/drivers/gpu/drm/i915/intel_fbc.c @@ -438,7 +438,8 @@ static void __intel_fbc_disable(struct drm_i915_private *dev_priv) intel_fbc_cancel_work(dev_priv); - dev_priv->fbc.disable_fbc(dev_priv); + if (dev_priv->fbc.enabled) + dev_priv->fbc.disable_fbc(dev_priv); dev_priv->fbc.crtc = NULL; }
If FBC is disabled we will still call intel_fbc_invalidate(), and as a result we may call intel_fbc_deactivate(), which will try to touch registers. I'm pretty sure I saw this happen on a runtime suspended device, and I'm almost sure I was running igt/pm_rpm. It produced the "you touched registers while the device is suspended" WARNs. But this was some time ago and I can't remember exactly which conditions were necessary to reproduce the problem. v2: Rebase to new series order. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> --- drivers/gpu/drm/i915/intel_fbc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)