On Mon, Jul 2, 2012 at 12:26 PM, Christian König <deathsimple@xxxxxxxxxxx> wrote: > On 02.07.2012 17:39, j.glisse@xxxxxxxxx wrote: >> >> From: Jerome Glisse <jglisse@xxxxxxxxxx> >> >> 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 <jglisse@xxxxxxxxxx> > > 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. Jerome _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
