All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 1/4] drm: Mark up accesses of vblank->enabled outside of its spinlock
Date: Fri, 17 Mar 2017 22:44:42 +0200	[thread overview]
Message-ID: <20170317204442.GW31595@intel.com> (raw)
In-Reply-To: <20170317202030.24410-1-chris@chris-wilson.co.uk>

On Fri, Mar 17, 2017 at 08:20:27PM +0000, Chris Wilson wrote:
> Order the update to vblank->enabled after the timestamp is primed so
> that a concurrent unlocked reader will only see the vblank->enabled with
> the current timestamp.
> 
> v2: vblank->enable is guarded by dev->vbl_lock not
> dev->vblank_time_lock, update the READ_ONCE accordingly.

The locking is indeed very confusing, and I don't know if it even makes
sense anymore. But this looks at least as sane as anything else here :)

For the series:
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

> 
> Do not add a READ_ONCE(vblank->enabled) inside the interrupt handler to
> avoid missing an interrupt whilst racing with enable_vblank()
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
>  drivers/gpu/drm/drm_irq.c | 23 ++++++++++++++---------
>  1 file changed, 14 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 53a526c7b24d..c47e07c89136 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -325,6 +325,8 @@ static void vblank_disable_and_save(struct drm_device *dev, unsigned int pipe)
>  	struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
>  	unsigned long irqflags;
>  
> +	assert_spin_locked(&dev->vbl_lock);
> +
>  	/* Prevent vblank irq processing while disabling vblank irqs,
>  	 * so no updates of timestamps or count can happen after we've
>  	 * disabled. Needed to prevent races in case of delayed irq's.
> @@ -336,10 +338,8 @@ static void vblank_disable_and_save(struct drm_device *dev, unsigned int pipe)
>  	 * calling the ->disable_vblank() operation in atomic context with the
>  	 * hardware potentially runtime suspended.
>  	 */
> -	if (vblank->enabled) {
> +	if (cmpxchg_relaxed(&vblank->enabled, true, false))
>  		__disable_vblank(dev, pipe);
> -		vblank->enabled = false;
> -	}
>  
>  	/*
>  	 * Always update the count and timestamp to maintain the
> @@ -384,7 +384,7 @@ void drm_vblank_cleanup(struct drm_device *dev)
>  	for (pipe = 0; pipe < dev->num_crtcs; pipe++) {
>  		struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
>  
> -		WARN_ON(vblank->enabled &&
> +		WARN_ON(READ_ONCE(vblank->enabled) &&
>  			drm_core_check_feature(dev, DRIVER_MODESET));
>  
>  		del_timer_sync(&vblank->disable_timer);
> @@ -1105,11 +1105,16 @@ static int drm_vblank_enable(struct drm_device *dev, unsigned int pipe)
>  		 */
>  		ret = __enable_vblank(dev, pipe);
>  		DRM_DEBUG("enabling vblank on crtc %u, ret: %d\n", pipe, ret);
> -		if (ret)
> +		if (ret) {
>  			atomic_dec(&vblank->refcount);
> -		else {
> -			vblank->enabled = true;
> +		} else {
>  			drm_update_vblank_count(dev, pipe, 0);
> +			/* drm_update_vblank_count() includes a wmb so we just
> +			 * need to ensure that the compiler emits the write
> +			 * to mark the vblank as enabled after the call
> +			 * to drm_update_vblank_count().
> +			 */
> +			WRITE_ONCE(vblank->enabled, true);
>  		}
>  	}
>  
> @@ -1517,7 +1522,7 @@ static int drm_queue_vblank_event(struct drm_device *dev, unsigned int pipe,
>  	 * vblank disable, so no need for further locking.  The reference from
>  	 * drm_vblank_get() protects against vblank disable from another source.
>  	 */
> -	if (!vblank->enabled) {
> +	if (!READ_ONCE(vblank->enabled)) {
>  		ret = -EINVAL;
>  		goto err_unlock;
>  	}
> @@ -1644,7 +1649,7 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
>  		DRM_WAIT_ON(ret, vblank->queue, 3 * HZ,
>  			    (((drm_vblank_count(dev, pipe) -
>  			       vblwait->request.sequence) <= (1 << 23)) ||
> -			     !vblank->enabled ||
> +			     !READ_ONCE(vblank->enabled) ||
>  			     !dev->irq_enabled));
>  	}
>  
> -- 
> 2.11.0

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2017-03-17 20:44 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-17 20:20 [PATCH v2 1/4] drm: Mark up accesses of vblank->enabled outside of its spinlock Chris Wilson
2017-03-17 20:20 ` [PATCH v2 2/4] drm: vblank cannot be enabled if dev->irq_enabled is false Chris Wilson
2017-03-17 20:20 ` [PATCH v2 3/4] drm: Refactor vblank sequence number comparison Chris Wilson
2017-03-22  8:54   ` Michel Dänzer
2017-03-22 10:06   ` [PATCH v2] " Chris Wilson
2017-03-23  3:23     ` Michel Dänzer
2017-03-29 11:32       ` Ville Syrjälä
2017-03-17 20:20 ` [PATCH v2 4/4] drm: Peek at the current counter/timestamp for vblank queries Chris Wilson
2017-03-17 20:37 ` ✓ Fi.CI.BAT: success for series starting with [v2,1/4] drm: Mark up accesses of vblank->enabled outside of its spinlock Patchwork
2017-03-17 20:44 ` Ville Syrjälä [this message]
2017-03-22 10:37 ` ✓ Fi.CI.BAT: success for series starting with [v2,1/4] drm: Mark up accesses of vblank->enabled outside of its spinlock (rev2) Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170317204442.GW31595@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.