On 02.07.2012 18:41, Jerome Glisse wrote:
On Mon, Jul 2, 2012 at 12:26 PM, Christian König
<deathsim...@vodafone.de> wrote:
On 02.07.2012 17:39, j.gli...@gmail.com wrote:
From: Jerome Glisse <jgli...@redhat.com>
GPU reset need to be exclusive, one happening at a time. For this
add a rw semaphore so that any path that trigger GPU activities
have to take the semaphore as a reader thus allowing concurency.
The GPU reset path take the semaphore as a writer ensuring that
no concurrent reset take place.
Signed-off-by: Jerome Glisse <jgli...@redhat.com>
NAK, that isn't as bad as the cs mutex was but still to complicated. It's
just too far up in the call stack, e.g. it tries to catch ioctl operations,
instead of catching the underlying hardware operation which is caused by the
ioctl/ttm/etc...
Why not just take the ring look as I suggested?
No we can't use ring lock, we need to protect suspend/resume path and
we need an exclusive lock for that so we need a reset mutex at the
very least. But instead of having a reset mutex i prefer using a rw
lock so that we can stop ioctl until a reset goes through an let
pending ioctl take proper action. Think about multiple context trying
to reset GPU ...
Really this is the best option, the rw locking wont induce any lock
contention execept in gpu reset case which is anyway bad news.
Why? That makes no sense to me. Well I don't want to prevent lock
contention, but understand why we should add locking at the ioctl level.
That violates locking rule number one "lock data instead of code" (or in
our case "lock hardware access instead of code path") and it really is
the reason why we ended up with the cs_mutex protecting practically
everything.
Multiple context trying to reset the GPU should be pretty fine, current
it would just reset the GPU twice, but in the future asic_reset should
be much more fine grained and only reset the parts of the GPU which
really needs an reset.
Cheers,
Christian.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
