On Sat, Aug 7, 2010 at 10:49 PM, Chris Wilson
wrote:
> When removing of the BKL the locking around lastclose() was rearranged
> and resulted in the holding of the open_count spinlock over the call
> into drm_lastclose(). The drivers were not ready for this path to be
> atomic - it may indeed invo
On Sat, Aug 7, 2010 at 10:49 PM, Chris Wilson wrote:
> When removing of the BKL the locking around lastclose() was rearranged
> and resulted in the holding of the open_count spinlock over the call
> into drm_lastclose(). The drivers were not ready for this path to be
> atomic - it may indeed invol
When removing of the BKL the locking around lastclose() was rearranged
and resulted in the holding of the open_count spinlock over the call
into drm_lastclose(). The drivers were not ready for this path to be
atomic - it may indeed involve long waits to release old objects and
cleanup the GPU - and
When removing of the BKL the locking around lastclose() was rearranged
and resulted in the holding of the open_count spinlock over the call
into drm_lastclose(). The drivers were not ready for this path to be
atomic - it may indeed involve long waits to release old objects and
cleanup the GPU - and
