summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/i915_globals.c
diff options
context:
space:
mode:
authorVille Syrjälä <ville.syrjala@linux.intel.com>2020-04-29 13:10:25 +0300
committerRodrigo Vivi <rodrigo.vivi@intel.com>2020-07-06 17:15:57 -0700
commit9eb0463cfe65d826c97fa26b904a64f52c94300d (patch)
treeeea5455477be67c703bce7c85aa33ecc05d04993 /drivers/gpu/drm/i915/i915_globals.c
parent7dfbf8a07cf8c936b0d6cc810df6ae7923954d5b (diff)
downloadlinux-9eb0463cfe65d826c97fa26b904a64f52c94300d.tar.bz2
drm/i915/fbc: Fix fence_y_offset handling
The current fence_y_offset calculation is broken. I think it more or less used to do the right thing, but then I changed the plane code to put the final x/y source offsets back into the src rectangle so now it's just subtraacting the same value from itself. The code would never have worked if we allowed the framebuffer to have a non-zero offset. Let's do this in a better way by just calculating the fence_y_offset from the final plane surface offset. Note that we don't align the plane surface address to fence rows so with horizontal panning there's often a horizontal offset from the fence start to the surface address as well. We have no way to tell the hardware about that so we just ignore it. Based on some quick tests the invlidation still happens correctly. I presume due to the invalidation nuking at least the full line (or a segment of multiple lines). Fixes: 54d4d719fa11 ("drm/i915: Overcome display engine stride limits via GTT remapping") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200429101034.8208-4-ville.syrjala@linux.intel.com Reviewed-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit 5331889b5ffb11d6257953e418291a9f04c02bed) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Diffstat (limited to 'drivers/gpu/drm/i915/i915_globals.c')
0 files changed, 0 insertions, 0 deletions