[Intel-gfx] [PATCH v3 7/8] drm: Connector helper function to release resources

Lankhorst, Maarten maarten.lankhorst at intel.com
Thu Feb 9 09:01:09 UTC 2017


Dhinakaran Pandiyan schreef op wo 08-02-2017 om 22:38 [-0800]:
> Having a ->atomic_release callback is useful to release shared
> resources
> that get allocated in compute_config(). This function is expected to
> be
> called in the atomic_check() phase before new resources are acquired.
> 
> v2: Moved the caller hunk to this patch (Daniel)
> 
> Suggested-by: Daniel Vetter <daniel.vetter at ffwll.ch>
> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan at intel.com>
> ---
>  drivers/gpu/drm/drm_atomic_helper.c      | 19 +++++++++++++++++++
>  include/drm/drm_modeset_helper_vtables.h | 13 +++++++++++++
>  2 files changed, 32 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 8795088..92bd741 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -576,6 +576,25 @@ drm_atomic_helper_check_modeset(struct
> drm_device *dev,
>  		}
>  	}
>  
> +	for_each_connector_in_state(state, connector,
> connector_state, i) {
> +		const struct drm_connector_helper_funcs *conn_funcs;
> +		struct drm_crtc_state *crtc_state;
> +
> +		conn_funcs = connector->helper_private;
> +		if (!conn_funcs->atomic_release)
> +			continue;
> +
> +		if (!connector->state->crtc)
> +			continue;
> +
> +		crtc_state =
> drm_atomic_get_existing_crtc_state(state, connector->state->crtc);
> +
> +		if (crtc_state->connectors_changed ||
> +		    crtc_state->mode_changed ||
> +		    (crtc_state->active_changed && !crtc_state-
> >active))
> +			conn_funcs->atomic_release(connector,
> connector_state);
> +	}

Could we deal with the VCPI state separately in intel_modeset_checks,
like we do with dpll?

Maybe implementing the relevant VCPI state could be done as an atomic
helper function too, so other atomic drivers can just plug it in.

Not sure how doable this is, but if it's not too hard, then it's
probably cleaner :)


More information about the Intel-gfx mailing list