drm/i915: Fix frontbuffer false positve.
This return 0 without setting atomic bits on fb == crtc->cursor->fb where causing frontbuffer false positives. According to Daniel: The original regression seems to have been introduced in the original check/commit split: commit757f9a3e5b
Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Date: Wed Sep 24 14:20:24 2014 -0300 drm/i915: move check of intel_crtc_cursor_set_obj() out Which already cause other trouble, resulting in the check getting moved in commite391ea882b
Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Date: Wed Sep 24 14:20:25 2014 -0300 drm/i915: Fix not checking cursor and object sizes The frontbuffer tracking itself only was broken when we shifted it into the check/commit logic with: commit32b7eeec4d
Author: Matt Roper <matthew.d.roper@intel.com> Date: Wed Dec 24 07:59:06 2014 -0800 drm/i915: Refactor work that can sleep out of commit (v7) v2: When putting more debug prints I notice the solution was simpler than I thought. AMS design is solid, just this return was wrong. Sorry for the noise. v3: Remove the entire chunck that would probably be removed by gcc anyway. (by Daniel) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
This commit is contained in:
parent
f37b5c2be8
commit
62e537f8d5
@ -12197,9 +12197,6 @@ intel_check_cursor_plane(struct drm_plane *plane,
|
||||
return -ENOMEM;
|
||||
}
|
||||
|
||||
if (fb == crtc->cursor->fb)
|
||||
return 0;
|
||||
|
||||
/* we only need to pin inside GTT if cursor is non-phy */
|
||||
mutex_lock(&dev->struct_mutex);
|
||||
if (!INTEL_INFO(dev)->cursor_needs_physical && obj->tiling_mode) {
|
||||
|
Loading…
Reference in New Issue
Block a user