On Sat, Oct 29, 2011 at 06:59:42AM -0500, Ilija Hadzic wrote:
> On Sat, 29 Oct 2011, Daniel Vetter wrote:
> >Ok, and here's why your locking (or any locking that drops the lock before
> >calling schedule) won't work: [SNIP]
>
> You just came full circle. Recall that in my v1 patch I went all the
>
On Sat, 29 Oct 2011, Daniel Vetter wrote:
Ok, and here's why your locking (or any locking that drops the lock before
calling schedule) won't work: [SNIP]
You just came full circle. Recall that in my v1 patch I went all the way
to enqueuing the process in the wait queue before dropping the
On Fri, Oct 28, 2011 at 09:44:54PM -0500, Ilija Hadzic wrote:
> Now suppose that the drm_wait_vblank is enteret in the context of
> two different PIDs and suppose that there are no locks. Let's say
> that the first process wants to wait on vblank N and the second
> wants to wait on vblank N+1. Firs
On Sat, 29 Oct 2011, Daniel Vetter wrote:
+ /* the lock protects this section from itself executed in */
+ /* the context of another PID, ensuring that the process that */
+ /* wrote dev->last_vblank_wait is really the last process */
+ /* that was here; processes waitin
On Fri, Oct 28, 2011 at 05:42:23PM -0400, Ilija Hadzic wrote:
> drm_wait_vblank must be DRM_UNLOCKED because otherwise it
> will grab the drm_global_mutex and then go to sleep until the vblank
> event it is waiting for. That can wreck havoc in the windowing system
> because if one process issues th
