aboutsummaryrefslogtreecommitdiff
path: root/Documentation/video4linux
diff options
context:
space:
mode:
authorHans Verkuil <hans.verkuil@cisco.com>2012-05-14 12:54:27 -0300
committerMauro Carvalho Chehab <mchehab@redhat.com>2012-05-14 15:05:55 -0300
commit74f22c48640cf39df1f9cbf4fac07f5fcd365a48 (patch)
treec929411038c524d82d47a4ad8f68fe5205f2d7f3 /Documentation/video4linux
parenta299e407b9ef356bf14fbb49793dc026877440df (diff)
[media] v4l2-framework.txt: update the core lock documentation
Thanks to Laurent Pinchart for pointing out that this information was missing. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Diffstat (limited to 'Documentation/video4linux')
-rw-r--r--Documentation/video4linux/v4l2-framework.txt10
1 files changed, 5 insertions, 5 deletions
diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt
index 0dace876b97..c24a9393dbb 100644
--- a/Documentation/video4linux/v4l2-framework.txt
+++ b/Documentation/video4linux/v4l2-framework.txt
@@ -590,8 +590,8 @@ You should also set these fields:
future!), then set this to your v4l2_ioctl_ops struct.
- lock: leave to NULL if you want to do all the locking in the driver.
- Otherwise you give it a pointer to a struct mutex_lock and before any
- of the v4l2_file_operations is called this lock will be taken by the
+ Otherwise you give it a pointer to a struct mutex_lock and before the
+ unlocked_ioctl file operation is called this lock will be taken by the
core and released afterwards. See the next section for more details.
- prio: keeps track of the priorities. Used to implement VIDIOC_G/S_PRIORITY.
@@ -652,8 +652,8 @@ v4l2_file_operations and locking
You can set a pointer to a mutex_lock in struct video_device. Usually this
will be either a top-level mutex or a mutex per device node. By default this
-lock will be used for each file operation and ioctl, but you can disable
-locking for selected ioctls by calling:
+lock will be used for unlocked_ioctl, but you can disable locking for
+selected ioctls by calling:
void v4l2_dont_use_lock(struct video_device *vdev, unsigned int cmd);
@@ -674,7 +674,7 @@ of a USB webcam might take a long time), then you might be better off with
doing your own locking if you want to allow the user to do other things with
the device while waiting for the high-latency command to finish.
-If a lock is specified then all file operations will be serialized on that
+If a lock is specified then all ioctl commands will be serialized on that
lock. If you use videobuf then you must pass the same lock to the videobuf
queue initialize function: if videobuf has to wait for a frame to arrive, then
it will temporarily unlock the lock and relock it afterwards. If your driver