All of lore.kernel.org
 help / color / mirror / Atom feed
From: Imre Deak <imre.deak@intel.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@intel.com>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	DRI Development <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 5/5] drm/irq: Don't call ->get_vblank_counter directly from irq_uninstall/cleanup
Date: Tue, 17 Feb 2015 15:42:07 +0200	[thread overview]
Message-ID: <1424180527.6914.6.camel@intel.com> (raw)
In-Reply-To: <1423857826-11048-5-git-send-email-daniel.vetter@ffwll.ch>

On pe, 2015-02-13 at 21:03 +0100, Daniel Vetter wrote:
> The pipe might already have been shut down, and then it's not a good
> idea to call hw accessor functions. Instead use the same logic as
> drm_vblank_off which has all the necessary checks to avoid troubles or
> inconsistency.
> 
> Noticed by Imre while reviewing my patches to remove some sanity
> checks from ->get_vblank_counter.
> 
> v2: Try harder. disable_and_save can still access the vblank stuff
> when vblank->enabled isn't set. It has to, since vlbank irq could be
> disable but the pipe is still on when being called from
> drm_vblank_off. But we still want to use that code for more code
> sharing. So add a check for vblank->enabled on top - if that's not set
> we shouldn't have anyone waiting for the vblank. If we have that's a
> pretty serious bug.
> 
> The other issue that Imre spotted is drm_vblank_cleanup. That code
> again calls disable_and_save and so suffers from the same issues. But
> really drm_irq_uninstall should have cleaned that all up, so replace
> the code with WARN_ON. Note that we can't delete the timer cleanup
> since drivers aren't required to use drm_irq_install/uninstall, but
> can do their own irq handling.
> 
> v3: Make it clear that all that gunk in drm_irq_uninstall is really
> just bandaids for UMS races between the irq/vblank code. In UMS
> userspace is in control of enabling/disabling interrupts in general
> and vblanks specifically.
> 
> Cc: Imre Deak <imre.deak@intel.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  drivers/gpu/drm/drm_irq.c | 21 ++++++++++++---------
>  1 file changed, 12 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 1e5fb1b994d7..885fb756fed5 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -269,7 +269,6 @@ static void vblank_disable_fn(unsigned long arg)
>  void drm_vblank_cleanup(struct drm_device *dev)
>  {
>  	int crtc;
> -	unsigned long irqflags;
>  
>  	/* Bail if the driver didn't call drm_vblank_init() */
>  	if (dev->num_crtcs == 0)
> @@ -278,11 +277,9 @@ void drm_vblank_cleanup(struct drm_device *dev)
>  	for (crtc = 0; crtc < dev->num_crtcs; crtc++) {
>  		struct drm_vblank_crtc *vblank = &dev->vblank[crtc];
>  
> -		del_timer_sync(&vblank->disable_timer);
> +		WARN_ON(vblank->enabled);
>  
> -		spin_lock_irqsave(&dev->vbl_lock, irqflags);
> -		vblank_disable_and_save(dev, crtc);
> -		spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
> +		del_timer_sync(&vblank->disable_timer);
>  	}

Looking also at non-i915 drivers, drm_vblank_cleanup is called always
before drm_irq_uninstall. Due to 'dev->num_crtcs = 0' in
drm_vblank_cleanup the loop in drm_irq_uninstall will be bypassed and
vblank_disable_and_save won't be called. This is mainly a concern for
UMS as you commented below, but if we care about that I'd prefer doing
the same thing above as you did in drm_irq_uninstall. Don't do anything
if vblanks are disabled otherwise warn only for KMS and call
vblank_disable_and_save and wake_up the vblank queue.

With that this series looks ok to me.

>  
>  	kfree(dev->vblank);
> @@ -468,17 +465,23 @@ int drm_irq_uninstall(struct drm_device *dev)
>  	dev->irq_enabled = false;
>  
>  	/*
> -	 * Wake up any waiters so they don't hang.
> +	 * Wake up any waiters so they don't hang. This is just to paper over
> +	 * isssues for UMS drivers which aren't in full control of their
> +	 * vblank/irq handling. KMS drivers must ensure that vblanks are all
> +	 * disabled when uninstalling the irq handler.
>  	 */
>  	if (dev->num_crtcs) {
>  		spin_lock_irqsave(&dev->vbl_lock, irqflags);
>  		for (i = 0; i < dev->num_crtcs; i++) {
>  			struct drm_vblank_crtc *vblank = &dev->vblank[i];
>  
> +			if (!vblank->enabled)
> +				continue;
> +
> +			WARN_ON(drm_core_check_feature(dev, DRIVER_MODESET));
> +
> +			vblank_disable_and_save(dev, i);
>  			wake_up(&vblank->queue);
> -			vblank->enabled = false;
> -			vblank->last =
> -				dev->driver->get_vblank_counter(dev, i);
>  		}
>  		spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
>  	}


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2015-02-17 13:42 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-13 20:03 [PATCH 1/5] drm/irq: Add drm_crtc_vblank_reset Daniel Vetter
2015-02-13 20:03 ` [PATCH 2/5] drm/i915: Drop pipe_enable checks in vblank funcs Daniel Vetter
2015-02-13 20:03 ` [PATCH 3/5] drm/i915: Flatten DRIVER_MODESET checks in i915_irq.c Daniel Vetter
2015-02-13 20:03 ` [PATCH 4/5] drm/i915: Switch to drm_crtc variants of vblank functions Daniel Vetter
2015-02-13 20:03 ` [PATCH 5/5] drm/irq: Don't call ->get_vblank_counter directly from irq_uninstall/cleanup Daniel Vetter
2015-02-14  9:38   ` shuang.he
2015-02-17 13:42   ` Imre Deak [this message]
2015-02-22 11:17   ` [PATCH] " Daniel Vetter
2015-02-23  0:20     ` shuang.he
2015-02-22 14:11   ` [PATCH 1/2] " Daniel Vetter
2015-02-22 14:11     ` [PATCH 2/2] drm: WARN if drm_handle_vblank is called errornously Daniel Vetter
2015-02-23  2:26       ` shuang.he
2015-02-23  9:52       ` Daniel Vetter
2015-02-15 14:08 ` [PATCH 1/5] drm/irq: Add drm_crtc_vblank_reset Laurent Pinchart
2015-02-23  9:54   ` Daniel Vetter

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=1424180527.6914.6.camel@intel.com \
    --to=imre.deak@intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --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.