Quoting Ville Syrjala (2017-11-28 15:48:53)
> From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
>
> i830_disable_pipe() gets called from the power well code, and thus
> we're already holding the power domain mutex. That means we can't
> call plane->get_hw_state() as it will also try to grab the
> same mutex and will thus deadlock.
>
> Replace the assert_plane() calls (which calls ->get_hw_state()) with
> just raw register reads in i830_disable_pipe(). As a bonus we can
> now get a warning if plane C is enabled even though we don't even
> expose it as a drm plane.
>
> Fixes: 51f5a0963984 ("drm/i915: Add .get_hw_state() method for planes")
> Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
> ---
> drivers/gpu/drm/i915/intel_display.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index d67c7c498b34..48d9332b196f 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14731,8 +14731,11 @@ void i830_disable_pipe(struct drm_i915_private *dev_priv, enum pipe pipe)
> DRM_DEBUG_KMS("disabling pipe %c due to force quirk\n",
> pipe_name(pipe));
>
> - assert_planes_disabled(intel_get_crtc_for_pipe(dev_priv, PIPE_A));
> - assert_planes_disabled(intel_get_crtc_for_pipe(dev_priv, PIPE_B));
> + WARN_ON(I915_READ(DSPCNTR(PLANE_A)) & DISPLAY_PLANE_ENABLE ||
> + I915_READ(DSPCNTR(PLANE_B)) & DISPLAY_PLANE_ENABLE ||
> + I915_READ(DSPCNTR(PLANE_C)) & DISPLAY_PLANE_ENABLE ||
> + I915_READ(CURCNTR(PIPE_A)) & CURSOR_MODE ||
> + I915_READ(CURCNTR(PIPE_B)) & CURSOR_MODE);
Ok. Avoiding mutex recursion sounds sensible, but a recursion sounds
like a layering violation. i830_disable_pipe is only used by the
powerwell, and I guess you could make the i830_enable_pipe in
i9xx_crtc_disable into a call to the powerdomain instead.
That sounds like more work than desired to fix the immediate problem!
However, I think you will miss the loss in precision by putting all the
checks into one WARN_ON. If it either fires, we've no idea what went
wrong?
Would it be worth just making each of those a separate WARN_ON()? I
think so.
Either way, I've checked that your explanation matches the code...
Reviewed-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
