Re: [PATCH 06/17] drm: Global atomic state handling

[Matt Roper <matthew.d.roper@intel.com>]

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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel