From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ben Widawsky <ben@bwidawsk.net>
Subject: Re: [PATCH 1/2 v3] drm/i915: Dumb down the semaphore
 logic
Date: Wed, 14 Sep 2011 09:56:42 -0700
Message-ID: <20110914095642.555adc39@bwidawsk.net>
References: <1315973507-4834-1-git-send-email-ben@bwidawsk.net>
	<20110914074050.GA2832@phenom.ffwll.local>
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 B1A549E926
	for <intel-gfx@lists.freedesktop.org>;
	Wed, 14 Sep 2011 09:56:26 -0700 (PDT)
In-Reply-To: <20110914074050.GA2832@phenom.ffwll.local>
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@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>, intel-gfx@lists.freedesktop.org
List-Id: intel-gfx@lists.freedesktop.org

On Wed, 14 Sep 2011 09:40:50 +0200
Daniel Vetter <daniel@ffwll.ch> wrote:

Paraphrasing:
>> PATCH
> The code is too bloated

It adds bloat, I agree. I haven't run any tests, but I can't imagine it
has a runtime impact. Your suggestions feel a lot like the existing code
to me, which was not easy to digest.

My goal was to make the code easier to understand, and removing the
black magic was just part of that. To me it's the most obvious way to
understand how the semaphores work, though I could be in the minority.
It also provides an easy way to put per ring debug, add new rings, and
disable/enable semaphores for a given ring (your idea, which I really
like). I don't feel strongly enough about it to argue further than that.
I'm cool with letting the patches die if others don't agree.

Ben