From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ben Widawsky <ben@bwidawsk.net>
Subject: Re: [PATCH 3/3] drm/i915: close rps work vs. rps
	disable races
Date: Sun, 4 Sep 2011 17:23:30 +0000
Message-ID: <20110904172330.GA16313@cloud01>
References: <20110904084953.16cd10a2@bwidawsk.net>
	<1315150502-12537-1-git-send-email-daniel.vetter@ffwll.ch>
	<1315150502-12537-4-git-send-email-daniel.vetter@ffwll.ch>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org>
Received: from cloud01.chad-versace.us (184-106-247-128.static.cloud-ips.com
	[184.106.247.128])
	by gabe.freedesktop.org (Postfix) with ESMTP id 43C689E89D
	for <intel-gfx@lists.freedesktop.org>;
	Sun,  4 Sep 2011 10:20:18 -0700 (PDT)
Content-Disposition: inline
In-Reply-To: <1315150502-12537-4-git-send-email-daniel.vetter@ffwll.ch>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/intel-gfx>
List-Post: <mailto:intel-gfx@lists.freedesktop.org>
List-Help: <mailto:intel-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=subscribe>
Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org
Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
List-Id: intel-gfx@lists.freedesktop.org

On Sun, Sep 04, 2011 at 05:35:02PM +0200, Daniel Vetter wrote:
> The rps disabling code wasn't properly cancelling outstanding work
> items. Also add a comment that explains why we're not racing with
> the work item, that could again unmask interrupts.
> 
> This also fixes a bug on module unload because nothing was properly
> syncing up with that work item, possibly leading to it being run after
> freeing dev_priv or removing the module code.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
>  drivers/gpu/drm/i915/intel_display.c |    8 +++++++-
>  1 files changed, 7 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 56a8554..ccd4600 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -7483,10 +7483,16 @@ void gen6_disable_rps(struct drm_device *dev)
>  
>  	I915_WRITE(GEN6_RPNSWREQ, 1 << 31);
>  	I915_WRITE(GEN6_PMINTRMSK, 0xffffffff);
> -	I915_WRITE(GEN6_PMIER, 0);
> +	/* Complete PM interrupt masking here doesn't race with the rps work
> +	 * item again unmasking PM interrupts because that is using PMIMR
> +	 * (logically sitting atop of PMINTRMSK) to mask interrupts. */
> +	cancel_work_sync(&dev_priv->rps_work);
>  
> +	/* Clear PMIMR and dev_priv->pm_iir in case outstanding work gets
> +	 * cancelled before having run. */

This comment is wrong, you are clearing PMIER, not IMR. IMR gets cleared
in enable() iirc

>  	spin_lock_irq(&dev_priv->rps_lock);
>  	dev_priv->pm_iir = 0;
> +	I915_WRITE(GEN6_PMIER, 0);
>  	spin_unlock_irq(&dev_priv->rps_lock);
>  
>  	I915_WRITE(GEN6_PMIIR, I915_READ(GEN6_PMIIR));
> -- 
> 1.7.6
> 

I'm not sure this actually fixes a problem. The existing code:
1. disables all interrupts (no more can occur).
2. sets pm_iir to 0 safe in rps lock
<workqueues can run at this point, but IMR has no effect with IER = 0>

I think you should do the cancel work sync somewhere in the code before
module unload (to be correct). I just don't think this fixes a race.

Ben