[Intel-gfx] [PATCH] drm/i915: Clarify the safety of the early unpin of old_fb->obj

[Chris Wilson]

On Tue, May 20, 2014 at 10:16:54AM +0200, Daniel Vetter wrote:
> On Tue, May 20, 2014 at 08:47:41AM +0100, Chris Wilson wrote:
> > Daniel simplified the modesetting code to push the common work performed
> > by each of the architecture specific routines higher into the caller. This
> > took me a while to be sure that it was safe in the event of a
> > modesetting failure - to be sure that the dangling pointer we left in
> > the registers would never be accessed. As it turns out, it is safe, as
> > even after the most convoluted error path, we always rewrite the address
> > registers with the currently pinned object before enabling the planes
> > and pipes. This patch just adds an assertion that the preconditions
> > Daniel stated are correct, and a comment to justify the dance.
> > 
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > Cc: Daniel Vetter <daniel.vetter at ffwll.ch>
> 
> Hm, I think we should tackle the larger issue here and have a bit of a
> plane config checker, to make sure reality matches up with what we expect
> it to be. But I'm not sure that effort is worth it.
> 
> Wrt the assert I actually prefer we keep those in the low-level callbacks.
> At least they often encode platform specifics, which will be more obvious
> once we have atomic modesets support and also need to deal with sprites
> and cursors here.

Here they are testing the preconditions you stated for this code to be
safe. I think they are exactly where they need to be as they serve a
similar but different purpose to the lowlevel checks.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre