[Intel-gfx] [PATCH 3/6] drm/atomic: Clean up wait_for_vblanks

Daniel Vetter daniel at ffwll.ch
Thu Dec 8 15:38:51 UTC 2016


On Thu, Dec 08, 2016 at 02:45:26PM +0100, Maarten Lankhorst wrote:
> Stop relying on a per crtc_state last_vblank_count, we know in advance
> how many there can be. Also stop re-using new_crtc_state->enable,
> we can now simply set a bitmask with crtc_crtc_mask.
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 29 +++++++++++++++--------------
>  include/drm/drm_crtc.h              |  5 -----
>  2 files changed, 15 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> index d19563651e07..ccf0bed9bf4a 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1110,19 +1110,20 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev,
>  	struct drm_crtc *crtc;
>  	struct drm_crtc_state *old_crtc_state;
>  	int i, ret;
> +	unsigned crtc_mask = 0;
> +	unsigned last_vblank_count[dev->mode_config.num_crtc];

I think putting last_vblank_count into
drm_atomic_state->crtcs.last_vblank_count would be nice(r). At least I
always freak out when we have dynamically sized arrays on the stack ;-)

> +
> +	 /*
> +	  * Legacy cursor ioctls are completely unsynced, and userspace
> +	  * relies on that (by doing tons of cursor updates).
> +	  */
> +	if (old_state->legacy_cursor_update)
> +		return;
>  
>  	for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) {
> -		/* No one cares about the old state, so abuse it for tracking
> -		 * and store whether we hold a vblank reference (and should do a
> -		 * vblank wait) in the ->enable boolean. */
> -		old_crtc_state->enable = false;
> -
> -		if (!crtc->state->active)
> -			continue;
> +		struct drm_crtc_state *new_crtc_state = crtc->state;
>  
> -		/* Legacy cursor ioctls are completely unsynced, and userspace
> -		 * relies on that (by doing tons of cursor updates). */
> -		if (old_state->legacy_cursor_update)
> +		if (!new_crtc_state->active)
>  			continue;
>  
>  		if (!drm_atomic_helper_framebuffer_changed(dev,
> @@ -1133,16 +1134,16 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev,
>  		if (ret != 0)
>  			continue;

		if (WARN_ON(ret != 0))
			continue;

... is the WARN_ON I meant in patch 1. Would be good to do that too while
we're at it.
-Daniel

>  
> -		old_crtc_state->enable = true;
> -		old_crtc_state->last_vblank_count = drm_crtc_vblank_count(crtc);
> +		crtc_mask |= drm_crtc_mask(crtc);
> +		last_vblank_count[i] = drm_crtc_vblank_count(crtc);
>  	}
>  
>  	for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) {
> -		if (!old_crtc_state->enable)
> +		if (!(crtc_mask & drm_crtc_mask(crtc)))
>  			continue;
>  
>  		ret = wait_event_timeout(dev->vblank[i].queue,
> -				old_crtc_state->last_vblank_count !=
> +				last_vblank_count[i] !=
>  					drm_crtc_vblank_count(crtc),
>  				msecs_to_jiffies(50));
>  
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 946672f97e1e..e03d194be086 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -93,8 +93,6 @@ struct drm_plane_helper_funcs;
>   * @plane_mask: bitmask of (1 << drm_plane_index(plane)) of attached planes
>   * @connector_mask: bitmask of (1 << drm_connector_index(connector)) of attached connectors
>   * @encoder_mask: bitmask of (1 << drm_encoder_index(encoder)) of attached encoders
> - * @last_vblank_count: for helpers and drivers to capture the vblank of the
> - * 	update to ensure framebuffer cleanup isn't done too early
>   * @adjusted_mode: for use by helpers and drivers to compute adjusted mode timings
>   * @mode: current mode timings
>   * @mode_blob: &drm_property_blob for @mode
> @@ -140,9 +138,6 @@ struct drm_crtc_state {
>  	u32 connector_mask;
>  	u32 encoder_mask;
>  
> -	/* last_vblank_count: for vblank waits before cleanup */
> -	u32 last_vblank_count;
> -
>  	/* adjusted_mode: for use by helpers and drivers */
>  	struct drm_display_mode adjusted_mode;
>  
> -- 
> 2.7.4
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the Intel-gfx mailing list