From 97397687886aa8ecd4ec603fab9e70e970c11597 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Mon, 20 Sep 2010 17:24:30 -0300 Subject: V4L/DVB: videobuf: prepare to make locking optional in videobuf Currently videobuf uses the vb_lock mutex to lock its data structures. But this locking will (optionally) move into the v4l2 core, which means that in that case vb_lock shouldn't be used since the external lock is already held. Prepare for this by adding a pointer to such an external mutex and don't lock if that pointer is set. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- drivers/media/video/videobuf-vmalloc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'drivers/media/video/videobuf-vmalloc.c') diff --git a/drivers/media/video/videobuf-vmalloc.c b/drivers/media/video/videobuf-vmalloc.c index e7fe31d54f07..91348b3170ff 100644 --- a/drivers/media/video/videobuf-vmalloc.c +++ b/drivers/media/video/videobuf-vmalloc.c @@ -75,7 +75,7 @@ static void videobuf_vm_close(struct vm_area_struct *vma) struct videobuf_vmalloc_memory *mem; dprintk(1, "munmap %p q=%p\n", map, q); - mutex_lock(&q->vb_lock); + videobuf_queue_lock(q); /* We need first to cancel streams, before unmapping */ if (q->streaming) @@ -114,7 +114,7 @@ static void videobuf_vm_close(struct vm_area_struct *vma) kfree(map); - mutex_unlock(&q->vb_lock); + videobuf_queue_unlock(q); } return; -- cgit v1.2.3