From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Widawsky Subject: forcewake v4 (now with spinlock) Date: Thu, 14 Apr 2011 11:13:42 -0700 Message-ID: <1302804827-11597-1-git-send-email-ben@bwidawsk.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: 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 0AC4A9E982 for ; Thu, 14 Apr 2011 11:13:56 -0700 (PDT) Received: from localhost.localdomain (jfdmzpr05-ext.jf.intel.com [134.134.139.74]) by cloud01.chad-versace.us (Postfix) with ESMTPSA id E87511D408C for ; Thu, 14 Apr 2011 18:14:51 +0000 (UTC) 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-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org As the patches say, I don't think adding this spinlock will have too much of a performance impact (I couldn't notice anything in my limited testing), because the serializing locks are already held when acquiring this lock. I suppose it now serializes access between stuct_mutex and config.lock, but in most cases I don't think that's big. Perhaps the ugliest change is spin_lock() in debugfs. But as I argue in the comments, if you can't get the lock there, register reads are also failing, and hung somewhere else. Ben