drm/i915: fix CFB size calculation
authorPaulo Zanoni <paulo.r.zanoni@intel.com>
Thu, 1 Oct 2015 22:55:57 +0000 (19:55 -0300)
committerDaniel Vetter <daniel.vetter@ffwll.ch>
Fri, 9 Oct 2015 07:35:32 +0000 (09:35 +0200)
commitc4ffd40908c30a33291227920e921f6b45b9e8f7
tree426e242553ede07734db0ff3db3c2f250e7a6651
parenta42e5a23ed1939a8eca5a753c19bb8b0e5cee475
drm/i915: fix CFB size calculation

We were considering the whole framebuffer height, but the spec says we
should only consider the active display height size. There were still
some unclear questions based on the spec, but the hardware guys
clarified them for us. According to them:

- CFB size = CFB stride * Number of lines FBC writes to CFB
- CFB stride = plane stride / compression limit
- Number of lines FBC writes to CFB = MIN(plane source height, maximum
  number of lines FBC writes to CFB)
- Plane source height =
  - pipe source height (PIPE_SRCSZ register) (before SKL)
  - plane size register height (PLANE_SIZE register) (SKL+)
- Maximum number of lines FBC writes to CFB =
  - plane source height (before HSW)
  - 2048 (HSW+)

For the plane source height, I could just have made our code do
I915_READ() in order to be more future proof, but since it's not cool
to do register reads I decided to just recalculate the values we use
when we actually write to those registers.

With this patch, depending on your machine configuration, a lot of the
kms_frontbuffer_tracking subtests that used to result in a SKIP due to
not enough stolen memory still start resulting in a PASS.

v2: Use the clipped src size instead of pipe_src_h (Ville).
v3: Use the appropriate information provided by the hardware guys.
v4: Bikesheds: s/sizes/size/, s/fb_cpp/cpp/ (Ville).
v5: - Don't use crtc->config->pipe_src_x for BDW- (Ville).
    - Fix the register name written in the comment.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drivers/gpu/drm/i915/intel_fbc.c
This page took 0.049101 seconds and 5 git commands to generate.