From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: [PATCH] drm/i915: don't grab dev->struct_mutex for userspace forcewak Date: Thu, 9 Aug 2012 22:33:58 +0200 Message-ID: <1344544438-5654-1-git-send-email-daniel.vetter@ffwll.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by gabe.freedesktop.org (Postfix) with ESMTP id 772CEA0F4D for ; Thu, 9 Aug 2012 13:33:42 -0700 (PDT) Received: by wgbdr1 with SMTP id dr1so625084wgb.12 for ; Thu, 09 Aug 2012 13:33:41 -0700 (PDT) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: Intel Graphics Development Cc: Daniel Vetter , Ben Widawsky List-Id: intel-gfx@lists.freedesktop.org Since forcewake is now protected by a spinlock, we don't need to grab dev->struct_mutex any more. This way we can also get rid of a stale comment, noticed by Ben Widawsky while reviewing some locking changes. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_debugfs.c | 17 ----------------- 1 file changed, 17 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index ed4bc98..5f3bb5e 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -1961,11 +1961,7 @@ static int i915_forcewake_open(struct inode *inode, struct file *file) if (INTEL_INFO(dev)->gen < 6) return 0; - ret = mutex_lock_interruptible(&dev->struct_mutex); - if (ret) - return ret; gen6_gt_force_wake_get(dev_priv); - mutex_unlock(&dev->struct_mutex); return 0; } @@ -1974,24 +1970,11 @@ static int i915_forcewake_release(struct inode *inode, struct file *file) { struct drm_device *dev = inode->i_private; struct drm_i915_private *dev_priv = dev->dev_private; - int ret; if (INTEL_INFO(dev)->gen < 6) return 0; - /* - * It's bad that we can potentially hang userspace if struct_mutex gets - * forever stuck. However, if we cannot acquire this lock it means that - * almost certainly the driver has hung, is not unload-able. Therefore - * hanging here is probably a minor inconvenience not to be seen my - * almost every user. - */ - ret = mutex_lock_interruptible(&dev->struct_mutex); - if (ret) - return ret; - gen6_gt_force_wake_put(dev_priv); - mutex_unlock(&dev->struct_mutex); return 0; } -- 1.7.10.4