Re: [PATCH] drm: Handle atomic state properly in kms getfoo ioctl

[Daniel Vetter <daniel@ffwll.ch>]

On Wed, Nov 26, 2014 at 10:52:24AM -0500, Sean Paul wrote:
> On Tue, Nov 25, 2014 at 5:50 PM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > So the problem with async commit (especially async modeset commit) is
> > that the legacy pointers only get updated after the point of no
> > return, in the async part of the modeset sequence. At least as
> > implemented by the current helper functions. This is done in the
> > set_routing_links function in drm_atomic_helper.c.
> >
> > Which also means that access isn't protected by locks but only
> > coordinated by synchronizing with async workers. No problem thus far,
> > until we lock at the getconnector/encoder ioctls.
> >
> > So fix this up by adding special cases for atomic drivers: For those
> > we need to look at state objects. Unfortunately digging out the
> > correct encoder->crtc link is a bit of work, so wrap this up in a
> > helper function.
> >
> > Moving the assignments of connector->encoder and encoder->crtc earlier
> > isn't a good idea because the point of the atomic helpers is that we
> > stage the state updates. That way the disable functions can still
> > inspect the links and rely upon them.
> >
> > v2: Extract full encoder->crtc lookup into helper (Rob).
> >
> > v3: Extract drm_connector_get_encoder too since - we need to always
> > return state->best_encoder when there is a state otherwise we might
> > return stale data if there's a pending async disable (and chase
> > unlocked pointers, too). Same issue with encoder_get_crtc but there
> > it's a bit more tricky to handle.
> >
> > Cc: Rob Clark <robdclark@gmail.com>
> > Cc: Sean Paul <seanpaul@chromium.org>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> 
> 
> My canary is still alive.
> 
> Reviewed-by: Sean Paul <seanpaul@chromium.org>
> Lightly-Tested-by: Sean Paul <seanpaul@chromium.org>

Put onto my atomic fixes pile, thanks for review&testing.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx