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@xxxxxxxx> 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@xxxxxxxxx> > > Cc: Sean Paul <seanpaul@xxxxxxxxxxxx> > > Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxxx> > > > My canary is still alive. > > Reviewed-by: Sean Paul <seanpaul@xxxxxxxxxxxx> > Lightly-Tested-by: Sean Paul <seanpaul@xxxxxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
