drm/i915/fbc: Fix fence_y_offset handling
authorVille Syrjälä <ville.syrjala@linux.intel.com>
Wed, 29 Apr 2020 10:10:25 +0000 (13:10 +0300)
committerVille Syrjälä <ville.syrjala@linux.intel.com>
Tue, 30 Jun 2020 17:39:17 +0000 (20:39 +0300)
commit5331889b5ffb11d6257953e418291a9f04c02bed
treeb9bbf665818c23828a5eff6fb3c6a54bfbdcbc84
parentc1b9fd3d310177b31621d5e661f06885869cae12
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>
drivers/gpu/drm/i915/display/intel_display.c
drivers/gpu/drm/i915/display/intel_display.h
drivers/gpu/drm/i915/display/intel_fbc.c
drivers/gpu/drm/i915/i915_drv.h