[Intel-gfx] [PATCH 5/7] drm/i915: fix FBC buffer size checks

[Zanoni, Paulo R]

Em Qua, 2015-09-23 às 17:59 +0100, Chris Wilson escreveu:
> On Wed, Sep 23, 2015 at 12:52:25PM -0300, Paulo Zanoni wrote:
> > According to my experiments, the maximum sizes mentioned in the
> > specification delimit how far in the buffer the hardware tracking
> > can
> > go. And the hardware seems to calculate the size based on the plane
> > address and x/y offsets we specify to it. So adjust the code to do
> > the
> > proper checks.
> > 
> > On platforms that do the x/y offset adjustment trick it will be
> > really
> > hard to reproduce a bug, but on the current SKL we can reproduce
> > the
> > bug with igt/kms_frontbuffer_tracking/fbc-farfromfence. With this
> > patch, we'll go from "CRC assertion failure" to "FBC unexpectedly
> > disabled", which is still a failure on the test suite but is not a
> > perceived user bug - you will just not save as much power as you
> > could
> > be if FBC is disabled.
> > 
> > Testcase: igt/kms_frontbuffer_tracking/fbc-farfromfence (SKL)
> > Signed-off-by: Paulo Zanoni <paulo.r.zanoni at intel.com>
> 
> Same query again for using src_[wh].

After clarification from the HW guys (which CCd you), I wrote new
versions of these patches.

>  Do we have tests for FBC + panel
> fitting?

The --use-small-modes option forces a 1024x768 mode for eDP, which
triggers the panel fitter in case its native resolution is not
1024x768. This is not the default option, but I run it eventually.

For this specific patch, the real "failure" is when you do a GTT write
and then the hardware tracking doesn't detect it and you end with a CRC
error.

For the other patch that's related with sizes (the CFB size patch) what
we need is a stolen memory checker, like we have for slabs: allocate an
extra page at the exact end of the CFB, write magic bits to it, enable
FBC, check if the magic bits are still there.

> 
> Did I miss some explanation in the code that isn't visible in the
> diffs?
> -Chris
>