On Fri, Jun 29, 2012 at 12:15 PM, Michel Dänzer <michel@xxxxxxxxxxx> wrote: > On Fre, 2012-06-29 at 17:18 +0200, Christian König wrote: >> On 29.06.2012 17:09, Michel Dänzer wrote: >> > On Fre, 2012-06-29 at 16:45 +0200, Christian König wrote: >> >> Hold the ring lock the whole time the reset is in progress, >> >> otherwise another process can submit new jobs. >> > Sounds good, but doesn't this create other paths (e.g. initialization, >> > resume) where the ring is being accessed without holding the lock? Isn't >> > that a problem? >> >> Thought about that also. >> >> For init I'm pretty sure that no application can submit commands before >> we are done, otherwise we are doomed anyway. >> >> For resume I'm not really sure, but I think that applications are >> resumed after the hardware driver had a chance of doing so. > > I hope you're right... but if it's not too much trouble, it might be > better to be safe than sorry and take the lock for those paths as well. > > NAK this is the wrong way to solve the issue, we need a global lock on all path that can trigger gpu activities. Previously it was the cs mutex, but i haven't thought about it too much when it got removed. So to fix the situation i am sending a patch with rw semaphore. Cheers, Jerome _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
