Re: FBC patchset

[Chris Wilson <chris@chris-wilson.co.uk>]

On Fri, 08 Jul 2011 13:00:09 -0700, Keith Packard <keithp@keithp.com> wrote:
> On Fri, 08 Jul 2011 20:43:47 +0100, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> 
> > Bumping to 250ms sufficiently delays the task to miss the race, but we
> > can not foretell just how long any given crtc modeset will take. So what
> > we need is to take the mode_config.lock in order to prevent concurrent
> > access to the FBC registers and also to prevent the fb from disappearing
> > beneath us:
> 
> Sounds like we also need to push out any FBC reconfiguration anytime
> modesetting occurs to ensure that we've waited past a vblank interval?

During intel_crtc_mode_set() and friends we only call into
intel_update_fbc() which just clears the FBC enabled bit and schedules a
delayed task to do the rest, if required. Fixing the mode_config locking
is sufficient to ensure that by the time the delayed task is run, the
modeset has finished, the pipe is running and at least 50ms, in the
original or 250ms in the update, has past since the final call to
intel_enable_fbc() which is at the end of *_crtc_enable().

If we are going from 2 crtcs to 1 with no swapping of the framebuffer,
then the single crtc that we want to enable FBC on, remains running for
the whole duration and the actual enabling is just deferred by 250ms.

If we are just moving the fb y-offset (e.g. panning the display), then the
pipe will remain running but we disable FBC and wait 250ms before
re-enabling.

So I think it just reduced into being an incorrect locking issue, but
we're still making the assumption that it is safe to touch the FBC just
because X ms have passed. :|
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre