[PATCH 06/17] drm: Global atomic state handling
Matt Roper
matthew.d.roper at intel.com
Mon Nov 3 15:41:32 PST 2014
On Sun, Nov 02, 2014 at 02:19:19PM +0100, Daniel Vetter wrote:
...
> +/**
> + * drm_atomic_get_plane_state - get plane state
> + * @state: global atomic state object
> + * @plane: plane to get state object for
> + *
> + * This functions returns the plane state for the given plane, allocating it if
> + * needed. It will also grab the relevant plane lock to make sure that the state
> + * is consistent.
> + *
> + * Returns:
> + *
> + * Either the allocated state or the error code encoded into the pointer. When
> + * the error is EDEADLK then the w/w mutex code has detected a deadlock and the
> + * entire atomic sequence must be restarted. All other errors are fatal.
> + */
> +struct drm_plane_state *
> +drm_atomic_get_plane_state(struct drm_atomic_state *state,
> + struct drm_plane *plane)
> +{
> + int ret, index;
> + struct drm_plane_state *plane_state;
> +
> + index = drm_plane_index(plane);
> +
> + if (state->plane_states[index])
> + return state->plane_states[index];
> +
> + /*
> + * TODO: We currently don't have per-plane mutexes. So instead of trying
> + * crazy tricks with deferring plane->crtc and hoping for the best just
> + * grab all crtc locks. Once we have per-plane locks we must update this
> + * to only take the plane mutex.
> + */
> + ret = drm_modeset_lock_all_crtcs(state->dev, state->acquire_ctx);
> + if (ret)
> + return ERR_PTR(ret);
> +
> + plane_state = plane->funcs->atomic_duplicate_state(plane);
> + if (!plane_state)
> + return ERR_PTR(-ENOMEM);
> +
> + state->plane_states[index] = plane_state;
> + state->planes[index] = plane;
> + plane_state->state = state;
> +
> + DRM_DEBUG_KMS("Added [PLANE:%d] %p state to %p\n",
> + plane->base.id, plane_state, state);
> +
> + if (plane_state->crtc) {
> + struct drm_crtc_state *crtc_state;
> +
> + crtc_state = drm_atomic_get_crtc_state(state,
> + plane_state->crtc);
> + if (IS_ERR(crtc_state))
> + return ERR_CAST(crtc_state);
> + }
It's not immediately clear to me why we need to get (create) the crtc
state here. Is this just so that we know to do an
atomic_begin()/atomic_flush() on this crtc later or do we actually use
the state itself somewhere that I'm overlooking?
Matt
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
More information about the dri-devel
mailing list