Re: [Intel-gfx] [PATCH] drm/i915: check the power wells on assert_{cursor, plane}
On Wed, Jul 16, 2014 at 05:06:34PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Since we merged runtime PM support for DPMS, it is possible that these
functions will be called when the power wells are disabled but a mode
is set, resulting in failed assertion and device suspended while
reading register WARNs.
To reproduce the bug: disable all screens using mode unset, do a
modeset on one screen, disable it using DPMS, then try to do a mode
unset on it again to see the WARNs.
Testcase: igt/rpm_rpm/dpms-mode-unset-lpsp
Testcase: igt/rpm_rpm/dpms-mode-unset-non-lpsp
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Hm, where do we call these asserts while the pipe is off? Do you have some
example backtraces at hand?
-Daniel
---
drivers/gpu/drm/i915/intel_display.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 54e3af9..7ad46e2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1216,7 +1216,9 @@ static void assert_cursor(struct drm_i915_private
*dev_priv,
struct drm_device *dev = dev_priv-dev;
bool cur_state;
- if (IS_845G(dev) || IS_I865G(dev))
+ if (!intel_display_power_enabled(dev_priv, POWER_DOMAIN_PIPE(pipe)))
+ cur_state = false;
+ else if (IS_845G(dev) || IS_I865G(dev))
cur_state = I915_READ(_CURACNTR) CURSOR_ENABLE;
else
cur_state = I915_READ(CURCNTR(pipe)) CURSOR_MODE;
@@ -1262,9 +1264,13 @@ static void assert_plane(struct drm_i915_private
*dev_priv,
u32 val;
bool cur_state;
- reg = DSPCNTR(plane);
- val = I915_READ(reg);
- cur_state = !!(val DISPLAY_PLANE_ENABLE);
+ if (!intel_display_power_enabled(dev_priv, POWER_DOMAIN_PIPE(plane))) {
+ cur_state = false;
+ } else {
+ reg = DSPCNTR(plane);
+ val = I915_READ(reg);
+ cur_state = !!(val DISPLAY_PLANE_ENABLE);
+ }
WARN(cur_state != state,
plane %c assertion failure (expected %s, current %s)\n,
plane_name(plane), state_string(state), state_string(cur_state));
--
2.0.0
___
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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: check the power wells on assert_{cursor, plane}
2014-07-17 5:38 GMT-03:00 Daniel Vetter dan...@ffwll.ch:
On Wed, Jul 16, 2014 at 05:06:34PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Since we merged runtime PM support for DPMS, it is possible that these
functions will be called when the power wells are disabled but a mode
is set, resulting in failed assertion and device suspended while
reading register WARNs.
To reproduce the bug: disable all screens using mode unset, do a
modeset on one screen, disable it using DPMS, then try to do a mode
unset on it again to see the WARNs.
Testcase: igt/rpm_rpm/dpms-mode-unset-lpsp
Testcase: igt/rpm_rpm/dpms-mode-unset-non-lpsp
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Hm, where do we call these asserts while the pipe is off? Do you have some
example backtraces at hand?
Function __intel_set_mode() directly calls intel_crtc_disable(), which
calls both assert_plane_disabled() and assert_cursor_disabled().
-Daniel
---
drivers/gpu/drm/i915/intel_display.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 54e3af9..7ad46e2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1216,7 +1216,9 @@ static void assert_cursor(struct drm_i915_private
*dev_priv,
struct drm_device *dev = dev_priv-dev;
bool cur_state;
- if (IS_845G(dev) || IS_I865G(dev))
+ if (!intel_display_power_enabled(dev_priv, POWER_DOMAIN_PIPE(pipe)))
+ cur_state = false;
+ else if (IS_845G(dev) || IS_I865G(dev))
cur_state = I915_READ(_CURACNTR) CURSOR_ENABLE;
else
cur_state = I915_READ(CURCNTR(pipe)) CURSOR_MODE;
@@ -1262,9 +1264,13 @@ static void assert_plane(struct drm_i915_private
*dev_priv,
u32 val;
bool cur_state;
- reg = DSPCNTR(plane);
- val = I915_READ(reg);
- cur_state = !!(val DISPLAY_PLANE_ENABLE);
+ if (!intel_display_power_enabled(dev_priv, POWER_DOMAIN_PIPE(plane))) {
+ cur_state = false;
+ } else {
+ reg = DSPCNTR(plane);
+ val = I915_READ(reg);
+ cur_state = !!(val DISPLAY_PLANE_ENABLE);
+ }
WARN(cur_state != state,
plane %c assertion failure (expected %s, current %s)\n,
plane_name(plane), state_string(state), state_string(cur_state));
--
2.0.0
___
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
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: check the power wells on assert_{cursor, plane}
On Thu, Jul 17, 2014 at 2:53 PM, Paulo Zanoni przan...@gmail.com wrote: 2014-07-17 5:38 GMT-03:00 Daniel Vetter dan...@ffwll.ch: On Wed, Jul 16, 2014 at 05:06:34PM -0300, Paulo Zanoni wrote: From: Paulo Zanoni paulo.r.zan...@intel.com Since we merged runtime PM support for DPMS, it is possible that these functions will be called when the power wells are disabled but a mode is set, resulting in failed assertion and device suspended while reading register WARNs. To reproduce the bug: disable all screens using mode unset, do a modeset on one screen, disable it using DPMS, then try to do a mode unset on it again to see the WARNs. Testcase: igt/rpm_rpm/dpms-mode-unset-lpsp Testcase: igt/rpm_rpm/dpms-mode-unset-non-lpsp Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com Hm, where do we call these asserts while the pipe is off? Do you have some example backtraces at hand? Function __intel_set_mode() directly calls intel_crtc_disable(), which calls both assert_plane_disabled() and assert_cursor_disabled(). Hm, I think it makes more sense to drop the three asserts in there. The modeset state checker will already notice when we've failed to turn off the pipe. And we check cursors and plane state in the enable sequence, too. Since we use these asserts a lot to lock down the precise modeset sequence I actually prefer if they're a bit dumb and don't check the power wells. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: check the power wells on assert_{cursor, plane}
2014-07-17 10:23 GMT-03:00 Daniel Vetter dan...@ffwll.ch: On Thu, Jul 17, 2014 at 2:53 PM, Paulo Zanoni przan...@gmail.com wrote: 2014-07-17 5:38 GMT-03:00 Daniel Vetter dan...@ffwll.ch: On Wed, Jul 16, 2014 at 05:06:34PM -0300, Paulo Zanoni wrote: From: Paulo Zanoni paulo.r.zan...@intel.com Since we merged runtime PM support for DPMS, it is possible that these functions will be called when the power wells are disabled but a mode is set, resulting in failed assertion and device suspended while reading register WARNs. To reproduce the bug: disable all screens using mode unset, do a modeset on one screen, disable it using DPMS, then try to do a mode unset on it again to see the WARNs. Testcase: igt/rpm_rpm/dpms-mode-unset-lpsp Testcase: igt/rpm_rpm/dpms-mode-unset-non-lpsp Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com Hm, where do we call these asserts while the pipe is off? Do you have some example backtraces at hand? Function __intel_set_mode() directly calls intel_crtc_disable(), which calls both assert_plane_disabled() and assert_cursor_disabled(). Hm, I think it makes more sense to drop the three asserts in there. The modeset state checker will already notice when we've failed to turn off the pipe. And we check cursors and plane state in the enable sequence, too. Since we use these asserts a lot to lock down the precise modeset sequence I actually prefer if they're a bit dumb and don't check the power wells. I can do this, but please notice that we already have power-well-checking code in many of the other assertions on our driver... And it will probably be just a matter of time since someone starts using the assertions again on a place where the power well can be disabled :) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: check the power wells on assert_{cursor, plane}
On Thu, Jul 17, 2014 at 3:29 PM, Paulo Zanoni przan...@gmail.com wrote: I can do this, but please notice that we already have power-well-checking code in many of the other assertions on our driver... And it will probably be just a matter of time since someone starts using the assertions again on a place where the power well can be disabled :) The only one I've found outside of the hw state readout code and error capture code (and there we obviously need them) is in assert_pipe. This was added in 693101618a4be. Tbh I wonder whether we could revert that with the patch to ditch the assert from intel_crtc_disable? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: check the power wells on assert_{cursor, plane}
2014-07-17 13:58 GMT-03:00 Daniel Vetter dan...@ffwll.ch: On Thu, Jul 17, 2014 at 3:29 PM, Paulo Zanoni przan...@gmail.com wrote: I can do this, but please notice that we already have power-well-checking code in many of the other assertions on our driver... And it will probably be just a matter of time since someone starts using the assertions again on a place where the power well can be disabled :) The only one I've found outside of the hw state readout code and error capture code (and there we obviously need them) is in assert_pipe. This was added in 693101618a4be. Tbh I wonder whether we could revert that with the patch to ditch the assert from intel_crtc_disable? I was talking about all that hw state readout code (which are also used as assertions) and basically every single caller of intel_display_power_enabled(). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
