[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