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 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, 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
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 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
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 waiting
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
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 this ioctl, it will block all other
processes for the duration of all vb
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 this ioctl, it will block all other
processes for the duration of all vb
12 matches
Mail list logo
