Subject: Re: 2.6.14-rt4: via DRM errors
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Lee Revell <rlrevell@joe-job.com>
Cc: Thomas =?ISO-8859-1?Q?Hellstr=F6m?= <unichrome@shipmail.org>,
       linux-kernel <linux-kernel@vger.kernel.org>,
       Dave Airlie <airlied@gmail.com>,
       "dri-devel@lists.sourceforge.net" <dri-devel@lists.sourceforge.net>
In-Reply-To: <1132829378.3473.11.camel@mindpipe>
References: <1132807985.1921.82.camel@mindpipe>
	 <8964.192.138.116.230.1132825958.squirrel@192.138.116.230>
	 <1132829378.3473.11.camel@mindpipe>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Fri, 25 Nov 2005 16:24:23 +0000
Message-Id: <1132935863.3298.36.camel@localhost.localdomain>
Mime-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1087
Lines: 22

On Iau, 2005-11-24 at 05:49 -0500, Lee Revell wrote:
> BTW can you point me to a good explanation of DRM locking?  There's so
> much indirection in the DRM code I can't even tell whether there's one
> DRM lock or several, what kind of lock it is or what it's protecting
> (beyond "access to the hardware").  Is it just an advisory lock used by
> DRM clients to keep from stepping on each other?  It doesn't seem
> related to spinlocks or mutexes or any of the other types of lock in the
> kernel.

It co-ordinates access between the X server and various 3D clients so
that they don't step on each others drawing. A shared memory area is
used to co-ordinate other things like clip lists and what context may
have been stomped by another user if when you retake the lock you were
not last holder.

Precisely what it protects is board dependant

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/