From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ben Widawsky <ben@bwidawsk.net>
Subject: force wake reference counting (another try)
Date: Mon, 11 Apr 2011 18:01:15 -0700
Message-ID: <1302570079-17032-1-git-send-email-ben@bwidawsk.net>
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 B94179E78F
	for <intel-gfx@lists.freedesktop.org>;
	Mon, 11 Apr 2011 18:01:28 -0700 (PDT)
Received: from localhost.localdomain (fruit.freedesktop.org [131.252.210.190])
	by cloud01.chad-versace.us (Postfix) with ESMTPSA id D3F781D406B
	for <intel-gfx@lists.freedesktop.org>;
	Tue, 12 Apr 2011 01:02:21 +0000 (UTC)
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: intel-gfx@lists.freedesktop.org
List-Id: intel-gfx@lists.freedesktop.org


Contrary to the discussion on IRC, I have decided not to add
config.mutex as part of the warning criteria. Upon further thought, it
just seemed incorrect to me. This patch series implies that all register
reads which may require a forcewake must now hold struct_mutex, ie. make
struct_mutex more global. The alternative is to invent a new lock for
forcewake which must be acquired prior to said register reads.

I know, that sucks. It has implications on non-SNB platforms, and that
is exactly what I was hoping to avoid. The current code is dangerous. If
two threads need register reads requiring forcewake but aren't
protected by the same mutex, it will lead to unpredictable register
reads (I can't think of a case where it will actually work correctly).

So once again, I expect this patch to potentially generate a lot of
warnings, but I consider all of those warnings to be serious bugs for
SNB.

If anyone has clever ideas on how to handle this outside of what I've
already mentioned, please let me know.

I expect ongoing patches to fix these issues as they come up.

Ben